You have to bear in mind that this story happened in 1999, more than a year before the dot com bubble burst; senseless hiring of people was considered perfectly normal at that time.

I was working for a well-known consumer electronics company, developing mobile phones. Our CEO had a problem. The problem — which is not so uncommon among CEOs — was that the investors weren’t happy because the company didn’t sell enough handsets. So the boss went to sales and they claimed they couldn’t sell more because the development guys didn’t give them enough cool products — products the customers reeeeeelly wanted and even if they did, they’d finish too late; that is, they’d come out with a phone in March, missing the Christmas sales season by threeeeee month.

So our boss went to the development manager to find out what the problem was; our development manager told him what almost every development manager tells in such a situation: “We could develop soooooo many cool products in sooooooo little time, if we only had moooooore developers!”

This procedure repeated a couple of times until our CEO freaked out. He went to our human resources manager and commanded him to “get more software developers, no matter what!”

Our HR manager didn’t know much about hiring software developers, but he surely had a plan: he wanted to hire 100 software developers in 100 days. He had t-shirts printed, carrying these words:

[company]
100
in
100
Do YOU have good
soft(ware) skills?

Our job was to wear these (poor quality) t-shirts and attract potential software developers for our team.

This strategy was unbelievably stupid for many reasons. First, it emphasizes quantity, not quality. Second, it reads as if soft skills were more important than software skills. Last, it is very offending as it is based on the idea that good software developers stupidly fall prey to such bad HR campaigns.

Anyway, we got lots of candidates — many more than we could interview; our HR manager celebrated a victory. We, however, had to separate the wheat from the chaff and thus we developed programming tests that every candidate had to take.

One of the most successful questions was this one:

Write a routine that sorts an array of ‘n’ integers; write best-quality code.

Innocuously as it looks, this question has several good characteristics: it requires the candidate to actually write real code; since it has to be ‘best-quality code’ you can find out about his/her skills and quality standards. For instance, does the candidate

– pay attention to style issues (indentation, layout and consistency in general)?
– choose meaningful identifier names?
– write (good) comments?
– use assertions and/or checks for boundary cases?

This question can reveal even more: since no programming language is given, you can find out about a candidate’s favorite programming language. But most importantly, you can find out if a developer is smart and has a questioning attitude.

Every smart developer knows that there is no perfect sorting algorithm. The choice depends on many constraints — constraints that are not given in the problem statement and hence must be investigated. I remember one applicant commented along these lines:

[…] It all depends on how big ‘n’ is and whether we have write access to the array (that is, we can sort in-place). Are there any code/RAM restrictions? Depending on factors like these I would choose the best sorting algorithm from a text book. Unless no further information is given, I would use the sorting algorithm that comes with the standard library (e. g. qsort() in C, java.util.Arrays.sort() in Java). Since I know that you want me to write some code, I’ll implement an insertion sort algorithm which is easy to code and its O(n^2) behavior is acceptable for ‘n’ < 1000 [...]

Naturally, we made an offer to him, which he turned down a couple of days later. I guess he was scared of having to work with too many soft skills experts.

Good programmers often wonder how to become even better programmers. They constantly seek for new tools and techniques that help them getting their job done better and faster.

If you want to know what helps the most, here is some advice:

“You must do two things above all others: read a lot and write a lot. There’s no way around these two things that I’m aware of, no shortcut.”

These words are from the best-selling author Stephen King; he should really know — he makes 45 million bucks per year from his books.

I believe that programming and writing novels have a lot in common and that King’s words of wisdom are applicable to software development as well.

Let’s first focus on reading. It’s a well known fact that programmers read too little. In their book “Peopleware”, Tom DeMarco and Timothy Lister assert that the average developer doesn’t own a single book on the subject of his or her work. If this is true, it might be an explanation as to why our industry is performing so badly: if developers don’t know about the fundamentals of software engineering (not just coding issues — also topics like software quality, configuration management and peopleware in general) how can they explain them to non-technical folks like sales and upper management once they’ve become technical leaders?

What about code reading? Fortunately, we live in very privileged times. Twenty years ago, almost all code was closed source; nowadays, there are billions of lines of open source code out there from which we can learn. Alas, there is the fundamental law of programming: “It’s harder to read code than it is to write it.”

If browsing through huge open source code bases gives you headaches, check out “Code Reading” or “Code Quality” by Diomidis Spinellis. These two fine books quote (and criticize) countless examples from open source projects — in my view, a lightweight and often entertaining way to improve your programming Kung Fu.

But what about code writing? Isn’t a professional software developer already writing enough code? Not so! Typically, software developers only spend a fraction of their time writing code. In fact, most of their time is devoted to meetings, email, reading specs, writing documentation and so on. With this little time given for writing code, it is vitally important that developers keep their programming skills active.

A good way to practice is by contributing to an open source project. Another possibility is doing Code Katas — little practice sessions, based on a concept borrowed from karate and other martial arts, where the practitioner fights against an imaginary opponent. But by far the best way is to work for your employer in your leisure time — for free!

Have you recovered?

I presume that to most people, this idea sounds shocking, almost insane — but I really mean it. Often, good ideas arise during the day that your boss doesn’t understand and hence doesn’t approve. If you think your idea is challenging and useful for the company — do it at home! Not only does this improve your coding skills, it helps your company; as a bonus, your reputation within the company increases. So we have at least a win-win, if not a double-win-win situation. But only choose interesting topics, things that improve your skills; leave the drudgework for the office.

Constant reading and practicing is the key to success. It doesn’t take much time, but it needs to be done habitually. Don’t expect that your company or your boss or anyone but you is responsible for improving your skills. Even if those days existed in the past, they certainly don’t exist anymore.