Sloppy vs Right

Every time I join an existing project I have to do one of the most frustrating things in my profession: reading and making sense of other developer’s code.

This is where I always see a reflection of one of the oldest false dichotomies: sloppy coding vs. “right” one.

It goes like this: one cannot write “right” code fast enough for a given time frame, that’s why it is sloppy: bad design, too generic (or misleading) names for abstractions, “spaghetti” style of routines etc.

Why this dichotomy is false?

Because it justifies unprofessionalism.

In our profession, despite its seemly overwhelming complexity, there is a limited set of corner-stone principals and skills (definition of this set is out of scope of this post).

One who does not possess, use and master (to some viable extend) this set is easily recognizable by someone who does.

Reading somebody’s code is one of the ways to recognize it. Unfortunately it means that sloppy code made it into production, and people behind it (developers and managers alike) made reading it one of the most frustrating things in my profession.