I’ve noticed a frustrating trend in online discussions about web development where developers take their personal experience with a tool or practice and promote it as a universal truth. Some of this is the nature of being human: we all see the world through our own lens. But the best technical observations exist within a specific context.
Everybody should be writing code using static types, the extra syntax is worth it because of all the bugs it prevents.
If you’re working in a large code base with many developers, static typing is extremely useful, because the overhead from writing extra code and compiler errors is more than made up for by reducing bugs and clearly expressing intent when developers edit code they didn’t write.
The first quote presents a tradeoff and declares a universal preference for one direction in the tradeoff. The second quote adds more details about the context in which the practice has been beneficial, and explains what about those circumstances (developers editing code they didn’t write) affects the tradeoff decision.
I’ll start with a distinction that folks seem better about making. Sometimes recommendations that make sense for beginners don’t work as well for more experienced developers and vice versa. For instance it might make sense to advise a more experienced developer to use and heavily configure a build system like Webpack for a new project. But beginners already have a lot to learn with each new project and might benefit from a simpler system; either a simple project without a build step, or a “batteries included” system like Create React App or Ember CLI. Making these distinctions is important for helping developers who may feel overwhelmed by all the concepts they need to learn when getting started with web development.
Another dynamic that matters when expressing best practices is the size of a team working on a project. If a project is being developed by a large team, or several teams, or is meant to be used as a library by many people, techniques like automated documentation, static type checking, and clear style guidelines may be essential. But for a personal project or a professional project run by a 1 person team, those same techniques may provide a lot of overhead for minimal benefit. Most teams will fall between those extremes and will have to weigh the tradeoffs in each case.
Some software projects are meant to be written, completed, and never seen again. For instance a promotional site for an event. Some projects, like financial software, are meant to last for decades. This is yet another distinction than can impact best practice discussions. When working on a short term project, speed of delivery and initial quality tend to matter a lot. For long term projects it may be better to prioritize maintainability, security and ease of deployment.
Thinking through the environmental factors that lead to productivity
A quick observation about what it means to write readable code