It's not bad advice - and also nothing new - but it's very condescending: "I want to help average developers who want to improve by calling out 10 performance-killing behaviors that stagnate the careers of most developers".
What makes this guy so great? He states that his product is "difficult even for large companies to master" so I'm inclined to think he's doing a few things wrong himself.
He paints a black and white picture and divides everyone into "average" or "good", that's my only issue.
In reality, each project demands different solution, some have heavy UX challenges, others strictly an architecture puzzle. There's bound to be variation in how "good" our work is for each aspect of the project. In one year, most of us have done lots of stuff, some really good, other stuff good. Like making an album, not every song will be a classic, but you'll break even and be home before midnight most nights.
Sometimes the solution is not pretty.
There's also developer ability in the mix too, and developer-philosophy! With javascript, for example, sometimes your function might be "the long way around" but still fine. Ok so it could have been done a little more efficiently if you'd constructed that other array and took that extra step etc etc. But here's the thing: in some languages such as javascript, taking the long way around might afford you better readability of your own code later, or just easier to work with for adding new elements later. It's YOU who makes that call. Sure, there's advice to be shared and we're all learning, but there's also a flexibility with programming that affords all but the most critical applications a bit of breathing room. If someone sees a better way to write a function, then great, update it if you feel it's a good choice. Or tell them they can update it anytime.
OP here. Our product is an analytics service and we manage large volumes of time-series and cohort data.
Every developer has lots of room for improvement. I'm no exception.
What I'm calling out is that there's a large cohort of developers, I've labeled them as "average developers," who completely stop growing intellectually and professional. They're technically passable but are stunted.
Strong developers, a small cohort of 10x developers (I'm a 10x developer) who I've labeled as "strong developers." The reason they are so productive is a strong focus on self improvement in areas that drive productivity.
For some really gifted developers this may come naturally / intuitively; for others like me it was more intentional / learned.
I wanted to share those learnings with average developers who are self-aware enough to realize that they're not growing and don't know how to fix it.
The condescending tone is intentional. Having a thick skin is a requirement to confront your own weakness. If the tone bothers you, you're probably a little too sensitive.
And in case you're curious: I would never talk down to an engineer on my team this way.
I can recognize the difference in writing a blog post intended for the anonymous Internet versus an intimate conversation with someone I work with 12 hours a day.
I am always concerned when I hear a developer self-identifying as a "10x developer" - you may well be right, but it smacks of arrogance as well.
Likewise, being intentionally condescending is an unusual approach to take at any time - even to the "anonymous internet". No-one likes to be condescended to (by definition) and so if you're attempting to promote your company and opinions I'd advise you to reconsider your tone.
I'm not the best developer in the world and probably won't be, but I'll freely admit that I'm excellent when it comes to productivity and iteration speed.
There's nothing "arrogant" about believing that you're good at something, particularly after spending many many years believing that you weren't and working really hard to improve. And there are many things I still do wrong and I'm working on improving those too.
Most of the feedback I've received on the article has been overwhelmingly positive, which leads me to believe that it's a small population of sensitive people who take issue with the tone.
Give it a rest already. Most advise is condescending. Including yours. If you haven't worked on a product that is 'difficult' for other to master, maybe it's because you just haven't solved any hard programs. Can you list all amazing programs that you have written?
Here is a dude who has started a company and he has something to say. He has written something nice and instead of appreciating what he has written and what he wants to convey, people go on and on nitpicking about irrelevant stuff.
While I agree with most of what the author is saying, the tone of the post really bothered me, I'm not sure why because I usually don't pay much attention to tone provided the content is valid. The longer I read the more I started to think he wasn't really describing strong vs. weak developers, he was describing strong vs. weak personalities. It was wrapped up as commentary on our profession but for almost all of his points you can replace "a strong developer" with "a confident person" and "a weak developer" with "an insecure person", and it actually reads better if you do.
Maybe the author needs to take some time to learn how to increase confidence in his employees? It is usually more useful to see how you can affect positive change than complaining that life/the world/other people are to blame for everything.
If the original title begins with a number or number + gratuitous adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is meaningful, e.g. "The 5 Platonic Solids."
Otherwise please use the original title, unless it is misleading or linkbait
Interesting. I think I agree with @freework, although it's quite trivial I suppose.
There are 10 items in the article, 10 separate points with headings. The author chose to draw attention to that in the title, maybe to offer a clue as to the quantity and arrangement of the document?
Average developers are those who aren't committed to getting better or keeping up. In some software areas, those two terms are synonymous.
To use a specific example, in the mobile development world, which is arguably one of the "hottest" development jobs (the dot-com-like hype gold rush aside), you have to keep improving to continue to be relevant, let alone 'realize your potential'.
The above average mobile developer keeps up with the best-in-class practices and the ability to deliver to the baseline customer experience expectations for the platform (which keep going up and up - customers are spoiled by the Instagram/Airbnb-type apps of the world).
For example, iOS has gone through significant changes from iOS 2 (original) to iOS 6. Maybe three or even two years ago, using ASIHttpRequest was good enough for async network operations. Now, everything has gone to blocks. Sometimes enough blocks tied/nested together to put Lego to shame. Storyboards have started to replace tedious UIViewController plumbing. Modal dialogs used to be tolerated by customers, now obvious use of them make your app look cheap and outdated. Custom animations (and yes maybe even custom tab bars) are almost expected (this is good and bad) - but simple stuff like tapping on an image to expand it to full-screen and tapping on it to collapse it back to thumbnail - the customer expects that.
As for Android, Android is running at a pace that leaves average developers behind. Someone who still uses TabActivity for apps is rightfully categorized as out-of-touch with the post-Holo look and feel. If you don't have an ActionBar in your app, your app is out of date. Someone who uses BroadcastReceivers for piping data between Activities and Services is out-of-date (see Square's Otto or GreenRobot's EventBus).
I know this devolved into a bit of a rant - but developers have to keep up with the best-in-class practices - and in the best case - "rockstar" class developers like Jake Wharton of Square for Android - can inspire others and give the community the right tools to push the entire platform forward and make it more competitive (in this case, with iOS).
I believe the best developers share their knowledge (whether in a closed environment like a team - or best - Github and conferences and podcasts/screencasts) so that others can become better.
All of them are traits of junior developers. (I know, because I was one at some point). With enough experience, and working in different type of problems they will start disappearing bit by bit. You will have both those skills, and the confidence to tackle major problems.
What's needed to reach that point:
1. Work on different type of projects and features (i.e. both back end, and front end). Being full stack is better early in the career.
2. Work on your own project end to end. It gives you a complete different perspective and grows you as an engiener by leaps and abounds(you are the PM, engineer, QA, and consumer advocate).
3. Learn really well (be fluent) at both language types. One static (Java, Scala, C++, C, Objective-C), one dynamic (Javascript, Lua, Python, or Ruby).
4. Work with a super solid/10x-er engineer, the multiplier type. You will learn a lot by working with somebody that is both good and has a lot of experience.
Good article, yet do not fret, an average developer with great ideas and execution can churn out a money making product thus hire developer rock stars to scale and improve your average code.
I think the author was talking more about rockstar/genius developers with many years under their belt than simple "good" or even "great" developers.
I also think the author fails to realise that a lot of what he recommends isn't easy to come by.
Don't get me wrong, it all makes a lot of sense; every word. However I agree more with antoko in that perhaps the focus sometimes needs to be on increasing developer confidence. After all, we can't all be rockstars can we?
OP here. No, we can't all be rockstars. I'm a productive developer and can own products, but I'm no Bill Joy.
However, we should always seek a means to improve. The items on this list are good set of guidelines to follow and I'm sure there are others I've overlooked.
I agree with most of these, excapt for the one that goes, "Strong developers accept that the business costs in a rewrite are usually unacceptable and should be avoided". What if the existing codebase is a rats-nest of complexity? WHat if the previous team were "bad developers" and they wrote code that was neck-high with technical debt? I think great developers are lazy, and not wanting to wade through a bad codebase is a trait of a good developer.
Solid article from top to bottom. My weakest link is Gandalfing like no other. I'm the moron who spends like 3 weeks eyeballing a new language or lib by consuming its spec, video presentations, tutorials and all of that but then produce 0 code in the entire time frame.
Then I'll take a break for like a week and when it comes time to coding something I'll forget most of what I read and then I use that as an excuse to read more.
OP here. We actually do have documentation, but that's because our product is an SDK + analytics service that requires developer integration: https://markedup.com/docs
However, what I was referring to in the article was third party documentation. MSDN docs.
I don't want to make this a slight against .NET programmers. It's no surprise to see all the references to .NET and Microsoft I know we have hit this topic a bit in the past, with various blog posts. This may be enlightening article for some. . But I will say, a lot of this is mostly true of a large swatch of the .NET/Microsoft developer crowd. A large percentage are really, to be honest, and you could probably say this about a couple other big crowds, uncurious, and not very deeply interested programmers. It's not surprising because so many, especially those that attend conferences and the like, are doing government contract work. Just my thoughts Also, the tone is a bit odd to me.
What makes this guy so great? He states that his product is "difficult even for large companies to master" so I'm inclined to think he's doing a few things wrong himself.