Programming for a Resume

The folly of choosing technologies for position rather than usefulness.

The Problem

As mentioned above, why are so many developers choosing technologies that are hot? My theory is that it’s partly about their personal marketability. Makes sense, doesn’t it? If I’m able to list a hot new technology on my resume then companies will desire me, right? This is a mistake for both the programmer and the company. There are other reasons to choose hotness such as curiosity or wanting to learn from other smart people but that’s not what I’m taking issue with here. Here, I’m addressing lights-off programmers who are trying to leap ahead through buzzwords.

I’ll be the first to admit that technology can be sexy. In my time, I’ve had love affairs with many technologies such as C, PHP, Java, Python, Clojure, Ruby, and Node. These days, I find Rust and Go to be sexy but for unpopular reasons. I’m attracted to them because they have great performance AND great developer productivity. But why aren’t more backends written in these tools? Why do companies opt for poor performing backends written in Node, Ruby, Python, and Java? Is good enough performance really good enough? I don’t think so. As a side note, I’m aware that Java can be very performant but the language is unpleasant for other reasons such as heavy boilerplate, ugly syntax, and a heavy abstraction culture.

Think about it this way, if you choose an interpreted tech stack, you automatically get a performance tax for everything you code. As you build layers, add modules, and grow your project the tax is compounded. Before long, you start hitting performance related issues and unhappy consumers. It used to be true that compiled solutions weren’t productive for developers. That’s just not true anymore.

As for companies, why hire based on a sexy tech listed in a resume? I get it. Recruiters need keywords to search for. Companies want to know if a programmer is continuing their education. But that doesn’t make this any less of a problem. I’m reminded of the talk by Adrian Holovaty entitled, “A Framework Author’s Case Against Frameworks” where he shows the downsides of not thinking about right-sized solutions.

The Solution

What we need are thinkers. We need programmers who consider, question, and summarize. We need programmers who think for themselves. I’m very passionate about this. If someone challenges me, I want to learn from them, I want to teach them, and I want to be a lights on programmer.

I think what we want or what I want is for programmers to think about why they are doing what they are doing, questioning whether there are alternative options, and having the courage to go against what is popular. That is how we will find compelling solutions in software that help businesses thrive. Software can kill a company, it’s no secret. We need to be professionals. Another side note, I’m aware that there was some drama surrounding Uncle Bob but I’m opting to stay out of it so I know very little. The talk is good and well worth your time.

Conclusion

The next time you consider what technology to use, think for yourself. If in the end, you land on an interpreted language at a minimum you’ll have reasons why you choose that language and at best you’ll have the same. That sentence is worth a second read. That’s the point: know why you are doing what you are doing and do it on purpose. If it’s to make a buck, be clear about that, at least to yourself. If, however, like me, you want to choose technologies that benefit companies then this is the beginning of that path. Be open about your thinking, allow others to challenge your views, and be willing to have the courage to champion the causes that are worth your time, not just a line item on a resume.