No One Expects the Spanish Inquisition!

(continued from a story that starts here).

Doing the Right Thing the Wrong Way

Another big mistake is to imagine that just knowing what to accomplish is sufficient. It's not.

Maybe if you really, truly, could know what to build, get it perfectly right the first time, and never have to change it again, quality wouldn't matter.

Even oracular powers won't prevent you from having to change your code, though, because shifting market conditions mean that what you need tomorrow isn't necessarily the same as what you'll need a year from tomorrow.

The ability to change code quality is valuable on its own, for that very reason. The fact that it mitigates our inability to guess what people want or what will happen in the future is just an extremely useful side-effect.

Doing the Wrong Thing the Right Way

One failure mode that is very common for us is spending all your energy on technical excellence without making sure you're working toward the right goal.

You can be a true hotshot and still miss the mark. No matter how exceptional your skills are or how clean your code is, it won't matter if you apply them to building the wrong thing.

While technical excellence does help you change direction when you realize your mistake, I've seen far too many developers go far too long before learning they weren't even realizing a meaningful objective.

Make sure to continuously invest at least a little energy in finding out if what you're doing even matters.

Error Modes

I've decided to start cataloging things developers do to shoot themselves in the foot.

I don't want to get too negative but I think knowing what to avoid is as important as knowing what to do.

I'll try to tag all such posts with the "error modes" tag I used on this one.

Easy Isn't Bad

Just because it's easy doesn't make it bad. It doesn't even make it worthless.

Most of the major successes in history are actually accumulations of many small, easy wins.

Take the value where you can get it.

Simple Is as Simple Does

Simplicity has no relationship to how many code structures are written or boxes are drawn. It has nothing to do with whether or not a particular person can understand some code. There is no relationship between how many "things" you can count in a system and how complex it is because it all depends on what you decide counts as a discrete "thing".

A good yardstick for simplicity, in software, is sustainability. Code that stays about as easy or hard to change over a long period of time is probably simple code. Code that gets harder to work as it evolves is overly-complicated.

Code qualities are proxies for true simplicity. They guide you because they correlate strongly with sustainability. Use them. Talk about them. Weigh them when considering your design changes.

If you want to make a change to your design and it's going to make your code easier to work with over time, don't let someone complaining that it "adds complexity" dissuade you. If you're blindly following a "best practice" and someone has a compelling argument for how it's going to make things harder in the future, you're probably adding complexity.

Programmer Hell