In the realm of software engineering, there exists a unique breed of engineers known as pragmatists. These individuals possess a distinct approach to their craft, blending technical expertise with a grounded mindset that sets them apart from their peers. But what truly sets a pragmatic engineer apart? What is it about their approach that makes them so effective in navigating the complexities of software development?
To answer this we will dive into the provoking thoughts and ideas inspired by the books The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin and The Pragmatic Programmer: Your Journey To Mastery, 20th Anniversary Edition (2nd Edition) by David Thomas and Andrew Hunt.
At the core of pragmatism lies a set of behaviours that define the pragmatic engineer. One such behaviour is being an early/fast adopter. Pragmatists eagerly embrace new technologies, swiftly grasping their intricacies and staying ahead of the curve.
Curiosity is another characteristic that fuels the pragmatic mindset. Pragmatists are inquisitive souls, always ready to question and seek understanding when faced with unfamiliar concepts or challenges.
Critical thinking is a cornerstone of pragmatism. Rather than accepting solutions at face value, pragmatic engineers apply their analytical minds to evaluate and challenge proposed solutions, always on the lookout for more elegant or efficient alternatives.
Pragmatists also possess a keen sense of realism. They strive to understand the underlying nature of the problems they encounter, grounding their solutions in practicality and addressing the true essence of the challenges they face.
Embracing a broad spectrum of knowledge is another defining trait of the pragmatic engineer. Rather than limiting themselves to a single technology or domain, they actively seek to expand their skill set, becoming a polymath who can adapt to a wide range of contexts.
By understanding these foundational behaviours, we gain some insight into the pragmatic philosophy. It is a mindset that values adaptability, practicality, and a continuous thirst for knowledge. Now let’s explore the intricacies of the pragmatic engineer’s thinking, unraveling the secrets that make them such effective and versatile engineers in the ever-evolving world of software development.
In the first series of the blog post we will delve into the first three key aspects (Cat ate my source code, Just a broken window and Make a stone soup), providing sufficient time for contemplation and assimilation. Subsequently, in the next series of the blog post, we will examine the remaining three aspects (Good-enough software, Knowledge portfolio and Talk the Talk) and conclude with some final thoughts.
Enjoy the enlightening journey ahead.
Cat ate my source code
Can you imagine a cat eating the source code? How does that statement sound to you? Do you find it silly, funny or maybe even stupid? Well, that is the same way your colleagues will feel if you try to make excuses for the mistakes you made. Never make excuses, forget that the word excuse even exists. As a pragmatic engineer you are in complete control of your career and you take full responsibility for the work you do. There’s a saying that if you don’t make mistakes it means that you’re either playing it too safe or you’re not playing at all. Mistakes are inevitable. They are the integral part of doing the work and growing as an engineer. Your team will forgive you for the mistake you made, but they won't forgive or forget if you don't take responsibility for it. It’s how you respond to a mistake that makes all the difference. Accepting that you made a mistake and taking the responsibility publicly is not the most pleasant experience, but you should be truthful, direct and never shy away from it.
Here are some ways that pragmatic engineers deal with mistakes and responsibility:
- Choosing Options over Excuses:
- Pragmatic engineers prioritise finding options rather than making excuses.
- They avoid labelling something as impossible and instead approach challenges with a curious and can-do mindset.
- Asking Questions and Preparing Options:
- When faced with a difficult situation, pragmatic engineers ask questions to gain a deeper understanding.
- They prepare options and alternatives to tackle the problem effectively.
- Refactoring or Removing Project Parts:
- Pragmatic engineers consider the possibility of refactoring or removing certain project components if necessary.
- They investigate, create a plan, assess risks, estimate impacts, and present their findings to the team.
- Assessing Needs and Implementing Improvements:
- Pragmatic engineers identify the needs for proof of concept, enhanced testing, automation, or cleaning the code base.
- They proactively address these requirements to prevent errors and optimize processes.
- Seeking Resources and Collaboration:
- Pragmatic engineers are not hesitant to request additional resources or seek help when needed.
- They aren't afraid to admit when they lack the skills to solve a problem and will ask for help instead.
- They understand the importance of putting in effort to explore options, ask for support, and leverage available resources.
💡 Just for thought: How do you react when someone gives you a lame excuse? Do you start losing trust?
Just a broken window
Why are some projects falling apart and inevitably increasing their technical debt? Even if they have the talented people and the time, so what is the problem? Have you heard about the broken windows theory? The social criminology scientific research states that if a building has just one broken window left un-repaired for a longer period of time, it will create an environment that encourages further window breaking. This is as true in nice neighbourhoods as in rundown ones. Multiple broken windows will create a sense of negligence that will then result with more civil disorder such as trash left out or graffiti on the building walls. In relatively short period the apartment owners will get a sense of hopelessness which will result in negativity spread, creating a contagious depression. As a consequence, that part of the neighbourhood becomes associated with being unsafe, and ultimately, the building gets abandoned.
Here is a reflection of the theory on the technology world:
- The broken windows theory applies to software engineering projects as well:
- Un-repaired broken windows such as bad design, wrong decisions, or unclean code contribute to technical debt and system entropy.
- Technical debt decreases efficiency and throughput of the team and it increases dissatisfaction and frustration, potentially leading to more technical debt and an unsuccessful project outcome.
- Psychology and culture play a vital role:
- In projects filled with technical debt, it's easy to pass blame and follow poor examples (easy to say “Well it’s not my fault, I work with what I have, I will just follow the example”).
- In well-designed projects, a natural inclination arises to maintain cleanliness and tidiness
- Pragmatic engineers resist causing further damage:
- They don't allow deadlines, high-priority issues, or crises to push them into increasing the project's collateral damage.
- They adhere to The Boy Scout Rule from the book Clean Code by Robert C. Martin.
- They diligently track broken windows and create concrete plans to fix them.
- They don't think “I'll improve this later”, and trust that it will be done. They create tasks for things to be tracked and tackled in the future.
- They demonstrate care, effort, and a resolve to address known issues.
💡 Just for thought: What did you do the last time you saw a broken window in your project? Did you do some action to repair it or did you look the other way and thought it’s not my fault that it’s broken?
Make a stone soup
In a well-known European folk story, hungry strangers visit a village seeking food. The villagers refuse to assist, so the strangers, having only an empty cooking pot, light a fire. They place the pot on the fire, filling it with water and a large stone. As the strangers gather around the boiling pot, the villagers, being curious, slowly start approaching and asking questions. The strangers tell the villagers that they are preparing a “stone soup” and even though it’s a complete meal on it’s own they encourage them to bring some vegetables to make it even better. The first villager, who anticipates enjoying a share of the soup, brings a few carrots from his home. Quickly after, follows the second and the third villager bringing their share of onions and potatoes. Becoming even more convinced by the actions of the first three, more and more villagers start bringing tomatoes, sweetcorn, beef, salt and pepper. Finally, making sure that the soup is ready, the strangers remove the stone and serve a meal to everyone present.
What is the moral of this story?
Would you say that the villagers got tricked into sharing their food?
Why is it important in the context of software engineering?
The tale teaches a moral lesson about the power of collaboration and generosity. However, in the context of software engineering, the story could be used as an analogy to emphasise the importance of teamwork and resourcefulness in problem-solving. Just as the strangers in the story creatively used their limited resources to provide a solution, software engineers often need to think outside the box and work together to overcome challenges and deliver successful projects.
Here’s how pragmatic engineers make the stone soup:
- Challenging Others and Communicating Vision:
- Pragmatic engineers face the challenge of rallying others to contribute and align with their vision.
- They draw inspiration from the tale of stone soup, emphasising the importance of proactivity and resourcefulness.
- Acting as Catalysts for Change:
- Pragmatic engineers take the initiative to create an initial proof of concept and lift ideas off the ground.
- They actively work towards gaining buy-in from their colleagues.
- Inspiring Others and Transforming Vision into Reality:
- By presenting a glimpse of a promising future, pragmatic engineers inspire others to join their cause.
- They collectively work to transform the shared vision into reality.
- Creating a Win-Win Situation:
- Through their efforts, pragmatic engineers create a win-win situation that benefits everyone involved.
💡 Just for thought: Have you ever made a stone soup for your team? How did they react?
End of part one
Are you filled with anticipation to discover the remaining aspects? If so, consider yourself fortunate as the second part of the blog series is just around the corner. Take this time to reflect on the insightful aspects discussed in this blog. Challenge yourself to apply at least one of the ideas you found most intriguing. Remember to hold yourself accountable and engage in self-reflection after a few weeks to assess your progress. Even a slight enhancement can lead to significant growth. Allow these concepts to simmer in your mind, ready to inspire your actions.
“Start by doing what is necessary, then do what is possible, and suddenly you are doing the impossible."
Saint Francis of Assisi
In the upcoming blog post we will explore deeper into the topics of Good-enough software, Knowledge portfolio and Talk the talk.
Until next time, stay sharp!
