A lot of attention is paid to the value of "rockstar" or "10x" programmers in building successful organizations. It's not hard to understand why; the inherently scalable nature of software means that marginal differences in programming work result in large differences in output.
Whether targeting outliers is a sustainable hiring strategy (it certainly can't be if everyone is doing it) is a widely debated topic. Less often talked about is what actually makes somebody one of these great programmers.
Without a mental model, it's difficult to either work towards being a great programmer or identify such individuals when hiring. What follows is an (opinionated) attempt to distill some of the qualities that make a great programmer. In particular, this list emphasizes delivering value within an organization (as distinct from the pure craft of programming). The list is loosely sorted in ascending order of difficulty / rarity.
1) Strong programmers can write business logic.
This means the ability to write working code which yields a solution to a presented problem. Sort an array of values, determine the right data to show a given user, etc. Obviously this is not a binary condition (everyone has different limits) but most development tasks shouldn't stretch the limits of your ability in this regard.
One big reason that software engineering interview processes are broken is that this is simultaneously the minimum requirement for being able to hold a programming job and the complete extent of what is tested for.
2) Strong programmers can write good code.
This is different from being able to write application logic. Code is for other people and should be written as such. This means succinct and expressive names, modular classes and functions, and readable logic. It's not enough that a piece of code "works". Good code is straightforward for others to use.
3) Strong programmers can design and architect things correctly.
There are of course many acceptable solutions to a given design or architecture problem. You can reasonably choose to trade simplicity for performance if the application warrants it. You cannot reasonably choose an approach that is both complex and slow (where a simple or performant solution exists).
Coming up with a "correct solution" means having the depth of understanding to make appropriate tradeoffs and avoid inflicting a deadweight loss on the software.
4) Strong programmers know a lot.
This is fairly self-explanatory; software engineering is knowledge intensive work. You can Google syntax but you can't Google fundamental problem solving ability.
5) Strong programmers learn a lot.
Again, this is pretty self-explanatory. In the course of working as a software engineer, you will encounter situations where you need knowledge you don't have. Being able to acquire that knowledge is important to being effective.
6) Strong programmers teach a lot.
Yet again, this is straight forward. Teaching is an economical way to deliver value to an organization. It makes others more effective in their work, creates a more attractive work environment, and fosters a culture of knowledge growth.
7) Strong programmers can take ownership of projects.
I'll define this as being able to take high-level business requirements and deliver a good software solution to the problem. This is less a technical skill than a "human factor".
Completing a project often involves a mix of programming and other non-technical concerns that are difficult to bake into a standard process. This means identifying what stake holders want (which is often distinct from what they ask for), forming the correct approach, aligning involved parties, and executing to deliver a strong finished product.
Being able to assume responsibility for these varied factors is a major separator of people who are good at writing code and people who are able to have major impact in an organization.
Top comments (18)
That's a reasonable outlook. I'll also add that we don't often bring up context. In the right environment, setting, and constraints, I am a 10x programmer (well, maybe 8x) but I can think of scenarios where I'd be 1x at best. I shouldn't think I'd be just as valuable to every team and situation.
I totally agree. I was a 1/2 developer when I worked with a team as the only remote worker. I wasn't able to keep the pace with them. In other context, my code production was very high and with decent quality ;-)
That's tough. I think most teams should take the plunge either way - all in the office or mostly remote - it's tough to be one of the only ones that aren't in the loop. Daily meetings don't make up for that either, and it shows in code quality and technical debt in my opinion.
Totally agree, or they need to be extremely considerate of those who are remote which I've seen remote-first companies do quite well. Little things like all meetings happen at your desk via video regardless of how many people are in the office...
Context is everything. I work as a bridge between front end and backend, so I'm quite often explaining how something works. I wouldn't consider myself higher then a 7 anywhere, but to them I'm more knowledgeable because I can do both.
I have turned many developers into 10x developers by reducing rework and debug time, basically developers find issues without a debugger and they only code once or twice. There are three tasks where developers spend the most time... debugging intermittent production issues, responding to changing requirements, and recoding because of changing data structures many times due to changing requirements. Extensive logging and reporting with try catch blocks solves first one. Anticipating requirements fixes second. And designing data structures that answer questions that need answered and properly represent all one to many relationships is important. Surprisingly naming conventions that accurately describe function is also critical. Automation especially test automation can also significantly reduce issues by finding them immediately. Basically reduce where developers spend time and everyone will be a ten x developer.
@John Lehew. Spot on. Companies have to invest and nurture developers to become 10x. IMO 10x devs do exist. It would be cool to make an Awesome list on github For who that might be. Id say. github.com/feross and github.com/sindresorhus Would make the top of the list.
Yes, indeed programming involves a lot more than just coding. A sentinent I shared in my article I'm proud to be a programmer.
An unanswered question is whether people are naturally 10x programmers, or this is something that can actually be improved upon with experience. You mention several "...a lot" statements. I wonder if this isn't the truth of where great programmers come from.
They program a lot, they teach a lot, they learn a lot.
I think a lot of people don't like facing the fact that if you spend a long term in one position you lose out on challenges, you lose out on new colleagues, you lose out on new learning opportunities. Maybe great programmers just subject themselves to a lot of variety.
I completely agree - programming is a lot more than just coding.
Can you learn to be a 10x programmer? I certainly think so. I've never met a 10x programmer who was a child so I don't think people are born that way.
At least on some level 10x programmers learn what it takes to be 10x programmers and practice those skills and disciplines while they are working.
I've given this topic quite a bit of thought and have written a preliminary guide on the topic: How to be a 10x programmer
I think it provides a nice contrast to the views in this discussion. I'd love some constructive feedback on my ideas from the dev.to crowd.
That "10x" became so annoying. Is this sustainable "10x"? How "10" is supposed to be measured? Anyway "10x" is highly contextual. In long running project it would be like "3x" at best (and 3x over 2 year project is a lot, mind you). For green field it may well be "10x" but then will you consider amount of technical debt the project then or instead praise that 10x-er for good job so he moves on to next hyperachievent and ask other folks to clean unicorn's poo?
Other parts of context are how team fits together, whether people are familiar with tools, how complicated is communication (if you own whole project - it's faster, if you have to coordinate many teams it takes time no matter now 10x your developers are), whether engineers solving right problem or just churning code that is destined to be abandoned, and handful of other reasons.
Strong programmers know when to listen to others.
This is very valuable advise. Now I know what it takes to be "10x" programmer. Thanks!
The best writing on subject I ever read is this one
kitchensoap.com/2012/10/25/on-bein...
Note how little it says about coding.
What is your opinion on TDD?
this article changed my outlook .
+1