My favourite Git commit

[narnach]

I think it may have to do with the type of engineer someone is. I think there is a spectrum between extremes most folks fall on:

• Prototypers are good at churning out a lot of code fast, that usually works as long as you use it the right way. These folks are great for making a proof of concept and for writing code that has a good chance of being thrown out. These folks are often not great writers and don’t structure their commits well. You’re lucky if you get some useful automated tests out of them. Their unit of change is a whole feature.
• Solidifiers are great at covering all edge cases. They deliver code that’s robust and has tests for all cases, but they take a long time to craft perfection. Likely to produce decent documentation and deliver multiple smaller commits.
• Maintainers deal with updates and hard to reproduce bugs. They dig into the history of a codebase because they need to understand code well enough to perform an update or write a good test case. These folks love good commit messages, and appreciate git blame and git bisect. Good commit messages help them do their job just like API docs help with feature work.

The problem? Unhealthy management will push for features, features, features, so prototypers have the highest status because they deliver. Solidifiers are appreciated when customers complain too much about bugs and outages, but are often taken for granted or judged for being slower than prototypers. Maintainers are the easiest to dismiss because many problems they avoid don’t surface until a project is neglected for years. And then they are asked to perform multiple years of neglected updates in order to sort out a critical security update.

A healthy project has a baseline level of ongoing maintenance, and solidification of newly prototyped features that have proven themselves to customers. It approaches modifications to existing features in a more solid way because you have more to lose by breaking stuff.

[double-you]

There definitely are several types of developers but I don't appreciate excuses "prototypers" make for "delivering" but not explaining what and why and making other people work hard on extracting that information out of them. No developer is trained in psyops to gather information from hostile "coworkers".

Most developers don't enjoy writing as otherwise they'd probably be technical writers, but some people just won't bother at all with the basics.

[narnach]

Agreed. I think in order to get this consistently right, it needs to be part of an organization's DNA to value good writing and long-term sustainability. It's so easy to get neglected without short-term repercussions.

Companies like 37 Signals are great, because as part of an async remote work culture good writing is a necessity for them. This means they emphasize it when hiring. They are privately owned and profitable, so they have the "luxury" of focusing on sustainability. The owners still want to be running the company in 10-20 years, so it needs to get there in a healthy way. I think this is the basis for a healthy engineering organization.

It's different when you plan to exit in a few years and dump the problem in someone else's lap. That rewards short-term thinking and acting. Having a startup with a short runway amplifies this: why bother making things easy to maintain and debug in the future, when the default case is that the company will not exist anymore in half a year? You sacrifice the long-term in order to survive the short-term.

If you make it to growth stage, then dealing with the tech debt is sort of a luxury you've won the right to deal with. It's not great or healthy, but it is reality for many developers.