body: In engineering, in programming, in coding–in building anything that intersects with a human and a computer, context matters. It controls how a variable is scoped, how a function is called, and how styles in a CSS file might cascade and apply.
As the saying goes, "Context is everything". But despite that, it can be easy to miss or ignore context, to skim past it when encountering issues, when hunting for problems.
So much of the engineering world is building things, moving things, refactoring things. It's a lot of activities that look and behave a lot like creating, but in equal measure a vast majority of roles and jobs in the field are about finding problems, whether by intention or accident.
It's why we have "Issues" in code repositories, the name alone signifies that something is amiss. An expectation was not met, a small part of this does not easily align with that.
Finding problems is as much the momentum of engineering as anything else, and once encountered, the problem begs for the next part; finding a solution.
It is here at this transition, at the border, that I would invite you to pause. To step back and reconsider the problem you've just witnessed, the thing that is amiss and possibly blocking the work you are doing in some way.
For it is here in this space, between problem-encountered, and solution-sought that we all could do better at exercising a degree of compassion.
This problem was, in many ways, born out of the context within which it was first introduced. It may have been the after effect of an unrealistic timeline, or an unintended consequence of decisions made well outside the control and influence of the engineer that introduced it. It may have been put there, with full knowledge of its existence, but without any ability to circumvent its inclusion.
The problem in question is not necessarily the product of one person, one team, or one process. It is, as is usually the case, the outcome of an interconnected and complex system of people and technology interacting and influencing one another.
It can be easy to lean into the gravity of assuming this problem was easy to avoid, that it is a sign of poor decision making, or outright malice. That it is specifically indicative of someone or someones' shortcomings in the field. But engineering as a space of people is a place that can at times be a list of limited options, and the correct choice is not the one with zero problems, but the one that is accomplishable with the least problems, or even the least negatively impactful problems.
Moreover, despite rigorous reviews and tests, things get missed, circumstances change, and given enough time the complex system we all work within has fault lines. Problems arise that no-one expected or anticipated.
Context is key, but it is also often a mystery. In the case of an inherited system, you may be left with the problems, but little if any evidence of the context in which they were generated. You are left with the duty to seek solutions, and little reason as to why the problems were introduced in the first place.
In all of these moments, we would all do better to remember compassion, to try to embrace that we do not know the full picture, the entire context. And that perhaps those before us, and around us did the best they were capable of within the system they were a part of.
It is certainly easy to jump to conclusions, lay blame, and cast judgements at the engineers, coders, tinkerers, and builders that came before us. "Why would they do it like this?" "This is a mess!" "I don't understand what this is doing here?" It's fair to be frustrated, and reasonable to question the "why", but a bit of compassion goes a long way towards building a community of trust and well being within the larger system of building things on and around the internet.
Without compassion in these cases, we can foster an environment where people are afraid to make any mistakes. One major issue with this is that beginners, being beginners, make a lot of reasonable mistakes, and if they do not feel safe to make those mistakes then the arena of open source loses beginners, and without that it does not flourish, it does not thrive.
People, and the technological systems we create are imperfect. And the way we keep improving those systems isn't by solving coding problems alone, especially if those solutions don't come with a degree of compassion.
So, consider for a moment the next time you encounter a problem, pause for a moment and try to have some compassion, to put yourself in the place of the coder who came before, and then move on to seeking solutions with a degree of understanding across time that while we may not meet each other or share the same context; perhaps both of us were trying to make things a little bit better in what we did, and in the end we did our best to keep the system improving, code moving, and trust growing.