My First Big Mistake as a Software Engineer

Well, I knew it was gonna happen sooner or later. Today, I made my first BIG mistake as a software engineer. Turns out, it wasn’t even a software problem, wasn’t a bug, wasn’t some ill-thought-out design or logic. No, it was a human problem, a communication issue, a mental issue.

To be fair, the first year and half at my new company has been pretty smooth sailing. I’ve received many wonderful and encouraging appraisals from my peers, managers, and even managers’ managers. But there I was today, working on a very important project that someone else had designed, and I was implementing it.

The Setup

This new project was large and complex, at least for me. It essentially required me to design a new system that flew from the very front end (UI), to the middleware, and finally to the backend. The problem was, I was still brand new. My understanding of our large, old and complex codebase was extremely limited. This meant, I didn’t know what the hell I was doing! At all! Luckily, the designer of the feature, let’s call him D, was very experienced and had written a design document entailing most of the core design decisions and requirements. Unfortunately for me, that well-written document was not enough. In fact, it read like complete jabberish to me. I had no idea what most of the terms meant, what the requirements were, or how to even begin implementing it.

Naturally I struggled with this task, and pressure built up as I was chugging along. I was making progress, slowly and surely, but things didn’t stick well. Initially, I started out with the hope to fully understand the feature, understand the changes required and then start implementing them. But the changes were simply too involved in a codebase too foreign for me to conceptually grasp. So I decided to tackle it one section at a time, slowly and surely, I was making little progress, with the help of D.

D being D, was always so kind, patient and extremely knowledgeable. He proved to be a great resource for this feature, and I ended up in a routine of relying heavily on him for his input and help. In fact, his help was so effective that I slowly forgot about the original design document, apart from the 3000 feet in the air overview of it. That would come to haunt me later…

The Trap

The project manager, let’s call him P, typically schedules weekly meetings to discuss the challenges and progress. But this week he required an email update. I was having a particularly tough week, struggling with a particular aspect of the feature that turned out to be more complex than I had initially understood. I even grew a little anxious and frustrated, wondering if this feature truly was for meant for a new engineer like myself. I was also at a point where I felt like I shouldn’t be bothering D with too many questions, as I was feeling guilty for taking up so much of his time.

So, as P requested for an email update, I thought it would be best to highlight my challenges, and point out these new challenges I was discovering. I promptly drafted an email, detailing the progress, the challenges, and the potential risks, as P had requested. I sent it off, and went back to work.

The Mistake(s)

Five minutes later, I received a message from D. There and then, I knew I f**ked up, BIG TIME. In my mind, I thought I was doing the correct thing, reporting the challenges and risks early on, so that there’s plenty of time and room to address them. But little did I know, these challenges were not only known, but were highlighted in the original design document, that I had miserably failed to comprehend, and later forgotten all about! Upon realizing the mistake, I quickly apologized, and re-edited the email to reflect the correct information, removing the intimidating challenges and risks I had highlighted.

But that wasn’t the real mistake. There were actually three mistakes I made, and they were all acutely psychological

Failure to Understand the Design Document, and Communicating That

I had read the design document cover to back once or twice before starting this feature, in hopes of understanding it. But of course that didn’t stick. I had no understanding of the system. It’s like reading the manual of an aircraft front to back without even knowing what a plane is! In hindsight, there were at least a few things I could have done better on this regard. First, I could have asked D to carefully walk through the document with me, from beginning to end. During this walk through, D might become acutely aware that I had no idea what I was doing, and might have opted to supplement the document with further details. Second, I should have routinely referred back to the document, and use my newly gained knowledge to better understand the original document, at which point, I could have communicated again to D that my understanding was still lacking. Third, I simply could have requested D for a more detailed document. But no, I did none of that, out of fear of looking incompetent, or out of fear of bothering D too much, or simply as a result of D being so helpful in person, that I forgot about the document. This was the This was a major mistake, primarily resulting from a lack of communication.

