6 ms·

Why You’re Failing to Realize Your Potential as a Developer

35 points by yitznewton 14y ago

SCdF 14y ago
11. You don't exercise enough
- Afforess 14y ago
  12. Replying to HN comments
  - unimpressive 14y ago
    13. Reading HN. But seriously, think about that for a minute.
hayksaakian 14y ago
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 http://ycombinator.com/newsguidelines.html http://ycombinator.com/newsguidelines.html Please
- freework 14y ago
  I've never understood that rule, seems kind of arbitrary...
  - hayksaakian 14y ago
    The number is arbitrary, but advertised as though it were not.
- exodust 14y ago
  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?
joshbaptiste 14y ago
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.
vosper 14y ago
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.
- exodust 14y ago
  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.
- Aaronontheweb 14y ago
  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.
antoko 14y ago
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.
dinkumthinkum 14y ago
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.
thefreeman 14y ago
http://webcache.googleusercontent.com/search?q=cache:3lkun58dbggJ:www.aaronstannard.com/post/2013/02/06/10-Reasons-Why-Youe28099re-Failing-to-Realize-Your-Potential-as-a-Developer.aspx+&cd=1&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:3lkun58...
up_and_up 14y ago
I would love to read this article but I literally can not read it with the colors and fonts chosen.
up_and_up 14y ago
"dude, stop Gandalfing the documentation and start coding something," You are a startup with documentation? Am I the only one that finds that funny?
- Aaronontheweb 14y ago
  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 https://markedup.com/docs However, what I was referring to in the article was third party documentation. MSDN docs.
wallflower 14y ago
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.
freework 14y ago
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.
- Aaronontheweb 14y ago
  OP here. If you want to nitpick over word choice, I did include "usually" into the sentence. But you're right - there are situations where a rewrite is called for. Just do it for the right reasons.
ardit33 14y ago
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.
shousper 14y ago
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?
- Aaronontheweb 14y ago
  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.
rartichoke 14y ago
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. It's the loop of death.

35 points by yitznewton 14y ago

SCdF 14y ago

11. You don't exercise enough

Afforess 14y ago
12. Replying to HN comments
- unimpressive 14y ago
  13. Reading HN. But seriously, think about that for a minute.

hayksaakian 14y ago

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 http://ycombinator.com/newsguidelines.html http://ycombinator.com/newsguidelines.html Please

freework 14y ago
I've never understood that rule, seems kind of arbitrary...
- hayksaakian 14y ago
  The number is arbitrary, but advertised as though it were not.
exodust 14y ago
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?

joshbaptiste 14y ago

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.

vosper 14y ago

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.

exodust 14y ago
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.
Aaronontheweb 14y ago
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.

antoko 14y ago

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.

dinkumthinkum 14y ago

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.

thefreeman 14y ago

http://webcache.googleusercontent.com/search?q=cache:3lkun58dbggJ:www.aaronstannard.com/post/2013/02/06/10-Reasons-Why-Youe28099re-Failing-to-Realize-Your-Potential-as-a-Developer.aspx+&cd=1&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:3lkun58...

up_and_up 14y ago

I would love to read this article but I literally can not read it with the colors and fonts chosen.

up_and_up 14y ago

"dude, stop Gandalfing the documentation and start coding something," You are a startup with documentation? Am I the only one that finds that funny?

Aaronontheweb 14y ago
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 https://markedup.com/docs However, what I was referring to in the article was third party documentation. MSDN docs.

wallflower 14y ago

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.

freework 14y ago

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.

Aaronontheweb 14y ago
OP here. If you want to nitpick over word choice, I did include "usually" into the sentence. But you're right - there are situations where a rewrite is called for. Just do it for the right reasons.

ardit33 14y ago

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.

shousper 14y ago

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?

Aaronontheweb 14y ago
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.

rartichoke 14y ago

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. It's the loop of death.