3 big mistakes I’ve made in my career as a software engineer

This article was originally published by Emma Bostian on .cult by Honeypot, a Berlin-based community platform for developers. For the latest updates, follow .cult by Honeypot on Twitter, Facebook, Instagram, Linkedin, and YouTube.

I vividly remember my first week as a Software Engineer at IBM. I was bright-eyed out of college and slightly egotistical.

“I deserve this job,” I thought, “Web development is easy; I’ll get promoted in no time!”

And then I made my first huge mistake: I forgot to test my code before merging it to master.

In college, I took one entry-level web development course, where they taught you that HTML, CSS, and JavaScript exist and you should use Bootstrap and PHP. Testing was never discussed and as a result I was embarrassingly unaware that just because my pull request was approved didn’t mean I could merge without second glance.

I promptly received an angry phone call from a Scottish senior developer reprimanding me for my lack of oversight. I had broken everyone’s development environment. We quickly rolled back to the previous version while I scowled in my office.

I never forgot to test my code from that day forward.

We all make mistakes; it’s part of the learning process. But making mistakes doesn’t have to be a bad thing as long as you learn from them.

Here are three of the biggest mistakes I made during my career. I hope you can learn from them, as I have, and grow as a developer and as a person.

1. Not asking questions

As a new hire, and even more so as a woman in a team full of men, I was nervous about asking questions for fear of sounding stupid.

I was afraid to ask questions which would expose my programming ignorance, and this greatly impeded my growth as a developer.

Once I built a strong rapport with my team members, I began asking more questions. I learned how to strike the balance of researching the answer and not wasting time looking on my own. And once I got over my fear of asking questions I learned more quickly.

Every developer starts from zero, and while we all learn at different speeds, we all have to go through the same process.

It is vital to ask questions if you don’t understand.

When you ask questions in-context, both you and your colleagues waste less time. If your question can be easily solved by a quick Google search, first take the time to do some high-level research. This will save your colleague the frustration of answering a question you could have found the answer for on your own, and it will save you the embarrassment of being told so (this happened to me at IBM and I will never forget it).

2. Assuming everyone communicates the same way I do

At IBM I worked with international colleagues, and now living in Germany as an American I work on a team with six different nationalities. And it wasn’t until a year of living abroad that I realized every culture has a different idea of what “good communication” means.

I had numerous miscommunications with my German manager as we would both walk away from a meeting with different ideas of what the next step was, and this led to frustration and inadvertent turmoil within the team.

Then I stumbled upon the book The Culture Map by Erin Meyer in the Frankfurt Airport and it changed my outlook on life.

Different cultures have different communication processes; some are high-context communicators and read in-between the lines (like people from Germany) while other cultures are low-context communicators and require explicit and redundant communication (like people from the United States).

It’s no wonder I had massive communication problems with my team and my manager; we were communicating differently!

From that day forward I vowed to learn more about communication and building solid professional relationships, and it has greatly improved team rapport.

Multi-cultural teams need low-context processes. All communication should be explicit, spelling out exactly who is responsible for which task, and backed-up in writing which is then distributed to the team through Slack or email.

Learning some of the cultural differences between you and your coworkers, as it relates to giving constructive criticism, communicating, even scheduling meetings, will greatly enhance your interpersonal relationships and your team dynamic.

3. Taking constructive criticism personally

Constructive criticism is important to grow as a developer and also as a human, yet to this day I struggle with taking constructive criticism personally.

When someone gives me constructive criticism, my first instinct is to interpret this as a reflection of my personal identity; it feels as though they’re attacking who I am.

In reality my colleagues are helping me by identifying the areas for improvement, and this is truly a gift. It demonstrates that they see potential for me to be successful, and they’re helping me reach that milestone.

Create a safe space to receive and give constructive criticism. It’s best to set a meeting to discuss this topic, where both parties know exactly what to expect, and to do it in private.

And when someone gives you a piece of constructive criticism that you don’t believe is true, don’t immediately get defensive and shut down. Take some time to process what they’ve just suggested and truly see whether their feedback holds some truth.

These are only a handful of mistakes I have made during my career, and I hope you can learn from them. You’re not expected to be a perfect employee and teammate, but having the ability to understand your flaws and learn from your mistakes will improve your job performance and set you on the road to success.