We show respect for our customers and fellow software crafters.
We do not act unprofessionally or unethically. —from the 8th Light Principles of Productive Partnerships
Whether you are the type of person that agrees with and champions the ideas and language found in Uncle Bob's The Clean Coder or Sandro Mancuso's Software Craftsmanship: Professionalism Pragmatism Pride, or the type of person that points out the risk of egoism and romantic ideals about craft clouding the aims of the Software Craftsmanship movement, or moreover, the type of person that does not identify with the medieval guild-inspired language often used to describe Software Craftsmanship, I think we can all agree on one simple idea: the heart of Software Craftsmanship is reducible to professionalism, delivering excellence and doing so consistently. And demonstrating these attributes really boils down to respect.
Collective Reduction
The weight and pressure of an entire production system failing in real time is too much to bear for one individual. Collective ownership of problems in large scale systems helps reduce the pressure and stress of problems. This collective reduction of pressure is one way we can demonstrate our respect for our colleagues while promoting the best quality work and value for a business.
It's a regular Tuesday working on site with my client alongside their developers, product owners and quality assurance team. All system monitors indicate production performance is good. I pull a story from the top of the backlog and begin happily churning through a new feature request.
A little later, I notice a message in the devops chatroom asking about errors in production. Next came that feeling of sudden dread as reporting hooks flooded the devops room with red alerts from our system monitors. A specific portion of the application was failing and returning a steady stream of HTTP status 500 responses for every request. Instantly everyone disengages with their stories and the team unifies together to identify the problem.
Within a minute or two the application endpoint responsible for the errors was identified. As a team we huddled around the stack trace and began picking apart the problem. Those with more domain knowledge of that part of the system began volunteering potential causes. Eventually the root of the problem was determined - data was corrupt! Answers always bring more questions, but we then knew where and why the errors were arising and that allowed us to begin thinking about a potential solution.
The collective ownership of this production issue gave everyone more mental room to think, read the stack traces, re-read the stack traces, and make better-reasoned suggestions about potential causes of the problem. This collective reduction saved my team time in troubleshooting and yielded higher-quality and more accurate answers to what was a tough problem. We show our colleagues respect every time we contribute to the collective reduction of pressure, problem complexity or knowledge gaps.
No Substitutes For Domain Knowledge
When teams are sprinting hard and building up large, complex systems, it's natural for some members of the team to build up a specific part or corner of the system. Usually this results in a few members of the team having most, if not all, of the domain knowledge. When this occurs in a team, this fragmentation of domain knowledge represents a form of technical debt that must be paid when other members of the team first begin working in that unknown domain.
I recently worked on a bug in a client project that dealt with an aspect of the system I was not familiar with. I had a small amount of domain knowledge, but I was not included in the numerous hours of discussion concerning the relevant business logic and had never seen the code. This portion of the application was large and operated under a complex set of business rules, and represented a critical component of how the business made money. As a professional, I knew that before I could identify the cause of the bug, I needed a mental model of the business logic and a high-level overview of how that portion of the system's code was structured so that I did not inadvertently create more bugs and cost the business more money.
I discovered that this portion of the system was largely written by one individual. I had spent some time looking through the code and familiarizing myself with the structure so I could begin to reason about its responsibilities before I sent an email asking for some of that developer's time. I knew they had their stories and commitments to meet, but I knew I would not be able to complete my commitments without some of their domain knowledge.
The developer agreed to meet later in the day. They provided a quick overview of that portion of the system and provided a highlights tour of the code to identify likely causes for the bug. In about thirty minutes I learned more about the business rules and the structure of that code than I would have learned in three hours of working by myself. Because of that domain knowledge transfer, I was better able to reason about the code at a deeper level than I would have otherwise been able to, potentially saving time or future bugs from occurring.
It's not always easy or convenient to share our domain knowledge with our team. As software professionals meeting our commitments, we have to balance our responsibilities with the requests of others. Yet, it's important to remember that there is no substitute for domain knowledge, and we demonstrate a great deal of respect for our colleagues when we give our domain knowledge away. This not only improves the ability for every team member to contribute to the system as a whole, but also helps reduce the risk to a business in the event a key developer leaves.
Be A Rubber Ducky
The teacher always learns more than the student. We bring a tremendous value to our colleagues and show them respect when we allow them to explain ideas or describe a complex problem. Often the process of working through the intricate details of a problem by explaining it to a peer reveals more nuance and depth than we usually imagine while working alone. The feedback we receive from our colleagues can also help us identify potential problems or edge cases we might not have considered otherwise, helping save developer time and money.
Prior to becoming a software developer, I spent a couple years as an English teacher in South Korea. I quickly learned that one of the best ways to evaluate students' comprehension and understanding of the lesson material was to ask them to explain a key idea to their peers. If they were able to explain the idea to their peers, I reasoned that they had taken the first and most difficult step towards achieving ownership of that idea, and it now served as part of their greater mental model for acquiring English as a second language.
As developers we have to acquire new technologies and skills continuously to stay relevant. When we learn a new technology or tackle a new problem for the first time, it is often helpful to explain something about that technology or problem to a colleague. The process of explaining a complex subject to a colleague forces us to slow down and consider each step. Not only does this have the benefit of illuminating our blind spots or holes in our knowledge, but it also forces us to consider the topic at a deeper level than would normally be required. This is because in order for our colleague to understand what we are explaining, we have to go beyond a superficial level of understanding. Instead, we must organize information about the topic into a coherent picture that can be easily relayed. In other words, explaining forces us to create a mental model of the topic.
One of the best ways we can help assist each other in this process of continual learning is to take on the role of the rubber ducky when a colleague wants to explain an idea. Not only do we gain benefit from the opportunity to learn something new, but we become a willing participant in the growth of a colleague. Expressing our confusion or uncertainty about an explanation further helps our colleague refine their mental model, while also allowing us the ability to gain a deeper understanding of a potentially new technology or problem.
And Smile While You Do It
Whether we're helping collectively reduce the pressure of a tough problem for our team, sharing knowledge with a fellow developer, or playing the part of a rubber ducky, a smile goes a long way to provide simple acknowledgement that we care. Smiling while we demonstrate our professionalism and our respect for one another may also make us happier too.
We at 8th Light are principled. This is one of the principles we follow.