House of Eratosthenes

I don’t call them that because someone else agreed, or because I anticipate someone else will agree. I call them that because when I first got started, long before any of them were in existence, these would’ve been the ones I really needed to see.

Still Drinking: Programming Sucks

All programming teams are constructed by and of crazy people

Imagine joining an engineering team. You’re excited and full of ideas, probably just out of school and a world of clean, beautiful designs, awe-inspiring in their aesthetic unity of purpose, economy, and strength. You start by meeting Mary, project leader for a bridge in a major metropolitan area. Mary introduces you to Fred, after you get through the fifteen security checks installed by Dave because Dave had his sweater stolen off his desk once and Never Again. Fred only works with wood, so you ask why he’s involved because this bridge is supposed to allow rush-hour traffic full of cars full of mortal humans to cross a 200-foot drop over rapids. Don’t worry, says Mary, Fred’s going to handle the walkways. What walkways? Well Fred made a good case for walkways and they’re going to add to the bridge’s appeal. Of course, they’ll have to be built without railings, because there’s a strict no railings rule enforced by Phil, who’s not an engineer. Nobody’s sure what Phil does, but it’s definitely full of synergy and has to do with upper management, whom none of the engineers want to deal with so they just let Phil do what he wants. Sara, meanwhile, has found several hemorrhaging-edge paving techniques, and worked them all into the bridge design, so you’ll have to build around each one as the bridge progresses, since each one means different underlying support and safety concerns. Tom and Harry have been working together for years, but have an ongoing feud over whether to use metric or imperial measurements, and it’s become a case of “whoever got to that part of the design first.” This has been such a headache for the people actually screwing things together, they’ve given up and just forced, hammered, or welded their way through the day with whatever parts were handy. Also, the bridge was designed as a suspension bridge, but nobody actually knew how to build a suspension bridge, so they got halfway through it and then just added extra support columns to keep the thing standing, but they left the suspension cables because they’re still sort of holding up parts of the bridge. Nobody knows which parts, but everybody’s pretty sure they’re important parts. After the introductions are made, you are invited to come up with some new ideas, but you don’t have any because you’re a propulsion engineer and don’t know anything about bridges.

Would you drive across this bridge? No. If it somehow got built, everybody involved would be executed. Yet some version of this dynamic wrote every single program you have ever used, banking software, websites, and a ubiquitously used program that was supposed to protect information on the [Internet] but didn’t.

All code is bad

Every programmer occasionally, when nobody’s home, turns off the lights, pours a glass of scotch, puts on some light German electronica, and opens up a file on their computer. It’s a different file for every programmer. Sometimes they wrote it, sometimes they found it and knew they had to save it. They read over the lines, and weep at their beauty, then the tears turn bitter as they remember the rest of the files and the inevitable collapse of all that is good and true in the world.

This file is Good Code. It has sensible and consistent names for functions and variables. It’s concise. It doesn’t do anything obviously stupid. It has never had to live in the wild, or answer to a sales team. It does exactly one, mundane, specific thing, and it does it well. It was written by a single person, and never touched by another. It reads like poetry written by someone over thirty.

Every programmer starts out writing some perfect little snowflake like this. Then they’re told on Friday they need to have six hundred snowflakes written by Tuesday, so they cheat a bit here and there and maybe copy a few snowflakes and try to stick them together or they have to ask a coworker to work on one who melts it and then all the programmers’ snowflakes get dumped together in some inscrutable shape and somebody leans a Picasso on it because nobody wants to see the cat urine soaking into all your broken snowflakes melting in the light of day. Next week, everybody shovels more snow on it to keep the Picasso from falling over.

There’s a theory that you can cure this by following standards, except there are more “standards” than there are things computers can actually do, and these standards are all variously improved and maligned by the personal preferences of the people coding them, so no collection of code has ever made it into the real world without doing a few dozen identical things a few dozen not even remotely similar ways. The first few weeks of any job are just figuring out how a program works even if you’re familiar with every single language, framework, and standard that’s involved, because standards are unicorns.

Naming Cats is Easy, Naming Blogs is Hard: Programming Metaphors You Need, Part 1 of Birds

Some years ago, my mother was sick in bed, and the family cat, apparently feeling she needed perking up, went out and got the best present it could think of. It hunted vigorously for hours, and exercising all the smarts and power it could muster, it found the perfect thing, and brought it back to my ailing mother.
My mother, awoken from fever dreams to find a half-dead bird in her bed, was not appreciative. Actually, she was more horror-struck. There was shrieking. Cat and bird were both banished summarily.

My mother and the cat both sulked for days, furious at each other for the cruel way they were treated when each had behaved as well as one could possibly hope for.

I myself have had an eerily similar interaction with a programmer who proudly showed me a feature which he thought was incredibly useful, and which had also been very tricky to implement. He was outraged to discover that I did not adore it. In fact, my first response was to ask how to turn it off, out of fear that I would trip it accidentally.

He felt that I was unappreciative, resistant to change, and failed to appreciate how life-changingly useful this feature would be. (Our disagreement was not improved by the fact that it was possible but not practical to disable.)

He did have at least one thing right; unlike the half-dead bird, it proved unobtrusive. In 10+ subsequent years of using software of the appropriate type, I have never once wanted this feature, and have often been in situations where it would have been dangerous, but I did successfully use his version for several years without accident. I’m sure he continued to enjoy it, and his [virtuosity], to no end. I just wish he hadn’t given it to me.

