Recently I’ve done quite a lot of interviews with candidates for a position of junior programmer, reviewing their test assignments and so forth. This has led me to wonder – what exactly am I looking for? How can I tell the difference between someone who will be a good programmer, and someone to whom programming will be just a nine-to-five job. Or, more precisely, what makes someone a good programmer?
I’d like to think I am a good programmer myself – or at least strive to be one. Sure, I will never be a coding guru who has all of Knuth memorized and can solve the travelling salesman problem with 23 cities using seven different algorithms without a computer. But I’m good enough for my daily chores.
This post tries to formulate some of the ideas I’ve had. I won’t pretend this to be an absolute, universal and final truth, these are just my thoughts on the subject.
Love
You have to love the code.
There is no other way to put it. You have to be passionate about what you do. The happiness when you pull off something above and beyond what the framework authors intended. Or the deep satisfaction from just finishing a really good piece of code. Or even the frustration of hunting an ever-illusive bug – and the joy upon fixing it.
If you have that passion, then you’re half-way there already. Everything else will come – knowledge, experience, “code-sight” – but if you lack that love, then you’ll never be a good programmer in my book. There is simply no replacement for it.
Largely, this is the reason why the famed Indian programming sweatshops (which were such a rage four or five years ago) are now mostly out of the picture. You had a circle of twenty university graduates and a supervisor walking around behind them, making sure everybody are coding as fast as they can. No slacking!
But the result of such work was simply not worth the price of $500..1000 per developer/month. As far as I know, a lot of the major players have now stopped outsourcing the work to such places (which are not necessarily in India, you can find programming sweatshops in quite a few places around the world). It is just cheaper to pay local, higher-paid programmers to do the same work in half of the time and a tenth of the bugs.
If you lack that love of code, then you still may write a decent code. But it will never be a brilliant code, it will just be a code that sort of works. You’ll lack the spark, the similar spark that makes Shakespeare different from a copywriter.
But what is there to love about the code?
It is the same excitement that a poet gets from writing a poem, or a painter from painting. It is the act of creation, the “develop” part of the word “developer”. We write some lines of text, which abides to the certain rules, and suddenly ex nihilo! we have a website, a video player, a database engine or something else.
Learning
If you are looking at your own code from two years ago and it looks fine, it doesn’t mean you were a good programmer two years ago. Quite the opposite, it means you haven’t grown as a programmer within these two years. You haven’t learned anything.
Programming is all about learning. New languages, new frameworks, new ways to do things, new tricks. Like Lewis Carrol’s Red Queen put it, “It takes all the running you can do, to keep in the same place.”
If you want to become a programmer, you will not be able to stop learning the day you left the university. In fact, you’ll realize that a lot of what your Alma Mater taught you is, frankly put, useless.
My own way to become a programmer was… convoluted, to say the least. Some day I will write a post about it – but suffice it to say that I don’t have a formal education in programming. I am completely self-taught. And, in a way, that is a good thing. Constantly learning something new is normal for me, whereas people just out of university often go “but I was taught to do it this way?!”
And so far, every time I’ve looked back at myself from two years ago, I’ve been able to go “boy, was I stupid back then. I am glad I am so much better now.” I hope this never ends.
Lazy
A programmer I used to know needed to generate some HTML. Cleverly, he used helper methods to do that. He needed H1, so he created a method similar to:
- public static string GetH1(string content)
- {
- return string.Format(“<h1>{0}</h1>”, content);
- }
He also needed a H2. So:
- public static string GetH2(string content)
- {
- return string.Format(“<h2>{0}</h2>”, content);
- }
And then he needed H2 with an ID. Lo and behold:
- public static string GetH2(string content, string id)
- {
- return string.Format(“<h2 id='{0}’>{1}</h2>”, id, content);
- }
And then he also needed H2 with a class. I’ll spare you from the code now, but you can guess what he did.
But this was just for H1 and H2 tags. He needed various other tags as well – img, div, p and so forth. And yes, you guessed right. He had overloaded methods for each and every one of them. The helper class ended up with about 30 methods in a several hundred lines of code.
Me, I’m a lazy bastard. I would have written:
- public static string RenderTag(string tag, object attributes = null, string content = null)
- {
- tag = tag.ToLowerInvariant();
- var html = new StringBuilder();
- html.AppendFormat(“<{0}“, tag);
- if (attributes != null)
- foreach (var prop in attributes.GetType().GetProperties(BindingFlags.Instance | BindingFlags.Public))
- html.AppendFormat(” {0}=\”{1}\“”, prop.Name, prop.GetValue(attributes, null));
- html.Append(content == null ? “/>” : string.Format(“>{0}</{1}>”, content, tag));
- return html.ToString();
- }
Less than dozen of lines of code without empty lines and braces. And that’s it for every tag you can imagine. Call it any way you like – RenderTag(“br”); RenderTag(“h1”, null, “header”);, RenderTag(“h2”, new { id=”myId”, @class=”myClass” }, “subheader”); – it just works. You can even render tags inside tags with that method.
Sure, I wouldn’t use that method to render a full website, but for a few dozen lines of HTML that was needed, it would have been perfect. Far faster to write than hundreds of lines of repetitive code.
The point where I’m getting to is that you can be eager and write more code. Or you can be lazy and figure out a way to write less code. Being lazy is a good thing in a programmer. It forces us to find patterns and promotes code reuse. It makes us more effective. It makes us better.
Or, to use the words of Terry Pratchett, “Having to haul around extra poundage was far too much effort, so he saw to it that he never put it on and he kept himself in trim because doing things with decent muscles was far less effort than trying to achieve things with bags of flab.”
—-
tl;dr: just read the damn thing.