In three earlier posts, I drew a lighthearted comparison between types of developers, two veteran film directors, the relentless perfectionist Stanley Kubrick and passionate amateur Woody Allen as well as comic book anti-hero Gomer Goof as the disaster artist. I wanted to highlight overlapping tendencies, not suggest strict categories. Stereotypes like Roy and Moss from the tv show The IT Crowd work great in fiction, or the evil and funny Nedry (anagram for nerdy, LOL) from the first Jurassic Park movie? 

If you do find persons matching the cliché of the behaviorally maladjusted yet genius workaholic for real, they are no fun to deal with. This is not to deny the fact that men in their thirties do take up most of the Bell curve, which dominates the perception of the programming community as a poorly diversified group. It certainly does in the Netherlands. We’re more old-fashioned than you think.

The Not-So-Humble Programmer

What is not a myth is the unwarranted self-image of some people’s knowledge and skills within the blogosphere. I’m used to filtering out most articles that list the seven essential traits of senior developers, the ten notorious pitfalls of juniors, and all assorted variations. It’s not as much the content as the tone. It oozes too much self-confidence and conviction. The writers seldom encourage modesty or humility. They seldom stop to think that there is much you don’t know, will never know, and don’t even need to know, that the individual has limited mental and physical resilience. They don’t ponder the impossible cognitive load to keep up with all that’s new.

Don’t let them or the HR departments drive you crazy with their impossible must-have skills. It’s wishful thinking. Uwe Friedrichsen wrote a series on dealing with professional ennui in leaving the rat race and gives a much-needed perspective. Remember that the software, consultancy, and certification industries need to regularly sell us their updated products, services, and training, or they go out of business. True innovations in software are rare, especially in programming languages. Hence, we exaggerate the positive impact of new developments.

Better to keep a helicopter view and not to join every movement’s grassroots stage as an early adopter. It’s expensive to bet on the wrong horse too often since many if not most initiatives die an early death anyway. Once a new technology is slowly being taken up by big legacy organizations, which happens at a glacial pace, there’ll be time to join the late adopters

No Free Root Canal Treatments

I don’t expect my dentist to perform root canals for free after hours for her friends. Likewise, accountants and plasterers. Why can’t software development be just a career? Why should new programming languages, tools, and gadgets be deemed so irresistibly fascinating that they must be on your mind 24/7? They’re not. I’m not a one-trick pony and neither are some of my most dedicated colleagues. They also have hobbies that don’t involve a keyboard and screen. 

I wrote about T-shaping as an unavoidable choice to manage the demands of growing complexity. The present-day full stack developer cannot master all the disciplines involved to the same level of detail as was required in 2001. There’s simply so much more to know. Choose the specialisms that stick to you and deepen your knowledge when you need it. Practice just in time learning skills.

When knowledge is spread, you can’t avoid asking and being asked questions. It’s a thin line to tread. Nobody likes these flow-destroying interruptions, but we also hate the feeling of being helpless when the roles are reversed. Solipsistic wizards make tremendous progress if you don’t interrupt them, but that’s neither scalable nor sustainable. Such lone wolves leave a legacy of undocumented incomprehensible spaghetti when the pack is fed up with them and their unresponsiveness.

Don't Avoid Questions; Prevent Them  

The best solution is to avoid interruptions because the questions don’t arise in the first place. Consider it your duty to prevent questions by being as clear as you can. Steve Krug’s classic book Don’t Make Me Think dealt with user interface design, but it’s just as valid for code. Big corporations know that an expensive usability consultant and subsequent rework on their UI makes perfect sense if it saves a thousand support interactions per month, not to mention the gains in customer satisfaction. 

Clean code keeps the eyebrows unraised. Clean coders write to be intelligible to their co-workers. That’s not only out of altruism. They don’t like to play helpdesk if they can avoid it.