As a software engineer, I've been fortunate to work on complex projects with teams of exceptionally talented people. At times, the work we do seems almost magical; there's an unparalleled sense of accomplishment in creating something that will reach millions of users worldwide, even if it's something as small as changing the color of a UI button. The profession offers financial rewards and a never-ending supply of mental challenges.
Alongside that, we also encounter a relentless stream of seemingly insurmountable requirements, pressing deadlines, and the occasional stubborn bug that evades extermination. There are days when we ponder if actual spaghetti has fewer entanglements than the cruft we've managed to bang out on our keyboards. Achieving balance amidst the highs and lows is vital not only for our professional success but also for our personal well-being.
Something that has aided me in navigating the vicissitudes of life and bits, from personal relationships to software engineering, is the collective set of principles from Don Miguel Ruiz's books "The Four Agreements" and "The Fifth Agreement." These five tenets—being impeccable with your word, not taking things personally, avoiding assumptions, always doing your best, and maintaining skepticism while listening—guide individuals toward personal freedom, inner peace, and self-mastery.
The Agreements are designed to help people break free from negative thought patterns and the doldrums of an unfulfilling existence. If you haven't read these books, I strongly recommend them for their simplicity, insights, and unpretentious prose. In this article, I hope to do justice to the combination of simplicity and usefulness found in the books.
Be impeccable with your word
The single biggest problem in communication is the illusion that it has taken place.
— George Bernard Shaw
In everyday life, being impeccable with our word means maintaining integrity, keeping promises, and communicating respectfully and accurately with others. This practice helps us build strong relationships and foster trust among those around us. These are the moments when you consider not only the honesty of your statements but also their impact.
Fortunately for software engineers, the precision aspect of this agreement comes fairly naturally. Our work often demands clear, concise, and unambiguous exchanges of information to ensure successful project outcomes. The act of writing code is unforgivingly inflexible. Whether it's off-by-one errors, floating point precision, or memory leaks, software engineers are practiced in identifying the massive impact of seemingly tiny details. A single poorly written integer conversion can cost billions when a rocket fails only 37 seconds after launch and removing an 11-line package from npm can “break the internet.”
But, of course, being impeccable with your word means being truthful and conscientious in our interpersonal communications, as much as in our code. This principle is applicable when discussing project requirements, providing status updates, writing code comments, and giving each other feedback and recognition. Poor communication could cause strained working relationships or cost a junior engineer their self-confidence. As crufty as someone’s code may be, it is likely neither accurate nor helpful to describe it as “hot tier garbage” (an actual critique that I saw in a code review a few years ago.). By ensuring accuracy and conscientiousness in our communication, we build trust with our team members and create a positive work environment.
Don't take anything personally
I’m not in this world to live up to your expectations and you’re not in this world to live up to mine.
— Bruce Lee
It is crucial to decouple ourselves from the opinions and actions of others, which allows us to sidestep unwanted emotional distress and concentrate on our personal growth and well-being. Fans of the modern revival in Stoicism will undoubtedly appreciate the potency of this approach in their lives. As Epictetus once said, "We cannot choose our external circumstances, but we can always choose how we respond to them."
We frequently take things personally when we assign a semblance of reality or danger to a particular event. Imagine if you were to experience someone's behavior or unkind remarks coming from a toddler—a little human who most likely lacks the knowledge, awareness, and authority to genuinely harm you with their opinion. I’ll admit their brazen honestly can sting, but you’re much more likely to dismiss the toddler’s criticism with a chuckle than you are with the same criticism from a coworker or peer. By recognizing the true source of our distress is in our perception and that not every comment is a reflection of our true worth, we can navigate life with a sense of stoic equanimity, like a modern-day Epictetus.
In the realm of software engineering, feedback is as inevitable as gravity, whether during code reviews, design deliberations, or, compiler help us, an outage of our own making. Our code and ideas will frequently face intense scrutiny and intellectual challenges. It's crucial to perceive these critiques as opportunities for growth rather than personal attacks, remembering that it is our work being questioned, not our identities. And our work is something we can improve.
Taking criticisms personally obstructs our ability to focus on the necessary improvements and can lead to unnecessary retaliation. By refraining from taking things personally, we can maintain a positive attitude, remain open to critical feedback, learn from our mistakes, and continually enhance our skills.
Don't make assumptions
The only true wisdom is in knowing you know nothing.
— Socrates
In our personal lives, not making assumptions can help us avoid miscommunication and strengthen our relationships. By asking questions and seeking clarification, we can better understand others' perspectives and intentions.
Making assumptions in software engineering can lead to misunderstandings, bugs, and project delays. If you've been coding for a while, you've likely stumbled into the trap of trusting a fossilized code comment that has as much in common with the current implementation as a T-rex does with its present-day bird cousins. Or, maybe we brushed off a random unit test failure as just a weird hiccup that couldn’t possibly be an oversight in how we composed concurrent operations.
And, at times, the assumption may not be entirely ours. For instance, we might spend time assisting a fellow engineer with converting a hash set to a sorted array, discussing optimal approaches in the process. Later, we discover that their goal was simply to find the min/max values among the sorted objects, a task that could have been easily achieved using a straightforward O(n) for-loop on the set; no unneeded data structure conversions or sorting algorithms.
To avoid such assumptive pitfalls, we should always seek clarification and validate our assumptions through testing and careful inspection. This approach reduces the risk of errors and ensures a higher quality software product.
Naturally, this principle extends to communication with colleagues. Despite our best efforts, misinterpretations can still occur. I like to think of human interactions as though they are nondeterministic APIs with somewhat leaky abstractions and no documentation. Pure functions don’t apply when it comes to human beings; the same input will almost certainly result in different outputs at any given time with any given person. If we are ever uncertain about the intention behind someone's words or actions, it is better to make no assumptions and “start curious, not furious.” Ask questions first; you’ll be glad you did.
Always do your best
Don't let what you cannot do interfere with what you can do.
— John Wooden
In life, consistently doing our best allows us to achieve our goals, overcome challenges, and maintain a sense of fulfillment and purpose. However, it’s important to keep in mind that our “best” will vary depending on various factors such as energy levels, stress, and workload. Recognize that it's not about always being perfect, but rather about consistently putting in our best effort to learn, grow, and contribute to our teams and projects.
As software engineers, we must strive to give our best effort in our tasks, whether we're coding, debugging, or attending meetings that could have been emails. By recognizing that our performance will fluctuate like an unpredictable stock market, with each day's best effort looking different, we can cultivate resilience, adaptability, and a growth mindset. In the end, we'll evolve into better professionals and individuals.
Embracing this principle means that we also need to be patient with ourselves and our colleagues. Some of the most meaningful conversations I’ve had with the most talented engineers I’ve met haven’t been technical conversations. Rather, they’ve been about our struggles and how we’ve learned to accept that they will happen, no matter how hard we try to avoid them.
As software engineers, we'll encounter setbacks, roadblocks, and frustrations—like wrestling with an undocumented library, or tracing that elusive heisenbug that always seems to be one step ahead. By maintaining a sense of compassion and understanding that progress isn't always linear, we can trudge through difficult moments and foster a supportive and psychologically safe work environment.
Be skeptical, but learn to listen
The trouble with having an open mind is that people will insist on coming along and trying to put things in it.
— Terry Pratchett
Practicing the seemingly opposed activities of skepticism and active listening enables us to make well-informed decisions, deepen our understanding, and cultivate empathy and open-mindedness.
In software engineering, it's crucial to treat assumptions, ideas, and solutions with a healthy dose of suspicion, as if they're trying to sneak into a party to which they weren't invited. It's like being introduced to someone named "Robert'); DROP TABLE Students;--" sure, he seems like a really nice guy, but maybe you should run to secure your database now.
Being skeptical means not accepting information at face value, but instead verifying and validating it. This encourages critical thinking and helps to prevent potential issues that may arise from blindly following instructions or accepting information without question. Always be prepared to ask questions and be asked questions in turn.
At the same time, learn to listen actively to others' perspectives, ideas, and, perhaps most importantly, feedback. This means giving your full attention and genuinely considering their input, even if it challenges your own understanding. Lest we fall prey to the Semmelweis Reflex and reject something simply because it is incongruous with our current beliefs.
I vividly remember my first tech role in 2009 as a Change Analyst when I encountered an IT executive from one of our clients. During a meeting, a colleague brought up the then-emerging cloud computing services, such as AWS, and their potential to replace some of the company's on-premises infrastructure. The executive confidently dismissed the idea, asserting, "It won't catch on."
By being open to different perspectives, you can gain valuable insights, learn from others' experiences, and discover more effective solutions to problems. And maybe avoid embarrassment of absurd certainty.
In summary
If we’re fortunate enough, every day brings a new, yet safe, challenge. After all, an engineer's true purpose lies in the unrelenting pursuit of solutions to life's technical problems. The principles from Don Miguel Ruiz's books, "The Four Agreements" and "The Fifth Agreement," offer a valuable framework for personal growth and self-improvement that extends to software engineering.
By being impeccable with our word, not taking anything personally, avoiding assumptions, always doing our best, and being skeptical while actively listening, we can become better engineers and individuals. By applying these principles to our work and interactions, we can create supportive, productive, and psychologically safe environments, ultimately leading to more successful projects and fulfilling careers.
So, the next time your code is heavily criticized, and you’re told it would pair well with some meatballs, remember the wisdom of these agreements.
Have you come this far and enjoyed what you read?
If so, please consider sharing and subscribing!
It would mean the world to me if you did!
❤️🙌