Ego-driven construction
Unlike the problems of the image-driven pitch approval process, ego-driven construction can happen on a project whether or not it needs external funding. Ego-driven construction is about leaving a mark or getting recognition for your work.
The need for recognition is strong, but the need to do a good job should outweigh it. On some projects, obvious candidates for a development team can and will be uninvited to join due to their demand to imprint on the project. Bring your skill, not your ego. True virtue does not need to win. Good code is usually devoid of ego. Code signed by an author is either left alone when we should fix it, leaving tension in the codebase, or believed violated when modified away from the original state, leaving tension in the workplace.
Quality comes from an intensely personal pride. It does not come from coin or celebrity—the pride we take in our work is not showing off. It’s about living up to our standards. We have examples of builders who built out of necessity where that necessity called for harmonious, impressive structures only attainable by working under a shared vision.
In the past, the most beautiful and profound constructions were those built for religion. Not just places of worship but also objects, monuments, and songs. Ego did not play such a significant part in their building, even if a person of ego commissioned it. These days, an egoless creation is driven by a need to express an idea or truth. Thus, we hunt for meaning in art because wealth has appropriated simple beauty for conspicuous consumption.
Great work is done on a large scale when everyone has the same goal and creates with the same principles. Everyone must understand what is important about what they are making and why they are making it. Workers could tell they were doing the right thing when building structures as part of a religion, and they could confidently call out and correct those who weren’t. Though some might think of this as a religious or spiritual feeling, it’s simpler and more secular than that. It is to be consumed by an ideal.
But you don’t need a grand vision to create without ego. Creating something that pleases you is selfish, but if it really is for your pleasure alone, it will also be egoless. An old pair of slippers or a worn-out bathrobe is a selfish but egoless pleasure. It’s not glamorous, as glamour is for others, even when done for yourself, because it’s based on cultural expectations. Egoless creation is evaluated on its direct ability to please and satisfy needs. However, egoless creation needn’t be selfish. The ideal that consumes you can extend to your family, friends, and community.
Fear of death
Things become ego-driven when our transient, temporary selves are the beneficiaries of what we create. Not so much our bodies or our way of life, but ourselves, our identities. So, in this form, the ego-driven way of producing is terrible because it’s all about us as unique people who want to be admired rather than about the intrinsic qualities of the result or its benefit to us. How other people view us is a poor metric to measure your life by.
This links to why patterns began to fail. Many wanted to write patterns because they would be recognised as someone who had authored them. It would lead to others doing things their way. People want to be in control. The promise of someone using their patterns was an incredible ego trip, even if they didn’t ever directly see the patterns being used. I believe it’s why so many patterns weren’t as well-curated as they should have been—people wanted to show off their cool ideas or be notable.
Many humans fear death. So many wish for immortality. Being remembered or having your signature on a thing plays into that. It’s about exposure, security, and the chance for more work later. It can be about leaving a legacy. We want to believe that when we have designed something, it was good. We want a pat on the back and a ‘well done’.
A competition about naming things
Even aspiring to a aggressive disregard for originality[PLoPD3-97], the pattern fans were affected by the ego-driven way. The movement trampled its own principles underfoot, turning into a hunt for all the nameable things. Naming a pattern of code or methodology gave better rewards than refining the concept of patterns itself. So, rather than extend and resolve in the way Christopher Alexander did with the transition to the fundamental properties of forms, the concept became diluted and diminished under the hooves of the many who wanted their names on articles.
Naming became the game. Naming became the value. This naming aspect became so prevalent that many now see it as the point of design patterns. I’ve protected the identity of the author by rewording this statement, so it cannot be web-searched, as I don’t wish to persecute anyone, but this opinion is not rare:
Design patterns allow you to communicate software design by offering you a common vocabulary. As a member of a team familiar with design patterns, discussions about design become very productive.
As an example outside of software:
Can an architect effectively discuss a house without using patterns for different types of rooms? When they say, ‘a house with two bedrooms, a kitchen-diner, and a bathroom’, they provide a lot of information in very few words.
Software design is the same.
Source intentionally obscured.
Hopefully, anyone who’s read this far can see the problems with the statement. The first would be that there are no bedroom, kitchen, or bathroom patterns. There’s not even a pattern of the house. Houses are a given. They already had a name before any patterns came along. Patterns name the relationships or organisations of elements given a problem. But clearly, a lot of people are listening and nodding along. Names are essential, and being able to name things is a powerful tool. Being able to communicate meaning enables other perspectives, evaluations, and interpretations.
So, names are valuable. Why not let this be? Why not recognise patterns as both naming things and problem-wisdom too? We should be wary because this dual meaning led to its absorption into the dominant meme of naming things. When design patterns are just names, we under-develop them, perpetuating the problem. And when they are names, they inevitably refer to the solution, the goal, not the problem.
The pattern people may have been looking for behaviours to claim, hunting for new, valuable, and unique things to give names to. They didn’t take the next step, to combine and refine the spoils of their hunt to distil the fundamental properties of software patterns. They simply continued to hunt. Their task drifted into cataloguing and publishing articles with named authors. And there lay the ego: in the name at the end of the article or the front of the book. So, the race to extract value destroyed the reward.