Why trying to be clever is the fastest way to writing bad code

#programming #softwaredevelopment #cleancode #tips

The 3 types of developers

In my experience, there are 3 types of people drawn to programming; “The Tourist”, “The Puzzle Master”, and “The Builder”.

The tourist is someone that has no real interest in programming itself, or what you can do with it. They are more interested in how it can allow them to change their lifestyle. They may care about the higher pay, allowing for a better living space, or to get away from the work culture they are used to in a different industry, or the aspect of being able to work remotely. You’ll often hear people from this group say something like “I just want to be able to travel and work from anywhere”. Hence the name “tourist”. Though this group often doesn’t last long, either leaving the industry, or changing position to management or something else that may be near programmers, but without having to primarily be a programmer. There are some that stick it out, and they tend to be pretty fun.

The puzzle masters are people that love the challenge, and feeling of solving a complex puzzle. These are your more stereotypical programmers. They find the levels of abstraction involved with programming exciting. They love logic, and keeping track of many things at once in their giant puzzle master brains. They can be insanely brilliant at being able to solve the most complex of problems. They are also most susceptible to the siren song of trying to be clever, but no group is completely free from its entrancing melody. This group can also be prone to over-engineering.

The last group is the builder, my favorite group, the best group! I put myself in this group, so I’m only slightly biased. Builders are passionate about making stuff. The code lets them create things they otherwise would not be able to. They tend to not be interested in puzzles, preferring to avoid them and spend as much time as they can creating. Builders are less likely to read a book on how to do something, and more likely to just hop in and try to figure it out. This can be good sometimes, but can also lead to more naive solutions that could have been avoided if more time was spent studying. Successful builders tend to be more process oriented, knowing everything they need to complete in order to finish what they’re building. They try to focus just on those things.

In reality very few people fall entirely into just one of these camps, instead being a mix of them, that may change over time. But you should know which of these you most lean towards, and if you don’t, the honest people around you will let you know if you ask.

Why trying to be clever is the fastest way to writing bad code

Why is it that trying to be clever tends to be such a bad thing? There are many adages about simplicity from other industries:

1960’s US Navy - KISS: Keep It Simple Stupid
UX Expert Luke Wrobleski - Obvious always wins
The most popular UX Book - Don’t make me think

It comes down to communication. Ultimately most jobs in our little world are about conveying context. As a developer your job is to communicate abstract ideas into concrete logic and systems that a computer can understand. But your job is also in writing that code in a way that it also communicates to other developers what your intent is, and why the code exists and does what it does.

If others need to be as clever as you were to solve the problem just to be able to understand the implemented solution, they simply may not be able to. It forces everyone to be the great puzzle solver you had to be in order to find the original solution. So good developers take the time to refactor the solution so that it is broken down to its simplest and most obvious form.

Of the 3 groups mentioned above, the puzzle masters tend to be very clever, and I mean that as a compliment. And if you are one, that means you’ll need to ensure you give yourself ample additional time after solving one of your coding challenges to evaluate your solution. See if there are cleaner, simpler, more readable alternative ways to convey that solution. Or, once you understand one approach to solving it, see if other approaches could work as well. I find talking to other developers about my complex approach yields ideas of “Would X work here?”. Sometimes X is something I hadn’t even considered, and it would drastically simplify my solution. Other times it spawns a discussion as to why X wouldn’t work here, and the other developer challenges assumptions I had made about that approach.

One time I was working with a developer who was trying to add a new concept to an existing very generalized system. This system had many many layers of abstraction built in, as it was the primary architecture for how most of this large application worked. As he talked about his approach, and I tried to offer alternative solutions, we both felt like perhaps we were over complicating things. Maybe there were other approaches we could take that wouldn’t have as many drawbacks. So we invited 3 more software engineers into the room. We explained the problem and the current approach, and ideas we had and their downsides. Then the 5 of us sat in that room for 90 minutes talking about the problem, throwing out new ideas, and shooting holes in them. From creating wrapper parent components, to making generic global state functions to be passed around between a top level configuration and a low level input field. It got pretty complex. But ultimately we found a beautifully simple solution that only required passing in a single 3 line callback function. Three seniors, one tech lead, and one quiet junior sitting in the corner listening and trying to keep up. It took this group an hour and a half to write 3 lines of code. But it saved us months of future turmoil from dealing with complex interconnected systems passing data around in clever ways.