Bad Hammers

You are attached to a bad tool that’s holding you back, and you lack the ability to get over it. I want to throw away that bad hammer.

I’m not the only one who’s noticed this pattern: others have noticed.

This whole piece was inspired by Casey Muratori’s talk about where bad code comes from. I also love Robert Martin’s weak attempt to cope with the fact that he made a bad hammer in their talk later on.

I’m shining a light on the mentality that is holding us back.

I want us to throw away our bad hammers. But what to throw out?

You Just Have To Do It Right

This came up in a Primeagen video, where he was going into Liskov Substitution Principle as a “good” thing of OOP (skip). The alarm bell that rang to me was that you “just have to do it right,” or else you’re not doing OOP right; it begs to exist because it’s good because it is.

This is a subclass of the “No True Scottsman” fallacy. The TLDR: if someone corners your argument, move the definition, i.e. “that’s not how [your thing] works, a true [your thing] is [qualia].” Of course, most people don’t talk like this strawman; most people will defend their hammer in other ways. “If the programmer had more skill, they probably would have done it differently, and better using [your thing].” The variations are subtle and nuanced; if the hammer bearer is skilled at speaking, they’ll hide their dissent and their tactic. No one inherently wants to use this trick (at least, I would expect that) but nonetheless you’ll hear it around bad hammers and their salesmen or proponents.

Often (but not always) Bad Hammers have this label on them: “If you don’t use it right, you messed up, and don’t get it.” With good hammers, the label is often the inverse, ergo helpful. Good Hammers might say “With these specific problems, this hammer won’t work as good as this other hammer,” or “I don’t think this hammer will actually solve this problem,” or in the case of a really good hammer, it’ll have mounds of (measurable, reproducible, actually important) data. I’m not talking about data like “90% of all people use this,” but rather more rigorous methods, such as “Big O” notation where you can actually prove that an algorithm has a specific growth quality: even then you’ll hear people who talk about Big O notation say that it actually doesn’t always measure how “fast” an algorithm is.

Bad hammers are infallible, because they’re great, otherwise why would we have the hammer? Good hammers do not come with such a label. In fact, they often say “this won’t work for a lot of situations,” but that isn’t a good way to know if it’s a good hammer either!

that’s because scammers know how to sell their hammers.

Scammers Love Bad Hammers

I’m not sure if this is a good metric, but it seems like the worst tools and the least verifiable “methods,” seem to generate a lot of books. Tons of books! Blog posts, LinkedIn posts, and YouTube videos and whole industries centered around using them “correctly”

My favorite example of this is “CLEAN” code, by Robert C. Martin. It’s main purpose is to sell more books, because it’s not clear how it actually helps you make better code. “Clean” Code proponents @ me for the reason why it’s so much more “readable,” and “better.” Also, why are you still defending “Clean,” it’s been bashed by people more qualified than me for a while.

The thing with this kind of hammer is that Zealots will mob. Uninformed beginners will flock to an authority figure. And since they’re all human, they will dig in to this new way to do things and feel threatened when they find out the hammer they were given was mostly useless.

This piece isn’t here to debate that, but it is here to point out that it’s a waste of time to try to convert believers. Programming and Computer Science isn’t about belief, or faith. It’s engineering, so the proof is in verifiable facts and outcomes.

Bad hammers can’t be measured, and that makes it perfect for scammers to trick people into using them and giving them money for the ‘service."

Novices Love Bad Hammers

I mentioned that beginners flock to bad hammers like “CLEAN” but why is that? Is it just because they"re predisposed to bad decisions? Is it because they’re bad so they go to bad things?

One reason that makes some sense is that bad hammers rely on authority, and novices don’t know what is good practice otherwise they would not be novices. There’s not much to take away from this, because programming is hard, and we’ve seen that it’s hard for some time. There is so much time investment into even trying to make code that learning wrong is a dangerous mistake.

Unfortunately, you can’t know if you learned wrong until you find someone who knows better than you. Even then, it’s hard to know if someone else learned better than you, just has more resources, if that person is just innately better / talented, or if they’ve been doing it for much longer.

I point this out, because we build up an ego to protect them from demoralizing possibilities, such as it being impossible to have the skills someone else has, or that you would have been better off doing something easy.

If there were two schools that taught programming and you had to decide which to learn from for 4 years and additionally it was not easy to identify which school produced “better” programmers, how bad would it feel if you found out after spending 4 years at school that the particular one you picked actually taught you how to program 20% worse? Even 10%, or 5% might feel terrible.

It’s easier to rationalize that you didn’t make a costly mistake. It’s easier to say that the way you learned was actually better. It’s easier to say that you don’t really need to be 20% better, because modern tooling makes everyone so good anyway, or only experts can truly learn to be that good.

