While we cannot change the industry, we can change ourselves, and by change I mean making sure we are actually qualified for the job we do, instead of resting on our laurels of experience. You may be hired for the experience you have, but you want to deliver all the knowledge you have acquired, even if you never had the chance to use it in any of the companies you worked on. How do we gain experience without working on a specific project? Education, of course! The training of pianists offers a very convenient analogy on this matter.

As a pianist myself, I would never be able to imagine how would I ever be able to perform without training. I would not be able to do sight-reading either: most of what I play has a reasonable complexity and requires a thoughtful interpretation. But programming and playing piano are very different when it comes to performance: while piano players are able to train hours, weeks or months for a few hours of performance, programmers are expected to learn on the job – hence the over-appreciation of experience. To make things just a little more difficult, the only time programmers have to fully concentrate on their training is their free time (no wonder you have to love what you do to stay on this business).

I do love what I do. I do love to study what I use at work to perform more than I train, but there’s a problem: I’m not willing to lead a monomaniac lifestyle, I do not want to use all my scarce free time to train for work. I need to rest and take care of my health to keep doing what I love to do. The inevitable corollary: my training must be very efficient. Do I find very efficient training available? Definitely not. Most of the technical books seem to expect a very passive kind of reader: I never find lists of exercises in many of the famous books from O’Reilly or Manning. Lists of exercises should be the rule, not the exception. It still amazes me how authors without teaching skills are allowed to publish technical books in a field where professionals are so devoid of training. We are left in the cold to learn erratically. We are supposed to train like monomaniacs. We are supposed to err on the job.

The self-learner’s agenda

We do what we need to do to accomplish the goals of our company. Accomplishing these goals doesn’t necessarily imply using all aspects of a technology we want to learn. Unless you’re one of the lucky ones who happen to use everything you will ever need to know about a given technology at work, your company’s goals and your learning goals are two different agendas. Where do you execute your agenda? Out of work, certainly. Unfortunately, what happens out of work is often ignored by many companies, which limit themselves to make their job requirements in terms of years of work experience. It doesn’t seem consistent that our learning efforts are underestimated by the very companies that could benefit from it, but I don’t think these companies are to blame, after all, measuring knowledge can be tricky.

Measuring knowledge with years of experience

Work experience follows a business agenda, and for the most part that implies repetition of the same experience after a while. To say one has worked 4 years with C++ does not imply she has explored every possible aspect of the language and its libraries at work (some people suggest job-hopping can be a solution). But it’s not just the overestimation of work experience: the time of work experience that is usually required indicates that it is assumed that it is impossible for one to achieve a level of expertise in less time. This is in sharp detriment of merit. Many professionals will feel unstimulated to pursue more skills in less time as this is an underrecognized effort.

As an approach to learning, work experience is unsystematic, emphasizing specific aspects of a technology in detriment of others. In the “My Job Went to India” book, Chad Fowler addresses the “learn on the job” issue on the “Practice, Practice, Practice” chapter, but even his suggestions rely on one’s judgments of what should be improved, which, in my view, is too biased and not very systematic. Fowler is right when he says that we learn too much on the job, but it’s no wonder considering how other means of learning are underestimated.

A systematic approach to training and assessment is needed

Last year I’ve bought the “Spring in Action” book. I was not using Spring at work, but I wanted to learn it nevertheless. Despite the educational purpose of the book, there were no exercises! It seems like I’m supposed to learn it on the job, or create my own (biased) exercises. At this stage, I’m not able to create effective exercises, only a Spring expert would have such an authority. If I’m lucky, I will use many Spring features at work, or maybe my exercises will be enough, but that would be betting on good fortune, and I don’t want my qualifications to depend on luck! I don’t want to live in the constant anxiety that I’m not prepared. Many professionals feel like they are unable to train properly because systematic training doesn’t exist for every technology they work with. And it’s not just a systematic training: how are we (and our employers) supposed to measure our knowledge in an unbiased way?

The solution

Even if employers decided to ask technical questions instead of requiring years of experience, professionals would still not be 100% sure about their skills because there is little systematic training and assessment. A solution for this would require a little initiative, for example: if you are a complete Spring guru, you could write a series of exercises in ascending complexity with suggested solutions that people could use to evaluate their results. The same goes for other frameworks, languages, etc. The whole point of this idea is to assure that one can always know in what point of the knowledge ladder he is. That can evolve to universally accepted credentials that employers can use. We’ve been using this system ever since we started studying, why should we stop now?

