Learning from My Tech Career Failures as a Software Engineer

There aren’t many things I regret in my tech career. Of course, there are things I’ve lived through that shouldn’t happen in a perfect world. For instance, the abuse I suffered as a kid. Or my laziness in college. Or my overdeveloped fear of failure.

Yet I’m grateful for every step of my journey. The complex tapestry of struggles, failures, and learnings I’ve experienced has led me down the path of tech career success I enjoy today.

But what if I had to do it all over again today? Follow along as I walk you through this interesting thought exercise. Hopefully, you can take something from these learnings to apply them to your own unique situation.

1. Applied more of my computer science (CS) knowledge

It is quite possible to be successful career in tech without having a computer science degree. However, applying CS fundamentals to your work empowers you as a developer in ways that being a mere tool or framework user does not.

My first job in tech was as an intern for a bank. What I did not understand at the time is that there is a huge difference between developing software for a company that makes its money from the software it builds and one that does not.

Back then, the value of software was determined by how well it saved the organization time over manual, paper-based tasks. It didn’t matter if it was fast, usable, or laughably, even correct at times. The worst applications still saved a non-trivial number of hours per year of time compared to doing tasks using paper based systems.

Graduating from a CS program that prioritized preparing students for cutting-edge software companies solving problems at scale, my education seemed somewhat useless given my situation at the time. The IT department could just build or buy software, no matter how awful, and force the tens of people who needed it to use it. The game was simply to provide the least amount of quality for the cheapest sum of money possible.

Consequently, I was dubious about the value of my classroom learning as it pertained to my real world career. Had I known what I know today, I would have done one of two things: 1) asserted my knowledge more confidently to help lead the team into better software patterns and practices, or 2) left the company sooner to pursue opportunities in my career where I could apply my knowledge more usefully and honed my skills more quickly.

2. Attempted the Google interview sooner

As fate would have it, I attempted my journey to Google five years after graduating from college and landed my dream job on my second attempt three years after that. The growth I experienced between those attempts were critical. I wish I had experienced that sooner in my career.

In college, almost a decade before I actually got the job, I met a Google recruiter at a career fair. They handed me a brochure and told me to apply for an internship. I trashed it. In my mind, there was no conceivable path for a black kid from Compton to get to Google. That’s the stuff of Hallmark movies.

I didn’t have a single soul in my poor network of connections who had ever attempted this unfathomable feat. No context. No experience. No vision. And because I had not yet valued the virtue of learning from failure, I did not see interviewing as an opportunity to accelerate my learning. No, it was like asking me to drive a car off a cliff. There was only one way that could end. Having no eagerness to discover the ceiling that I knew had to exist all along for someone like me, I preferred not to even try. I was a black man pursuing a career in tech in the early 2000’s.

Had I known that Silicon Valley is the place where taking risks is not only celebrated but glorified, I would’ve taken the dive way sooner and been all the better for it.

3. Networked 500% more in college

With some regularity, I get an email at work from a recruiter wanting to know if I am familiar with some candidate. Over 95% of those emails pertain to someone who attended my alma mater while I was there.

I confessed earlier that I was network poor in my college days (I was money poor too, but I digress). The thought had not occurred to me to make an effort to build one myself. If I had not isolated myself, I might have built doorways into better career opportunities. At least I would’ve learned some names that I could’ve referred to Google later in life. That could have been easy referral bonus money.

While I might not have had as many opportunities handed to me like some of my colleagues did, I also didn’t leverage what opportunities I did have very well. And with the platforms for networking that now exist, I would not make that same mistake today if I had the chance to start over again.

4. Practiced unit testing and code reviews

For the majority of time in tech before Silicon Valley, I often relied on a QA team to validate the results of my work. This fostered a mindset of shifting the responsibility of ensuring the quality of my work to someone else. School taught me that unit testing is an effective tool for building robust, higher quality software. But in my early days, most enterprise organizations didn’t have the stomach for it.

Not only that, but I could write as much code as I wanted with impunity. This meant that I made a lot of bad decisions regularly, developing horrible habits that went unchecked for years. And I was good at producing boat loads of code.

I faced a rude awakening when, during my first year at Google, I found myself having to redo work many times during code reviews. I saw my productivity dive bomb like a bent paper plane. You can only imagine how that fed my already severe feelings of imposter syndrome. The code review process exposed a lot of weaknesses in my coding practices. That suffering was both necessary, humbling, and useful. I also could have saved myself some embarrassment too.

What could I have changed? Even when in an environment where not practiced, I would have made unit testing an integral part of my workflow. I would eagerly invite others to review my code. Finally, I would insist on finding roles that value unit testing and code reviewing.

Conclusion

I’m sure there’s more that I could say, but I hope this honest take is helpful to you. Have a thought about something I mentioned here? Did I leave something out? Leave a comment and let me know.