Software is often full of dead bird features. It’s not valuable because it was difficult to implement, or because it makes developers happy; it’s only valuable if it makes the users happy. Save the dead birds for those who appreciate their excellence.

Edited to add:

It’s not just programmers that come up with dead bird features, of course. For instance, the ultimate dead bird feature is almost certainly Clippy, the animated paper clip that used to offer to help you with your Microsoft Word documents. It was a masterpiece of technology, lovingly crafted, and beloved by its audience. But lots and lots of people found it not merely unattractive but actually repellent. There you were, working away, when AARGH! your eye was drawn to an animated paper clip, actively trying to distract you from your work in order to offer to help you do something you had no interest in.

And, finally, there is the wisdom of Scotty: Never tell the boss how long it’ll really take! I am sure the kids at work, who think of “bald Captain” Star Trek as the “oldest” one, are beyond weary of hearing me quote this one & exposing myself as the only one in the room who sees the humor…yup…all those episodes, “I canna change the laws of physics!!,” Scotty was just fudging…

I have only two things to add myself.

The job is to define behavior. That is the job. This means, as some wizened sages have observed, there is a necessity for those new to it to “change the way you think.” That’s true, because the job involves defining something, and until the necessity arises a lot of us don’t have to define much of anything at all. You see this in babies. If they get what they want by just making illegible noises, that’s what they are going to learn how to do. If they’re forced to articulate exactly what it is they want, and until then they don’t get it, they become more skilled in their vocal expression. That is learning to define. This stuff we call “code” is merely the medium through which definition is done. Most debates about programming languages are counterproductive, and most programming languages hurt the industry as a whole, because by adding themselves to the growing collection of languages they do injury against the progress of defining. Just like with the spoken word, changing the language in which an idea is expressed doesn’t do anything to improve the idea. Do you really need to switch? The code you’ve written already is an asset; it is the only product in existence, after your investment of time. “How many lines is your code” is a metric that might offer a clue about this, although not a decisive one. “Is it easy to read?” is a consideration, in the sense that a programmer familiar with it shouldn’t be given a reliable first impression that is the direct opposite of what it really does. As the language evolves, it should maintain backward compatibility as it does so, so that the code written already is treated like an asset. Which is what it is. So, there should be assurances to this effect. Guarantees are better than assurances. I suppose a parchment document signed in blood would be better than a guarantee. Regardless, the best definition of a “wrong language” being used is, oopsie, this compiler or interpreter is now on rev X which doesn’t support programming construct Y anymore, so you need to go demolish/reassemble. Yeah. While you’re doing that, switch languages because that was the wrong one. Then nuke it from orbit.

With regard to Captain Scott’s parting quip, I guess by choosing that as the punchline the scriptwriters are trying to fulfill a social obligation they’ve perceived after reading about these generations of engineers who got into the industry in the first place because of “Scotty.” And so they seek to mold and shape the next generations to come. Well…let me say my piece to them. Again, the job is to define behavior. That means, it is not for “people to think of you as a miracle worker.” So-called “engineers” who make it their goal to do that, don’t build a lot. They spend more time in the e-mail client than in any development-environment tool, and their energy goes into molding and shaping public perception. Which is not without value. But…read the thing about the dysfunctional team of crazy people building the bridge. When people start calling me a miracle-worker, I get nervous. The way a husband gets nervous when his wife starts getting all excited about how he’s going to get her the perfect birthday or anniversary present, and he hasn’t got the slightest clue what that is. It is the gathering storm of high expectations. Remember, even Scotty doesn’t believe in those. He’s adamantly opposed to telling the Captain how long it’ll really take, remember?

” It reads like poetry written by someone over thirty.”
OK, THAT as brilliant.
But ya’ gotta’ be careful.
Custom manufacturing of one-off industrial display. OFF by about 1/4 inch.
One of the tasseled loafer, clean shirt, folk from “the front” came up with “Can’t you just….(always a klaxon) put that weld warped thingie under the hydraulic lift and “squish” it to where it need to be?”
(A piece that I had screwed up, made of “exotic” steel)
SPUT…pft..doh..gerk…are you out of your frekin’ mi….!!!!!!
Wait a minute…..
The ABSOLUTE WORST part of the whole episode was announcing the incident, acepting blame, and granting credit. to the ENTIRE company at the traditional “beer thirty” after work on Friday.
- CaptDMO | 07/22/2017 @ 11:10
As a programmer (of sorts), I agree and endorse all of the above.

Also, something Morgan kind of left out: Another reason Scotty’s advice is sound is because it will ALWAYS take longer than you think. So however long you think it will take, pad your estimates to give you a margin for error because the suits will praise you for coming in under time, not for being late even if “the power grid collapsed for our block” is your excuse.
- Nate Winchester | 07/26/2017 @ 10:08
Swear Trek’s version of Scotty is also apropos here.
- nightfly | 07/26/2017 @ 10:51

Leave a Reply

You must be logged in to post a comment.

Recent

Items of Interest

Monthly Archives

What They Say

Links

The Three Greatest Programming Links EverSaturday, July 22nd, 2017

The Three Greatest Programming Links Ever
Saturday, July 22nd, 2017