<context> Of What You Do Is As Important As <what> You Do
The What, The Who and The Ugly.
The word context within itself is a work loaded with different meanings, so let's split it out in different parts:
The reason behind an action. E.g.: to fix a slow database query, to implement a new API endpoint.
The moment an action took place. E.g.: right after a security breach was detected within a platform.
The state of mind of the person in charge of an action. E.g.: a colleague who has just started working with the company's main framework, a colleague who had to perform a hot-fix while watching the platform availability go down.
That being said, all of those items relate to one another and influence each other all the time when an action is taking place.
That is the main reason all of those items must be communicated before, during or even after the action took place.
This represents a really valuable fountain of knowledge for the person in charge of the next steps. Even if that person finally decides there are actually no more steps to take.
Now that we've got a better understanding of what context means, it would be really useful to tackle a couple of real life scenarios where its importance is paramount.
Performing reviews
It is common practice to go through other peoples code, e.g.: a Pull Request within Github, thinking how a particular action / function / method / query / could have been done 3 times better or faster or cleaner. This is something innate in a human being.
What we need to consider as well, is the context this function / method was conceived in.
A number of common scenarios to consider are listed below:
(DISCLAIMER: This is a list of real-life scenarios. It is NOT a list of excuses that will allow a professional engineer not to accept any responsability for their actions)
A function/method is written as part of a series of hot-fixes scattered around the codebase. This particular hot-fix is not given the right follow up maintenance and test coverage.
A new feature is added to the platform without enough test coverage to ensure it behaves as expected. At the time might seem something harmless, but later on might provide space for false-positives and buggy behavior when more users have access to this functionality uncovering corner-cases not planned out by the team nor discovered earlier via testing (unit/request/feature).
A combined index is set in place within a table with tens of millions of records by a junior developer who didn’t have the full scope of the platform in mind, missing out on the consequences on performance and scalability of this decision.
Follow up actions
Now that we know the reasons for each scenario above, we not only have information about the team’s strengths and weaknesses, we also have made a significant step forward into preventing these kind of issues from happening again.
A list of preventive (and constructive) actions to consider would be:
Introduce Post-Mortem Reviews with a Context Focus
After resolving critical issues (like hot-fixes or performance problems), conduct a post-mortem analysis focusing on the context in which decisions were made. Discuss not only what went wrong but also the pressures, constraints, or knowledge gaps that influenced the decisions. Document these learnings and share them within the team to improve decision-making processes and avoid repeating the same mistakes.Experienced Engineer/s Reviewing Colleague’s work
And providing feedback while they do it. This way, within time, knowledge is distributed among more engineers reducing the chances of “silo” style of knowledge among specific people, further reducing the chances of engineers work being blocked because, for example, they need a specific-set of knowledge that only one engineer posses and they just happen to be on vacation.
Implement a Mentorship or Pair-Programming System
Pair junior developers with more experienced engineers through a formal mentorship program or pair-programming sessions. This setup helps junior team members gain a deeper understanding of the platform's scope and best practices while reducing the likelihood of decisions made without sufficient knowledge of the system's impact. Regular pairing sessions also promote continuous learning and stronger collaboration.
Final thoughts
Embrace every opportunity to understand the context behind the work you do and the work of others. Ask questions, seek feedback, and participate in discussions that uncover the reasoning behind decisions.
Over time, you’ll grow more confident and knowledgeable, equipping yourself to contribute meaningfully to your team’s success.
As always, keep collaborating, keep writing, keep learning and building something you're proud of.
Stay safe,
Juan.