Software Development is a Strange Profession

Software development is similar to other creative professions in many ways. For example, working with buildings as an architect involves planning, recognition and application of well-known patterns, problem solving and so forth. But software development is different from most other professions in one very important way.

Imagine you are a painter, an architect or a musician looking for a job. What kind of information would you supply in your job application? Obviously, you would show proof of your skills (photographs of paintings or buildings or recordings of music). As a software developer, what do you show? An application?

Assume it’s a very nice application (or a very bad one). Sure, you can draw some conclusions from the externally observable quality and behavior of an application. But development is normally a team effort, your code might be perfect while other’s isn’t and vice versa… Showing an application also assumes it can be shown. Your stuff might be a deeply integrated in a backend server somewhere, or worse.

A friend of mine brought up the example of an electrician. After a job well done, the wiring is normally not visible, somewhat like the programmer’s. Nevertheless, the electrician can still take photos before walls cover up their work. Unfortunately, the code you write is normally a well-kept secret of the company you work for (and might be off-limits in terms of photography :). The problem is, as a software developer you have nothing to show! This is not only a problem for you, but also for people trying to hire you.

As I’ve said before, your CV does not say much, since experience is not really an indicator of quality code. Admittedly, there are ways to prove your skills: doing a test task, participating in open source software development, creating a portfolio of sample code to show etc. But this doesn’t change the fact that software development is a strange profession. Can you think of a profession that has the same problem?

Skills That Will Get You Hired

What is it that companies look for when they hire programmers? Surprisingly, they probably want something else than what’s in the job ad.

Job advertisements often focus on technologies (network programmingfor hire, windows programming, XML, you name it) or expert skills in a specific language. As a consequence, most CVs focus on the same thing. This is only natural, since people want to get hired. With otherwise equally strong candidates, the technology skills listed in the CV might affect who’s hired. But highlighting technology skills in a job ad is probably misguided, since I think these skills are not what companies really need. Let me explain what I mean.

In order to get a software system to do what we want, we need the above-mentioned technology knowledge. So, it’s definitively required, don’t get me wrong. But for the project to be successful over time, technologies are worth nothing unless the structure of the code is good enough for maintenance. (Somebody said that your code is in maintenance mode after the first line of code has been checked in. There is some truth in that.)

Also, acquiring a new piece of technology is not rocket science. Give it a couple of months, and you will have good enough knowledge. You will not become an expert, but there is no need for everyone to be an expert. To me, the skill to properly structure software is an essential one. Nevertheless, it is a rare one. Could it be that it is a skill hard to acquire? My point is this: avoid hiring people for knowledge that can be taught, without making sure he/she has what is essential. More specifically, what is that?

Here it is: I value people that write code that are testable, modular, readable and extensible. Without testability, I dare not touch your code. So I would have to throw it all away and start over, risk breaking it while making it testable or just dive in with my eyes closed. Nether is acceptable. With good modularity, the worst case scenario is that modules with unreadable code can be replaced or wrapped with tests. Modularity will also help readability and understanding. If you can understand the interfaces, understanding the internals become less important. Once we get down to internals of a module, readability becomes crucial. Only if I can read it (= understand it), can I maintain and extend it. Extensibility allows your software to meet customer’s needs and survive over time.

In object-orientation, there are design principles that will help you write testable, modular, readable and extensible software (see e.g. these three posts). If someone showed up with a good sense of how to write well-structured software using these design principles, he would certainly be a good hire. And conversely, if someone wasn’t convincing enough on his skills in writing structured software, he would be hard to hire. Regardless of his skills in other areas.

Correlation Between Experience and Programming Skills

In my daily work, I have the privilege to work with talented people. But finding these people in the first place is not always that easy, it seems. I’ve conducted lots of interviews with potential hires over the last five years. Preferably, you would like to learn from the CV whether or not a programmer is good, but this proves to be a tough challenge. Maybe I’ve just had a skewed set of samples, but I’ve made a few observations:

  • There seems to be little correlation between experience and programming skills. In my experience, you are as likely to find an experienced developer (10+ years of experience) with poor skills as you are finding one with excellent skills. On the bright side (and further “evidence”), I’ve come across lots of very talented newly graduated students. It seems some people “get it” right away, while some struggle.
  • Also, there seems to be little correlation between education and programming skills. I’ve seen self-taught programmers that really humbled me, as well as PhDs with poor skills. (On this topic, check out self-taught James Bach’s book “Secrets of a Buccaneer Scholar“.)

If my experiences are not just due to bad luck, it seems programming skills correlate neither with education nor experience. Then what does correlate with good programming skills?

To be honest, I have no answer. But research published in the article “The Camel Has Two Humps” presents an interesting observation. Maybe there’s a correlation between between consistency and programming skills. True or not, it is an appealing idea: it’s easy to imagine that a consistent person (i.e. a person that repeatedly makes the same decisions in similar situations) should be able to become a good programmer. Correct his flawed thinking once, and he will use his newly found knowledge in many places. An inconsistent person would need correction on a case-by-case basis.

Now if (big if) consistency is key, the question is just how do we device a test for it? I’m not sure how revealing the tests from “The Camel Has Two Humps” would be on real programmers.  (They are on the form “int a = 10; int b = 20; int c = 30; a = b; b = a; c = b; What are the values of variables a, b and c?” :))