Answer ( 1 )

  1. Originally Answered: How does one become a great coder?
    Naturally, when we see a question like this, we see lots of answers like:

    “Always be writing code!”, “Learn to learn!”, and “I started on a Babbage Difference Engine that I built from marbles and gum-drops, so you should do the same!”

    Sure. Great. These are fine things, and a lot can be had early on from banging on, noodling with, and tackling problems on your own. Still, I’m going to suggest that you do two things to try to become a great coder:

    Stop writing code for yourself.
    Stop writing code.

    1. Stop writing code for yourself.
    The greats don’t just solve coding problems. The greats create tools that others can leverage to solve problems. Whether those downstream of you are in your organization or not doesn’t really matter. What matters is that your code is readable, comprehensible, usable, extensible, compatible, ableible, ibleable, etc.

    Middling and good programmers can create APIs, components, and frameworks that other teams can interact with on an ongoing basis, but it will typically take coordination, modification, and collaboration. Great programmers can build APIs and components, drop the mic/keyboard, walk away, and still have an impact.

    Think of what a good API looks like. Interfaces self-document, allocation and resource retention semantics are coherent, threading concerns are cleanly managed and consistently expressed, etc.

    What about components? Capabilities scale cleanly, integration burdens drop, interfaces allow for natural extension, problems that the component author never dreamed of can be solved concisely, etc.

    Even if you’re never going to share the code, write for others. Write virtuoso code. In a year, when you pull this code out of your bag of tricks to solve some other problem, it will be there, waiting for you, with a bow on it. When I was young, energetic, and writing code only for myself, I would express “false” with “5 == 3” or name all of my variables after farm animals. Needless to say, I don’t do that anymore.

    When all of this is done right, one coder suddenly becomes tens, hundreds, or thousands of coders in downstream efficiencies. The leveraged impact of direct application of the code is one part, but the reflections of that code in the work of others has a meaningful (though indirect) impact. Which brings me to the larger point:

    2. Stop writing code.
    This may seem a little counter-intuitive, but stay with me for a minute. In order to write well, we generally need to read quickly, effectively, and thoroughly. The overwhelming majority of what we do is read code. I just spent a couple of weeks reading code so I could take what was expected (by others) to be a few thousand lines of hard-to-maintain code and turn it into about 25 lines of the right (ask me again in six months) code. When you’re working in mature codebases, being able to make progress on large-scale bodies of code without introducing technical debt means being able to deeply understand what is in front of you. Wrapping your head around the whole problem in an existing codebase means reading the code in the codebase. It means that you can, for example, look at a thread-safe data structure and understand if it is lock-free, wait-free, or utterly broken. Part of this comes down to you and your fellow coders writing readable code for others (See 1.), but much of it comes down to your ability to ingest and internalize code. You do this by reading code, and you get good at reading code by reading code.

    Additionally, reading is your gateway to the party tricks (and substantive methodologies) of others. When you encounter an elegant API, a clever construct, or a complete solution to a complex problem, read the code. When you find a broken hack, a set of classes painted into a corner, or an incomprehensibly complicated stack of band-aids, read the code. You’ll learn about good approaches and horrible pitfalls. You’ll see a little more through the eyes of the author(s), develop some sympathy for the situational choices involved, and reach beyond your own edges. When you never stop writing, you can fall into the old adage of having a hammer… every problem looks like a nail. You can get very far with a limited toolbox and a lot of effort, but you’ll never be great.

    I once had a very senior engineer (and mentor… and friend) at a previous company tell me that I was the best “mathematician who codes” that he knew. He is the best reader of code I’ve ever met, and he was leaps and bounds more valuable to the organization than I was. The most influential programmers I’ve worked with have all been voracious readers of code, capable of reading code like others read the morning paper.

    If you want to be a great coder, you need to stop writing code long enough to start reading it.

Leave an answer