Reducing Code Suckage
Legibility is important enough to be the opening topic but it’s not the most important aspect of code suckage. I’ve written more about this here:
We still cultivate the notion of a “personal coding style” which is never, ever, ever based on any consideration of ease of apprehension for others or even for the author; coding style is for developers (we are nowhere near “engineers” when we do crap like this) is akin to what dogs do with fire hydrants; it’s territorial marking.
There are studies, lots of them, on how we parse text, so far as I know I am the only developer who has ever considered these in developing coding standards for software development groups.
But the big reason most code sucks is because the people who write it can’t concentrate. We’ve known since before the personal computer, known since the days of mainframes, that some programmers produce much higher quality code and a lot more of it than others, and that the criterion for this superiority is the ability to enter Flow, periods of prolonged and uninterrupted concentration. The uninterrupted is the important part; once concentration is broken by some meeting or some other interruption it is gone, usually for the day.
The early success of Microsoft had its very foundation of recognition of flow and cultivation of a workplace that enabled it. More on that here
The abandonment of good workplace practices corresponded with the replacement of software executives who were experienced developers with businessmen, people to whom a meeting is a productive use of time (is this your experience? It’s not mine). We felt this happening; we didn’t like it; a lot of the best people decided to leave and work somewhere they could be productive without being interrupt by a meeting that came at the same time every week, or even every day, regardless of need.
The last ten years have seen an avalanche of decay; those of us who remember being able to concentrate are aging out of the industry and younger developers think that “methodologies” are the answer, that more meetings are the solution to time lost to meetings, that more testing is the solution to low-quality code.
I’ve even read that people who want to focus (people like me) are antisocial, toxic to “teams” (what a stupid metaphor that is), possibly mentally ill.
Going back to what worked for years is pre-repudiated.
I’ve worked in agile and scrum; I don’t like them. They add little of value and both pile on the interruptions. Test-driven development is backward and cultic, inefficient and silly. Again
Test-Driven Development is Fundamentally Wrong
It was late 2008 and I was writing an extension for the Windows 7 taskbar. My work was essentially finished, the final…
You want to write non-sucking code? Decline the meetings. Get into an office alone. Put on your headphones, put a DND sign on the door, forget about speed optimization about 99% of the time.
Drop the faddish nomenclature; drop “stories” and “technical debt” and “refactoring” and communicate in plain English using terms with precise meanings. Take on responsibility, don’t be afraid of detail.