[ Code ] The Thing About Real Artists Is That They—

Some code is beautiful and you want to read it, reuse it, and take it into your program and your heart. Some code is annoying and pretentious, and some code looks good at first and turns out to be kind of mean. Estimating code quality is a big part of programming. Go on—judge.

[OK]

As a class, programmers are easily bored, love novelty, and are obsessed
 with various forms of productivity enhancement. God help you if you’re 
ever caught in the middle of a conversation about nutrition; standing 
desks; the best keyboards; the optimal screen position and distance; 
whether to use a plain text editor or a large, complex development 
environment; chair placement; the best music to code to; the best 
headphones; whether headphone amplifiers actually enhance listening; 
whether open-plan offices are better than individual or shared offices; 
the best bug-tracking software; the best programming methodology; the 
right way to indent code and the proper placement of semicolons; or, of 
course, which language is better. And whatever you do, never, ever ask a
 developer about productivity software.

Meanwhile, the executives who run large programming teams have to actually ship software. “Ship” is a cult word. If they don’t ship on time, managers could get a lower rating on their performance reviews and end up making only inordinate, as opposed to obscene, amounts of money. Wine cellars are at risk, not to mention alimony payments. As managers, their job—along with all the trust falls and consensus-building and active listening—is to reduce ship risk, which comes in many forms: bad bugs; features that were promised to bosses or clients that distract from boring, utterly necessary features; or test servers that crash at night.

One of the greatest ship risks is anything shiny. This is where languages are particularly risky. An experienced and talented programmer can learn a language in a week, but a middling one is going to take much longer. Meanwhile, exciting, interesting programming languages always come with a list of benisons, promises of speed or productivity or just happiness. No, really. Happiness is a serious selling point for languages, and people have written blog posts where they analyze how people discuss code. According to an analysis by GitHub user Tobias Hermann, PHP coders are far more likely to use the word “hate” in their Reddit comments than Clojure programmers; Clojure programmers are far more likely to use the word “cool” than PHP programmers.
There are many blog posts on how to persuade your manager to switch to a new language. Experienced managers, who bear scars and were often coders themselves, become practiced at squinting and coughing and saying things like, “No, the switching cost is just too high right now,” or, “Maybe we could do a two-week trial project when we build the analytics reporting engine.”

17

Then the programmers shuffle back to their standing desks and complain until the product is shipped. Or else they just quit, because Lord knows there are jobs out there. For programmers, particularly the young ones, there are jobs everywhere.
Managers and old coders have fewer options. It’s often better to just keep working and shipping, even if the code starts to look ugly, even if there are nominally better solutions, even as the technical debt

18

accrues around you, because in a few years everything will change. Maybe you’ll get promoted and the new manager will have the will and motive to tear up everything you did, cursing, and start again (perhaps using a new language) with the goal of making something much simpler. Or the entire industry will spasm and everything you’ve done will need to be thrown away and rebuilt along new lines anyway. (From desktop to Web, from Web to mobile, from mobile to … quantum? Who knows. But there’s always something.)


Somehow it keeps working out. The industry is always promising to eat itself, to come up with a paradigm so perfect that we can all stop wasting our time and enter a world of pure digital thought. It never happens.

 We Still Need to Choose …

Nine weeks into the re-architecture, you have asked TMitTB to come by the office and talk next steps.
You’ve noticed that his team has started to dress like him. One of the women is in tall boots and has done something complex with her hair. She’s wearing a black leather jacket. Nothing ostentatious, just cooler. She was previously all Patagonia. Is this how programmers dress? How did they get their own executive style?
“PHP,” he says, “well—it is what it is. The team had a good time at PHP[world]. But I think the thing we might have learned …”
He doesn’t pronounce the brackets, of course, but you approved the expense, and that’s how they write it, bracketed. It’s good they had a good time, because it cost you $25,000 to send them to that conference and put them in hotels and feed them, and you have no idea whether that was money well spent or not.

“… is that we really need to move off of PHP.”
Oh. Well. There’s your answer.
“We’re all agreed that PHP isn’t the language for our next five years.”
“Which one would you say is?”
“Ay, there’s the rub,” he says, and you have to remind yourself to not show him your real face right now. If he quotes Hamlet again, though …
“Well,” you ask, “which language do you want to use?”
He looks confused. “I mean, it doesn’t matter,” he says. “I don’t write the code.”
Then who does? And you realize, right now, the answer is no one.