Programming as an environment
Most methodologies treat programmers as a fungible resource. However, junior developers are developers too. If working in the environment requires you to be senior to work safely and make real progress, then the environment is hostile.
Software inhabits multiple worlds; different entities inhabit each environment. Each class of entity has different values and senses of beauty. Sometimes, the inhabitants have a long history with the space and know what is good for them. For example, users know a good UI when they use it as we’re used to using tools with our hands and eyes and getting feedback on our actions.
In other cases, the inhabitants have little experience of their world. Inexperienced programmers must work with source code for quite a while before concluding whether it is good. They need help identifying what is good for them. They must internalise the necessary values and judgements defining beauty for that environment.
In physical architecture, symmetry is an indicator of quality, as is geometry. Any architectural pattern language needs geometry because it’s about physical space, dynamic entities, and their activity. Symmetry and geometry make the unfamiliar easy to understand. Why? Because things with symmetry are predictable and take up less cognitive space than semi-chaotic things.
Code structuring is about creating software with others. It’s not about the geometry of spaces taken up by people in a physical way but about passing work between each other and relieving cognitive load.
When constructing buildings, symmetry can determine where things go. It’s how things indicate their purpose and what belongs beside them. Breaking symmetry points out exceptions. In code, instead of symmetry, we have something equivalent; we have variation and commonality. We have architectural guidelines that define where things belong and their default appearance.
So, breaking symmetry in construction is information for the end user, and
variants are information in code. It’s how we decide whether to apply
Those who thrive
Your code base is an environment. As such, certain types will struggle, others will survive, yet others will thrive. Do those who thrive or survive create a better or worse environment for the kind of people you want on your team? The organisation is also an environment. The ‘org chart’ and the building that the team works from count towards the environment. How you reward the team and handle failure are as significant to the inhabitants as linting tools and source control. Your organisation could spend thousands on extravagant outings and team-building exercises or, instead, listen to its members and spend less by improving access to testing hardware.
Decide based on what you are making. How should you build the environment to best suit the people you need to make it happen? For example, is your project a conundrum? If so, you want puzzle solvers to thrive. But if it’s a user-facing project, you should cater to those who care about disambiguating and iterating over UX requirements.
However, regardless of the project, there are types you always wish to support and others you never will. Some people care about improving things and we should nurture them where we can. But beware those who want to show off how clever they are as that rarely translates into value for others.
Paper trail
In physical construction, it is normal for older buildings to show their age through nonconformity to modern standards. You can say the same of legacy code. You can tell by its lack of tests, usage of modern language constructs, and older or less consistent naming or style.
What does your code say about the people who worked on it? Are they clean coders, or do they write only the necessary code to achieve the goal? Are they quick workers, leaving functional but difficult-to-reason-about functions full of difficult-to-read short names? Just as we excavate ruins to discover more about the lives of those living in buildings long buried, we can learn about the people who wrote the code by the evidence of their values realised in the lines of source in a project.
If you’re unaware of the environment in the code and around the humans developing it, you’re missing an essential set of patterns for productivity.