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".<p>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.
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.<p>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.
Average developers are those who aren't committed to getting better or keeping up. In some software areas, those two terms are synonymous.<p>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'.<p>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).<p>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.<p>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).<p>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).<p>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.
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."<p>Otherwise please use the original title, unless it is misleading or linkbait<p><a href="http://ycombinator.com/newsguidelines.html" rel="nofollow">http://ycombinator.com/newsguidelines.html</a><p>Please
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.<p>What's needed to reach that point:<p>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.<p>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).<p>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).<p>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?
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.<p>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.<p>It's the loop of death.
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.
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.