Observe better phenomena
Wisdom helps you see things. Patterns help you see things if you know about them. When you don’t, you can still think about what might be overlooked and use it to guide you to thinking about what phenomena currently slip by undetected.
In range
In range means close enough to see. You might not be able to see what’s wrong from 100m away, or you might only be able to see from a vantage point placed even further. One millimetre is too close to see what’s causing some problems but not close enough for others. The thing you perceive will depend on how far away it is. This is like the wood for the trees saying. From the window of the oppressive castle, the village can look happy and idyllic.
Some development methodologies overlook this aspect of range. In Scrum, they take a perspective of nearby in terms of the product owner—the most important thing to them right now. It can be challenging when structural changes are essential but never the next most important thing until they are suddenly late and urgent.
In other development methodologies, the range can be much greater. The goal can be quite far away, and all the problems on the way there become invisible at that scale. Unexpected issues are bound to turn up. Here, the lack of local observation leads to fewer high-level mistakes, but with so many local problems, it has a higher ultimate cost.
Another extreme is the bazaar-style approach to developing an established software product1. It has many contributors and one director. Each contributor will have an idea of what will make the product better locally but will likely only have a very myopic perspective of the whole product. The contributors are all highly tuned end users with different use cases and priorities. This is why the bazaar methodology requires a leader who is aware of the general situation for all and has a well-restrained ego. Their ego would fight against the best outcomes, as it would put the value of identity over the product’s value. In bazaar development, the recognition and identity of each contributor is often quite important and must be respected by those with their hand on the tiller.
Domain contrast
Due to our perspective, what we care about also indicates what we don’t or can’t care about. We need the UX team to feel they can tell the product designers when the experience of their users is no good. With critical feedback, we can avoid introducing complicated workflows. We need the security team to be able to contribute to our design process, so we don’t miss legal requirements with far-reaching implementation implications. Our programmers must inform content creators when the assets they create are too expensive for the target platform. Without these alerts, much work remains hidden until too late.
Sometimes, we need an astute outsider or intermediary to help those on the inside perceive. Outstanding issues must be translated and communicated to those who cannot sense them. The intermediary can be a person, a specialist or consultant, or simply someone added to a team to be the eyes for a particular domain. Other times, it can be a program we regularly run or an active indicator generating relevant and real-time notifications in a tool we use.
What you always see
Many works on software development will have some assumptions built in. Older works assume a procedural programming paradigm. Modern books mostly assume an object-oriented architecture. Future books may assume functional programming is the norm. That’s an unknown for me. But notice they all agree on programmers programming in a programming language.
One realisation I have had over the last few years is that there are two main types of programmers: the specialist programmer, who is well-versed in a piece of software, a language, or a subject matter such as algorithm design; and the glue programmer, who is more of a generalist but plugs things together nicely. Each type has strengths and weaknesses. When I first started programming, there was only one type of programmer: the programmer who did it all. There were more types around; I just couldn’t tell because I didn’t know how to discern between them.
I recognise the specialist in me. I might know quite a few different things due to the varied demands and the nature of game development, but in general I know only a few things but know them deeply. I find I need a lot of help to learn a living codebase quickly. Those who can pick up new things fast are more suited to the application developer role. They might not have the attention required to internalise complicated connected knowledge, but they have the mental flexibility to jump between tasks, levels, and roles, which makes them indispensable in a modern application development shop.
This leads back to the section title. We always see something and assume it’s the norm. I saw programmers who did a bit of everything and thought all programmers were like that. We assume how things are is how they should be, but that’s wrong on two counts. Many people learn programming these days, but not many are suited to become specialists or management, and there’s no uplifting career track for people who build lots of small things well and fast. The way in which we compensate people is stuck in the values of the past, stuck in what we always see.
It’s true everywhere, not just in software development, even in the works of
Christopher Alexander. Recognisably, Western patterns dominate
If we continue writing about how things are rather than finding a formula that works regardless of the variables inside it, then we are doomed to find a mirror for ourselves. You can learn much from mistakes, less from success, and even less from a successful repetition of a prior event.
What you cannot even see
Darkness is an absence of light. If you have never experienced light, you will find it difficult to comprehend the impact of darkness on people. You can understand it intellectually, but the closest approximation might be the loss of perception when you are effectively deafened by being in a loud environment.
The problem is we are missing the extra information only perceptible when we have internalised the connections and meanings of the observable facts. For example, when listening to a conversation in a foreign tongue; you cannot decipher the content or meaning. It’s often possible to speculate on the mood of the conversation without understanding the language, but even then, it’s still guesswork.
Whatever you are unable to experience, for whatever reason, denies you the chance to see what is missing, even if it is affecting you. Just as someone completely blind is unlikely to be afraid of the dark, someone with no experience in concurrent or parallel processing will likely not fear race conditions.
Becoming conscious of higher-level concepts is only possible when you can perceive and understand the foundations. When you don’t understand basic mathematics, there’s little chance of recognising the impact of statistics and probability on your decision-making.
All this is also why the principles from the
Always ask questions about how a project will work in the end, not how each piece will work. I always prefer testing work when it is integrated rather than asking for acceptance in an isolated testbed.
Swimming pools for kids by the sea
The importance of things can sometimes only be seen by those close to the problem. People might ask why you need a swimming pool in a coastal town when the kids can swim in the sea instead. The problem isn’t apparent until you think about swimming lessons.
The more context and awareness of a problem you have, the fewer solutions will seem appropriate. When you do not understand or consider all the purposes of swimming pools, you may de-prioritise them where they are necessary and provide them where they are not. If those in charge don’t know why a community wants something, that doesn’t mean it’s frivolous. Understand the community. Make sure they know you want that education.
If a person in a leadership role doesn’t understand the impact of their decision to de-prioritise something, then it’s your duty to correct them, to help them see what happens when they commit to those actions. A computer game producer putting off localisation until all the strings in the game are finished might have to be informed of the costs incurred by their scheduling. A product owner delaying bug fixing may not know how technical debt accrues interest, how bugs get more complicated to fix the longer they hang around, and how tasks in a clean codebase are more accurately estimable. A project manager who delays optimisation may not know that earlier optimisation work leverages faster development or simplifies later optimisations.
Two things are going on in these situations. Disconnected experience in the domain means outcomes foretold by others aren’t foreseen by those making the decisions. And there’s an inability to see alternative usages from how you usually observe things. This aspect is not quite as bad as functional fixedness, but in the case of a swimming pool, the person making the decision may think it is solely for the purpose of recreation. And when you put the pool into the category of leisure and pleasure, the idea of cutting funding when there’s a beach nearby makes perfect, tragic sense.
When reviewing tasks and someone, not a decision-maker, pipes up with concerns, or even if you hear murmurings of discontent, listen harder. Ask questions revealing your missing knowledge. Without awareness, you will make bad decisions. Find the reason why there’s anxiety in the team and figure it into your decision-making process.