The Programmer Skill Fetish, Contextualized
I am currently considering something of a content pivot for DaedTech. I haven’t really decided anything for sure yet, but I’m leaning toward putting cross posts into digest format once per week and then doing fewer posts, but ones that are more focused on developer empowerment and the efficiencer dream. Your feedback on this is entirely welcome in the comments or on Twitter or Facebook or anywhere, really. I’d honestly like to know what you think.
I mention that because I think I need to refocus a little on some hypotheses that underpin all of this. In the time between writing Developer Hegemony and now, I’ve found myself distracted by changing my lifestyle, selling a house, starting a couple of businesses and, well, life. But throughout that time, I’ve given some thought to what I ought to offer people with this site. Should I continue (against the advice that I offer everyone else blogging with purpose) to keep the blog as a chronicle of my many thoughts? Or should I orient it around a theme in which I help people solve some kind of problem.
And I’m leaning toward trying to solve a problem.
So back to the hypotheses. First one that I’ll mention is that programmers should specialize and seek options outside of full time employment. (Not as in immediately making it your goal to escape the rat race. Rather, make it your goal to have options outside of serving at the pleasure of some single employer.) The second one, following from that first, is that we focus on programmer skill to the point of fetishizing it. And, we do this to our detriment.
The Known, But Unheeded, Career Wisdom for Programmers
Let me lay out a few points that surround the issue. None of these will probably be especially new to you, but taken together, they’re interesting.
- You often hear some variant of “part of being a great developer is knowing when NOT to write code.” In other words, being really good at writing code helps no one if you code up a useless product.
- Successful “entreprogrammer” John Sonmez, in promoting his “Soft Skills” book, often talked about how he wasn’t successful because he was the best programmer, but because he learned the material that he was communicating in the book — strategies for business and dealing with other people.
- In most organizations, it’s not necessarily the “best” programmers that wind up with higher pay and vanity titles like “senior,” “tech lead” and “architect.” It’s generally the longest tenured ones. Long time readers will remember my writing on this subject.
- Businesses and non-technical people often don’t listen to the “best” developers, often because those developers take pride in spewing jargon and being indecipherable.
- We can’t even define “best” programmers. Do a google search on it. Page one alone promises more than 100 answers. These include technical knowledge, but also things like “positive attitude” and “good communication skills.”
Put all this together, and you have an interesting picture. The business world and the greater non-programming world in general values one thing. Programmers, when we get together, value something different. We’re fully aware of how outsiders value us, but we just can’t resist the impulse to compare ourselves to others with code competitions, programming challenges, data structure interviews, and claims that we’re “10x” better than others.
The Skill Fetish, Explained Indirectly
This brings me to what I think will be the fun part about writing this post. I want to use a metaphorical story to help bring context to why we do this, and how shotgun-blast-to-our-own-feet it is. It’s easy enough to sit there in the waiting room of GiganTech, waiting to see if they deem you better at O-notation than the other 430 applicants, and get caught up in all of this. It becomes normal. So I’m going to draw a parallel to a different line of work.
I did this to an extent in Developer Hegemony, but as part of a larger point about journeyman idealists. Here, I’ll get more direct.