Failure to Recognize the Impact of My Email on D

The second mistake was the email itself. I had sent an email to P, highlighting the challenges and risks I was facing. But I had failed to realize that D was the one who had designed the feature, and had already highlighted these challenges and risks in the original document. I was thinking, “Hey I did a pretty good job identifying all these issues and clearly communicating them.” I was thinking about me, from my own perspective, and not at all about how this would reflect on D, the designer. By sending out that email to P and D, I had essentially communicated to P that D had done a poor job designing the feature, and that I was the one who had identified these issues. This was a huge blow to D, and I had failed to recognize that. I lacked empathy, professionalism.

This was a gross misjudgment, and blatant ignorance on my part. There were a few psychological reasons at play here.

• Excessive self-regard tendency: I was so focused on proving that I was doing a good job, confirming my own values, that I failed to see the contributions of D.
• Misjudgment of social proof: I thought that by highlighting the challenges and risks, I was showing that I was doing a good job, and that I was being proactive. But in reality, I was showing that I was not understanding the system, and specifically underestimating how my actions (sending the email) would be perceived by others, particularly P and D.
• Lack of Consideration of Second-Order Effects: In my email to P and D, the first-order effect was the communication of the issues. However, the second-order effect, which was overlooked, was how this communication would reflect on D and impact their professional reputation.

This lack of second-order effect actually brings me to my third mistake.

Failure to Recognize the Impact of My Email on P

The earlier I highlight the mistakes, the better I am able to resolve them. But there’s a limit. I had failed to recognize that by highlighting these challenges and risks, I was essentially putting the pressure on P. P now has to make an executive decision on whether to escalate this issue to its manager, which could in turn continue to escalate. I had failed to correctly gauge the severity of the issues and the risks.

On top of the second-order effect, there are also two key psychological models at play here.

• Social Proof Misjudgment: In this context, my action of sending the email could be seen as an attempt to demonstrate diligence and proactivity, but I misjudged how such communication would be received by P. Instead of seeing it as proactive, it might have been perceived as signaling that the project was in trouble, which could influence P’s decisions and actions based on the perceived need to respond to a crisis.

• Authority Misinterpretation: I grossly misinterpreted how authority figures will perceive and react to information. By sending the email detailing unfiltered challenges, without a clear understanding of their documented status, I assumed that P would interpret the information as helpful or insightful. Instead, it could be seen as a red flag that the project is not on track, prompting potentially unnecessary managerial intervention.

The Aftermath

So yeah, that was the mistake. It might not look like one, but could potentially escalate quickly. Had D not reached out to me promptly, it likely would have. Mistakes are bound to be made, and it would do no good do dwell in them and drown myself with self-pity. Instead, we should proactively analyze and learn from our mistakes. In this particular case, it gave me great clarity on some of the psychological tendencies I fall victim to. Once aware of such tendencies, I know now to look out for them.

I’m documenting and sharing this mistake with you, in hopes of helping you and myself learn from them. And in the fashion of learning and progressing, I’m not oblivious to the second-order effects of this particular post - it could be seen as me seek validation and sympathy, or it could be seen as me seeking to learn and grow. I hope it’s the latter.

Finally, let me close of this already long post with a few quotes that I found particularly relevant to this situation.

“Life will have terrible blows in it, horrible blows, unfair blows. It doesn’t matter. And some people recover and others don’t. And there I think the attitude of Epictetus is the best. He thought that every missed chance in life was an opportunity to behave well, every missed chance in life was an opportunity to learn something, and that your duty was not to be submerged in self-pity, but to utilize the terrible blow in constructive fashion. That is a very good idea.”

“Think of every mischance in life, however bad, creates an opportunity to behave well. One’s duty is not to become immersed in sel-pity, but to utilize the terrible blow in constructive fashion.”

“I sought good judgment mostly by collecting instances of bad judgment, then pondering ways to avoid such outcomes.”.