The quality-oriented developer
When programming large enterprise software systems, it is essential they are constructed with maintainability in mind. Otherwise, the whole system becomes impossible to comprehend, and then every bug fixed becomes two bugs added. Some developers, either through choice, inexperience, or inability, embrace the complexity, guaranteeing a system's knotty demise.
Below, I describe some of the contrast between the extremes on the range. I refer to those developers less-likely to build maintainably as the "typical developer". I use the term "QO developer", or quality-oriented developer, to describe those who write with consideration for longer-lasting systems.
Typical developers write lots of code to show how productive and professional they are.
QO developers scrutinize the value of every line and delete code where they can, since each line of code has a cost to readability and is a place for bugs to hide.
Typical developers like writing clever code to show sophistication. They believe that comments in the code are redundant, that a quick read of the code is sufficient for understanding.
QO developers recognize the effort of building correct and complete mental models, so they facilitate it by fewer moving parts, fewer dependencies, better documentation, better testing, and less cleverness.
Typical developers like getting the most features shipped out as fast as possible.
QO developers know that it takes time to let the nuances become apparent, to write good tests and documentation, and to tidy up afterwards.
Typical developers think they must consider all future possibilities, and the resulting code should be perfect and bug-free.
QO developers know all code has bugs, even the most highly-polished code. They know each feature is never really finished, but rather it should be just enough for our current understanding. When we revisit old code, we spend extra time to leave things better than we found them.
Typical developers believe that ideas in popular books and blogs ought to be followed religiously, that is, without question or deviation.
QO developers believe that the craft of programming has many subtleties and no two situations are exactly alike. Rather than relying on simplistic binary thinking, they apply critical thinking and experience.
Typical developers are excited to pad their resumes with the latest tech buzzwords to stay current.
QO developers know that maintainability requires a paucity of dependencies.
Typical developers believe in launching fast by combining as many big components as possible.
QO developers know that slow and steady approaches let them resolve more bugs and improve maintainability, and that moving too fast is likely to encumber the project with fatal levels of technical debt.
Typical developers think that automated tests are written to meet obligations by nit-picky managers or tech leads.
QO developers understand that tests are a mental tool to think more deeply about program behaviors, to provide confidence when making changes, and are a design tool. Their primary point is not the test count or code coverage, it is all the beneficial side effects that occur as a result of writing tests.
Typical developers think that code coverage is a heuristic for how well an application is tested.
QO developers understand that code coverage merely shows which lines were hit during automated tests, which can be very useful information when paired with good testing approaches. For example, if we cannot get coverage on a deeply-nested line of code, it could imply that code is impossible to reach.
Typical developers use a simplistic approach to picking dependencies, often basing their decision on popularity.
QO developers realize every dependency has costs, such as conflicting paradigms, difficulty of use, poor quality, and then the basic aspect of extra complexity from having more dependencies, and will consider the big picture carefully.