Becoming a Software Developer


Normally when people read or hear a fascinating story about anything, they tend to imagine themselves as an actor in the unfolding drama. That’s how it was for me when I first read Ben Carson‘s Think Big a few weeks before I joined high school. When our physics teacher came around for our first lesson and asked us what we would like to be when we grew up, I shot up immediately and proclaimed, rather importantly, that I wanted to be a neurosurgeon. Needless to say, I had the limitless pleasure of explaining to my dismayed classmates that the job of a neurosurgeon is to open up people’s heads and fix any problems he might find.

Even today, whenever I read a great book, watch an intriguing documentary or just listen to someone who really loves their job, I can’t help visualizing myself in a lead role in their story. Which really is the aim of any great story teller – to paint a picture so vivid that his listener sees himself in it. For most people (and most stories), this fantasy wears out soon after the end of the tale. When you read a president’s autobiography for instance, you imagine how it must be to be president. But however much you enjoy the book, you typically don’t embark on preparing for next general election on the basis of that experience alone. When you listen to the operating theater intrigues of your surgeon friend, you don’t send your application for admission into med school the next day.

Lingering fantasy

It appears though that there are certain kinds of stories that invite a fantasy that lingers far longer than usual – or at least that’s how it seems for some people. I guess it affects activities that are viewed more as hobbies rather than real professional undertakings. Things like photography, animation, rally driving and… wait for it… software development. Somehow these things attract the notion that it really can’t be that hard. And understandably so. It is certainly easier to take a picture, animate a stick figure, attempt a heel-and-toe or write a “Hello world” program than it is to perform a circumcision or run a small country. The sheer accessibility of these vocations make them seem deceptively straightforward compared to more dangerous or people-driven initiatives. The problem, I think, is a lack of appreciation of the wide chasm between hobbyist and professional pursuits of these careers.

I have met a good number of people with a small amount of training in computer programming – but often little or no apparent interest – who seem to think they can just cross over from whatever they are doing and make a career out of writing software. Such people will usually have written their last line of code a few years before, have zero or very rudimentary projects under their name and fond memories of how nice it was to never have to remember semicolons in Visual Basic 6.0. They will usually have struggled with some other job(s) for a while and then, by various means, come under the impression that software development is a very lucrative career. At which point a light bulb comes on in their head and they instantly remember their computer science roots and voila! Their fantasy journey begins.

Self taught developer

As a largely self-taught developer who does not trace his roots to an IT or CS degree, I will be the last one to say that software development is rocket science. Far from it. Anybody with the passion and a decent level of analytical skills will get by just fine. I am also not saying it is not a good hobby to pick up. I would recommend it to anyone who is genuinely interested. What I am saying is you can’t just come from being a credit control officer and hope to polish up your first year or diploma C lessons before applying for a software development job. It doesn’t work like that.

Professional software development is a lot more than memorizing compile commands and putting your curly braces in the right places. It is more than the number of programming languages with which you are familiar. It is about identifying people’s problems and solving them. It is about learning to talk to users who have no clue what they want but are especially adept at detecting what they don’t want the very moment they see it. It is about project management. It is about people and relationships management. It is about inventing tomorrow today. And you don’t get very good at these things if you don’t enjoy doing them. At least a good number of them anyway. Because writing software is as much a science as it is an art. And you know what Doug Coupland said about creativity? It is the only other thing, besides competence and sexual arousal, that you can never fake.

Best wishes

So go on and dream about becoming a professional software developer. And you have my best wishes. Just understand that it’s going to take you passion, time and hard work. And because the industry evolves so much so fast, you will need the willingness and tenacity to frequently update your skills. One more thing, in this industry, evidence of projects you have done carries far more weight than the most outstanding school grades you can muster. Unless your interviewer is not too smart – which, I must tell you, is not entirely inconceivable.


My Rugby Experience: A Lesson for Programmers


Where I went to high school, rugby was a big thing. You looked tough and impressed the girls if you played the game. You didn’t need to be exceptional. Showing up at the dinning hall in soiled shorts, grazed elbows and a limp – which didn’t even need to be genuine – often did the trick. In those pubescent days, you didn’t aim for a kiss. That was far too high. Even a hug was considered a bonus. Just a gaze that lingered a second longer than usual was good enough. If you were lucky, they poked each other’s ribs, pointed at you and whispered – or giggled. And you felt like a warrior.

There were many of us like that. We played the game for the glory. We never saw it for what it was, as much a game of wit and strategy as it was of brawn. We saw it as a contest in brute force. We hit hard even when there were less violent and more productive alternatives. We delighted in our injuries and proudly wore them as emblems of valor. When we didn’t get hurt, we faked it.

Then there were those who knew what they were doing. They played because they honestly enjoyed doing so. And they knew the real goal. To win. Like us, they would get hurt every once in a while. That was impossible to avoid. But unlike us, they never celebrated injury or took any pride in the acquisition of it. They did everything they could to avoid it, and certainly never faked it. They knew that just a point more than the opposing team was enough reward. It brought the glory and the recognition. You didn’t need a broken nose or a sprained ankle. In fact, those were liabilities that got in the way of winning.

It is many years now since I last feigned a limp. Yet in my programming career, I have witnessed something curiously similar to what happened on my high school rugby field. There are people who write code for the glory and those who write it out of enjoyment. Like in rugby, the glory-seekers are inept and disinterested in the inner workings of their art. They take pride in sleepless nights spent chasing after shallow bugs that could have been avoided in the first place. They delight in the unnecessary complexity of their classes and methods. When they pick up a design pattern, they use it to the point of abuse, often employing it to complicate what could otherwise be achieved by clearer means. They are happy when they explain a piece of code to you and you can’t get it. It gives them a high. For them, complication equals genius.

And then those who write code for the love of it. They are smart and solution oriented. Often they have so much useful work to do they could scarcely afford a minute on a needless bug. They aim to get it right the first time. From seemingly mundane observances like variable naming and code formatting to lofty ideals like unit testing and defensive programming, they are meticulous to a fault. They take pride not in the obfuscation of code but in the elegance of it. When they do obfuscate their code, it is on purpose, and they are jolly good at it. They invest time and effort in studying their art. They strive to understand every rule or suggestion of good practice. Because then that education becomes a permanent source of illumination rather than a temporary euphoria of illusory competence. Above all, they keep their eyes on the goal – software that makes its users happy, is maintainable and scales well. That is how they judge their success.

Which type of programmer are you?