Man, I thought this was going to be an article on better code reviews and how to get better feedback from people you work with regarding your performance.<p>Instead the article is some strange "self-help"/"hustle-hard" blogspam, quoting Malcolm Gladwell and shading a picture of the normal distribution and pretending it's arrived at some brilliant insight.
Software is not sports. Stop comparing software to sports. Stop comparing developers to athletes. Stop making analogies to running. Just stop.<p>In fact, please stop doing that for all serious vocations, life is not a game and that's all sports are: a game. That's why everything in sports is super simple, straightforward, and measurable [except when it isn't, but don't mind me].<p>Sports are not really a good analogy for most things, because sports are entirely <i>relative</i> and have no fundamental value. No soccer player has any inherent value except for being better than a large amount of other soccer players. So it makes sense that soccer player skill follows a binomial distribution since it's basically that by definition.<p>This is not the case for developers. Developers do not need to be relatively best to produce a lot of value, and mostly produce value by the nature of, well, producing it. If you create a useful website, you created a useful website, it really doesn't matter if you are the best website creator on the planet. The value of that website has no relationship to your abilities relative to others, and has much more of a relationship to things like whether it's useful for customers.<p>And since there are a range of domains, you actually end up with balderdash if you measure developers against each other, since some are good at debugging, some at C, some at websites, some at arguing with product owners, and some at writing AIs in Python. There's really no point or benefit from trying to homogenize them all into a group and rank and file them.<p>What we need is not "great" developers, what we need is higher <i>standards</i> for all developers, so that across all these varied domains we have lots of people who respect quality.<p>The "fundamental gap" between developers is likely not there and I think this thinking is actively harmful. All we need is to encourage more developers to <i>care</i>, which is already a hard enough problem without getting into the useless weeds of being the developer equivalent of Muhammad Ali, which seems like a great way to discourage literally 99% of developers because that is how sports work in practice and most sane people avoid sports [as a job] for that reason.<p>Rant over.
This seems like an article that would not have been on HN's Front Page a few years ago. Are people blindly upvoting articles based on the title? How can HN moderate incredibly low quality articles like this one? This is a checklist of how to become a better anything, how to more effectively work on a team and other work how to's without diving beneath the obvious surface at all.<p>Am I the only person seeing HN descend into terrible click bait with flame war comment sections? In this case, I really hope my observation is the outlier, and that people continue to find this site helpful and contructive.
> The well-known 10,000-hour principle, popularized by Malcolm Gladwell, illustrates an important lesson for developers. ...<p>It’s not often I’ll wholesale dismiss an article on HN because of one sentence, but this is one of those times. The fabulist Gladwell is not credible in general, and his 10,000 hour “rule” can no longer be thought to even remotely approach science, or even fact. The author lost all credibility with this sentence.
Here's the key thing that I think has made me a better developer - focus on being a better communicator. At some stage in your career you're going to work on something that would be impossible for a lone dev to write. At that point being someone who is happy to have a meeting, write a clear document, or answer the phone is going to make you a key person on your team. You'll be in the center of everything, hearing the facts and making the decisions. That's what senior devs do. They communicate.
I have been collecting similar guides to improve on software engineering, as I am a recent graduate looking to excel in my career. Here are some other blogs I found useful:<p><a href="https://recurse.henrystanley.com/post/better/" rel="nofollow">https://recurse.henrystanley.com/post/better/</a><p>"Ask HN: What topics/subjects are worth learning for a new software engineer?": <a href="https://news.ycombinator.com/item?id=18000410" rel="nofollow">https://news.ycombinator.com/item?id=18000410</a>
My favorite takeaway from this is that I'm an ANGELIC TROUBLEMAKER (because much/most code is demonstrably terrible but I do have a fair amount of experience in greatly simplifying it), but other than that I find several points in the article to only be relevant in these times.<p>I've been through several boom/bust cycles and right now we're living in a boom period where:<p>* Programming demands a high hourly rate<p>* There are many programmers on the market, tending towards making them interchangeable cogs<p>* Income inequality is high, leading to a wide discrepancy between wealth and technical literacy<p>After the coming web2.0/mobile bust in a few years, these will likely no longer be true. I think what will make a good programmer then is the ability to map use cases (design) to abstractions and then to business logic in as little code as possible (preferably none at all). We're going to go back to a time more like the 1980s, when nontechnical people were able to get Real Work done with spreadsheets and DBMSs like Microsoft Access.<p>I looked at Airtable a bit and it has some interesting ideas but is no panacea. There are other interesting attempts in that space but almost everyone seems to be moving in the opposite direction towards large volumes of highly imperative, object oriented code which is prone to technical debt that requires a longterm support staff of technicians to maintain it. In other words maintaining is currently more lucrative than architecting, but that wasn't always true, and will likely not be true again in a few years.
I have three rules for better coding performance, for me.<p>- Ask Questions<p>- Do not Multitask. One problem at a time.<p>- Test control answers i.e. You want result to be 10 then test for 9 and 11. Wrong results create a more stable solution.<p>Speed has never been my strong suit, but when I deliver code to QA, you can bet that you will be testing a well thought out solution.
Highlights of this article:<p>- 10,000 hours mastery: Another power-of-10 based bullshit stolen from Rocky I.<p>- Stacked ranking: Bullshit belief that gives you 100% probability of ruining a company. Costed Microsoft 10 years to fix the damage caused by it.<p>- Personality types: Horoscope-grade pseudoscientific bullshit used to justify bad management. See also: MBTI<p>- Hyperbolic decay: Often applied to impress people easily impressed with math, i.e.: bullshit<p>- Self-promotion<p>My thoughts and prayers to the 278+ people that upvoted this article.
The most valuable skills I've learned are empathy and a servant attitude. I cringe at some of the things I've said in the past with an inflated ego and poor attitude. I try to put relationships first and listen before problem solving.
Despite the weird formatting and general buzzwordiness I actually enjoyed this quite a bit.<p>Chapter 2 resonated the most, finding a meaningful metric and then measuring against that is something every engineer should do, not just in SW, but sadly it's very common that teams just bumble along hoping for the best.
Be warned! There is no correlation between being a great software engineer and having a rewarding career in the workplace. You need other skills to survive the politics in hiring and promoting as well[0].<p>0 - <a href="https://cis.org/North/Oracle-Sued-White-Males-Indians-Receive-Different-Kinds-Favoritism" rel="nofollow">https://cis.org/North/Oracle-Sued-White-Males-Indians-Receiv...</a>
Unfortunately you need half of this. Just listen and understand what other say don't go over it. Don't think you have it all right. Work hard keep your head down, but look for the options.<p>There is a lot of stuff to say to go kill it, but not. To kill it you have to be exceptional and usually people are not exceptional. Unfortunate is most people will think the6 are exceptional and fail.
This is an excellent general framework for upping your game in software development within the context of a decent sized software engineering organization. I've stumbled my way into much of this advice over the past 2-3 years.<p>One caveat is that much of the advice is predicated on having a supportive environment.<p>For Example,
> Application development is a team sport. Period. Full stop.<p>What if you work in an environment where people primarily work on their own? I have done a lot of that in the past.<p>> For many, the best way to learn is to teach.<p>What if there aren't feasible opportunities to teach or your management pushes a pace that makes it not plausible?<p>> Create side projects<p>There are managers that support the idea of doing side project but not the execution.<p>I'm sure you can find more examples of suggestions that aren't plausible in your environment.<p>Here is my answer to these examples, I wasn't just complaining. If you don't have opportunities to fulfill sections of this framework that you feel you are lacking in, do it anyway. If your manager tells you not to spend time learning and improving ignore them. Do it anyway.<p>You might say, "that's fine for you Mr. internet commenter, but I'm the one that has to take the risk". Well, that's true but I've already done it. Here were my results.<p>Did exactly what my management asked me to do for two straight years. All reviews for two years were "Meets expectations" with a long list of things I should improve.<p>One year ago, I read a book with an abhorrent title but good information "stealing the corner office"<p>I stopped listening to what my manager told me to do and instead I picked up random side projects with little to no perceived business value for my team, spent 10x more time reading code and made commits in projects I shouldn't be working on, and started spending a lot more time understanding basic fundamentals of software engineering.<p>Have had "exceeds expectations" on every review since and glowing praise.<p>It's counter-intuitive but, don't give the people what they ask for, give them what they want!<p>Note: I got a bit carried away on this comment, I should have mentioned that in reality I spend 10 - 20 % of my time working rogue, and the rest of my time doing what my boss tells me.
Orthogonal content that inspired me to finally get serious about learning functional programming, and led me to Erlang: <a href="http://sijinjoseph.com/programmer-competency-matrix/" rel="nofollow">http://sijinjoseph.com/programmer-competency-matrix/</a><p>Sure, it's flawed, but isn't everything?