It is hard to spend 4 more years learning how to get 20% better. It is hard to throw away things you spent years building. It is hard to conclude that you made a mistake, and the thing that took you a long time to learn wasn’t the best. Those who don’t build up this shield are either unaware of the pain, or taught themselves to ignore or move past it; I don’t think many (even myself) really do this. I’m certain I’ve done this, and I would guess I’m still doing it.

So, as a result novices cling to the bad hammer. Because it took them a long time. Because it cost them a lot of money. Because it’s “good.”

How to Detect Bad Hammers

The basic answer is “use them,” but unfortunately bad hammers are designed to be unmeasurable (see the former sections). I’ve alluded to ways that Bad Hammers fail and how people use them as tools to manipulate others or console themselves. But hopefully these techniques can help.

“Why” is a Four-Letter-Word

Good tools have a reason for existing. Good tools also don’t exist because they are good.

Bad hammers usually beg for their own existence. Bad hammers presume they are good. Bad hammers, “obviously” make sense.

This is a form of appeal to authority; bad hammer salesmen will often presume that you want something. Take Scrum; it presumes that your team should be “more agile,” because that’s “good.” Why use it? Uhh, well you have to believe in the premise.

If you peel back the premises, and the assumptions, and continue to ask “why,” you’ll get nothing.

Take the Scientific Method as applied today: you write papers and submit to peer reviewed journals and it takes a lot of writing. Is this the best system for Science? Maybe not, but if you continue to ask “why,” you’ll probably eventually come to a few reasons: Science is highly distributed, Science is expensive and needs large institutions, and Science needs to be verifiable.

You also don’t see any self-help books trying to apply the Scientific Publication Method to anyone, but that’s probably because it’s not a great system for individuals.

Stay Curious, and skeptical of any tool that aims to solve high-level problems. Management, programming, architecture, and coding paradigms are large domains; it’s unlikely that someone could “solve,” such problems rather than have a skill at navigating them. It’d be like someone saying there’s a best way to make music, or a best way to paint.

There’s No Way to Measure

This is probably the best way to figure out if a hammer is bad: if you don’t know how it’ll change what you’re doing.

Think about this; you buy an electric drill when you already have hand screwdrivers. Why? The new tool allows you to work faster. How much faster? Well it takes you about a minute to drive a 2 inch screw. An electric drill can do it in 5 seconds.

How much better does Scrum make code? How much better is OOP vs Functional Programming? How much better is “CLEAN” code? What percent?

If we think about good tools, like the electric drill, it’s not even a question of why it’s a good tool. For all of the frameworks, tools, and all the other things that programming gurus and framework salesmen push it’s not obvious nor is it clear how you’d figure it out.

This might be because when it comes to computers, all Turing Machines are the same. Literally. So what this means is any Java program is essentially the same as a C++ program, the same as COBOL, etc. etc. This doesn’t mean they all have the same qualities, but they have the same basic capabilities in regards to computing things. This is one of the reasons that we don’t usually see any measurable qualities for why you’d use a programming language: they’re all essentially equally capable.

Keep your eyes on measureable, achievable outcomes. Instead of saying you want “faster” or “better” programs, target a number: “60fps on these specs,” “Able to handle 1000 concurrent sessions”.

They Are Expensive

This ties back to two of my prior points: scam artists love to sell bad hammers therefore they probably want to sell the hammer for as high number as possible. Second, because novices don’t know and we all have an ego to protect, if the price is high enough, then people who buy the tool rationalize that they didn’t waste their money ala the sunk cost fallacy.

Are only bad always hammers expensive? No.

Are good tools always cheap or free? Not necessarily.

I’m calling out that the price of a tool doesn’t align with it’s value, and it’s yet another trap that we know. We know this trap so well, we’ve described and named it.

Where Are The Good Hammers?

Hopefully I’ve cleared the floor a bit. But how do we find the Good Hammers? I don’t want to fall into the same trap that I’ve just spent an entire article trying to dispel, so I don’t have any prescriptive advice.

Do not take this section as a guide, but only as advice

Some of the best hammers I’ve found simply by looking at FOSS; I started using Blender in 2006, and I didn’t know then that it was and is one of the coolest pieces of software - I just wanted to learn 3D (I’m bad at it, but it’s not Blender’s fault!). Similarly, I found Vim because I had to use it in school; I think Vim is one of the coolest pieces of technology that I use - I don’t think everyone who doesn’t use it is wrong per se, just they’re really missing out.

I’ve tried to evaluate how good hammers are. As an example Rust: a core quality of Rust is that memory leaks are difficult to write, the language is “memory safe.” These qualities are all true to some extent, but is it “good”? Rust proponents will probably say yes, but how many bugs in software we use are caused by memory leaks? Most, Few? I can’t tell, but it actually is theoretically measureable. To me, Rust is a pretty good tool. I’m not sure if it’s a “good hammer,” but it might be and I’m on that journey to discover it.

I think the only piece of real advice I can give is not to perscribe hammers, and don’t make religions around programming. I guess you can but I’ll try and find a better way.

Stay curious!