Fortunately, Steve has managed to be persuasive. What is very interesting about his post is that Steve, as someone who has managed to understand compilers, didn’t fall into the arrogance trap. Instead of arrogating himself for his compiler knowledge, Steve took the self-critical route, describing in a very candid manner what he thought about compilers early in his career. Instead of enumerating arguments that make sense only for the GCC team, Steve describes how different programmers in different contexts can benefit from this knowledge, showing his awareness for diversity in a post that instead of condemning, stimulates and encourages all of us to look further into compilers.

If I asked a SAP/Netweaver programmer what would it take for me to become a better professional, there’s a very high chance she would recommend me SAP/Netweaver. The same goes for other languages. If I asked a network administrator the same question, he would probably point me some network administrator’s skills that I should learn – all that without even detailing what my goals are. With the interdependence of today’s many technologies and skills, many of these recommendations could be pretty much valid, yet it’s still a challenge to figure out how one would manage to achieve any goal at all if he is to study everything that is important.

In the posthumous “The Art of Controversy“, Schopenhauer recommends “extrapolation” as one of the techniques to counterpoint an argument. When it comes to such an overused argument as the importance, this strategy proves to be very useful. A hardware engineer may recommend to a programmer: “you should study the depths of hardware engineering, because it if weren’t for hardware, your software would have nowhere to run”. This argument can be extrapolated with the phytoplankton analogy: “you should study the depths of microbiology, because if it weren’t for phytoplankton, which produce almost half of our oxygen, there would be little chance for intelligent life, without which there would be no hardware or software”. The phytoplankton is extraordinarily important, but should we study the depths of microbiology, diverting ourselves from our programmer goals, just for the sake of its importance?

This extrapolation is meant to highlight how the importance of a subject is not necessarily related to its relevance to our professional lives. A subject may be important, my very job may depend on this subject, but that still is not enough to make this subject relevant. The relevant subjects are those that lead me to my goals, which, on their part, are very individual choices that are subject to my very own criterion. In other words: importance may be objective, but relevance is subjective, and it’s based on this subjectivity that my professional choices are made. Being a product of subjectivity, importance itself has nothing to do with it, although that is what our vanity wants to believe. When it comes to looking for a good mentor, it is then convenient to look for someone with a similar subjectivity, but in a higher professional level. As Fowler puts it: “It’s OK to depend on someone. Just make sure it’s the right person”.

I remember giving to a co-worker the source code of a program I had written a few years earlier, when my coding practices weren’t exactly as I would like them to be. “I wrote this 3 years ago!” – I said, as if meaning “I don’t know who’s the idiot who wrote this code, but it wasn’t me, OK?”. Chances were that she didn’t care, but nevertheless I was faced with code that I had done myself and that I wished I could do again with my current skills. This case in particular was about the fear of someone else’s judgement, a judgement that would not take into account the developer that I am today, but the one I was.

But the urge to rewrite code is not just about other people: sometimes you are a team of one; other times you are in a team of more than one, but you want to rewrite parts of the code for the sake of its own quality, not someone else’s opinion. This very website fell victim to this perfectionism, as I would constantly switch layouts as I found a better one. This constant insatisfaction meant that I was never – ever – releasing the website. It also meant that the time I was using to try many layouts (to later discard them) wasn’t being used to write new content. As the release of my website was under no deadline, I could go on with this perfectionism indefinitely. It’s when self-criticism and deadlines meet that you have a problem.

The self-criticism per se isn’t bad, of course. For me it’s a symptom of my evolution as a programmer. The problem lies on the urge to redo that arises when this feeling hits hard. If you have to deliver a new feature, or write new content, a refactoring may be the right thing to do in the wrong time. Naturally, we don’t keep adding new features forever: if even hardware has to face manutention every now and then, can you imagine software (though convincing your manager likewise is a different matter). Understanding when the urge to redo will happen is key to make it fit on the manutention window. To me, the two basic factors that define this urge are the self-criticism and how much the skills evolved in a given time frame:

Very self-critical, perfectionist people will have more urges, even when Δ evolution is small. On the other hand, even a self-forgiving person may want to rewrite code if his skills have evolved significantly ever since he wrote the code.

Of course, this is not a formal theory, and it applies to specific situations such as those when one has to work on a single project while his skills are evolving. I have a few suggestions to adress this issue, but I’ll leave that to my next post.