Does Writing Code Matter?

Ian Landsman's 10 tips for moving from programmer to entrepreneur is excellent advice. Even if you have no intention of becoming an entrepreneur.

One of the biggest issues I see is developers getting caught up in the code. Spending countless hours making a function perfect or building features which show off the latest technology. Now you have to write code to be in the software business. It has to be high quality code that isn't filled with bugs or is insecure. However, the best code in the world is meaningless if nobody knows about your product. Code is meaningless if the IRS comes and throws you in jail because you didn't do your taxes. Code is meaningless if you get sued because you didn't bother having a software license created by a lawyer.

Software developers love code. But we're biased. And we write less of it than we think we do. We spend far more time understanding code than writing it.

Anyway, as Ian points out, the importance of the code we do write is absolutely dwarfed by everything else that goes on around it. Raise your hand if you've ever poured your heart and soul into an application that never shipped. I know I have. And that's just the tip of the iceberg; there are hundreds of reasons the code you write may have zero impact on the world. If nobody knows about your code, if nobody can understand your code, if for whatever reason your code doesn't even ship … then have you really accomplished anything by writing that code?

Maybe the best way to succeed as a programmer is to cut out the low value activities entirely and stop writing code altogether. Steve Yegge explains:

Do you have any programming heroes? I do! Oddly enough, though, I've never really seen much of their code. Most of the famous-ish programmers I respect have actually made their impact on me through writing, and it's usually just prose, with maybe a little code interspersed.

There are programmers I admire who've built things that I use a lot. But when I try to come up with a list of programmers I admire (and I specifically mean people I don't know personally), I find they almost always fall into one (or both) of just two categories:

• People who wrote a useful programming language, an operating system, or an especially important framework.
• People who wrote a really neat book about programming.

When someone builds a framework – any environment that we live in and actually enjoy programming in – and there's one person who's chiefly identifiable as the primary author of that framework, then I think we tend to admire that person, and unlike other programmers, the person starts to become famous.

Even if they're a crappy programmer.

Not that we'd really know, because how often do we go look at the source code for the frameworks we use? How much time have you spent examining the source code of your favorite programming language's compiler, interpreter or VM? And by the time such systems reach sufficient size and usefulness, how much of that code was actually penned by the original author?

Am I really telling developers to stop writing code? No, not really. Developers are already good at writing code. It's why they became software developers in the first place. Writing reams of code just digs you deeper into an already deeply specialized skill. What I am proposing is that we spend less time coding and more time developing skills in other areas that complement our coding skills. Become a better writer. Become a better speaker. Improve your personal skills. Participate in the community. Try to spend some time talking to people instead of the compiler. That's how you distinguish yourself from your peers. And that's ultimately how you become a better software developer, too.

Of course, this isn't a zero-sum game. You can have it both ways. Ideally, you'd write code, and then write or talk about the code in a way that inspires and illuminates other people. But we don't have an infinite amount of time, either. If you have to choose between writing code and writing about code, remember which side of the equation is more important – and balance accordingly.