3 Early Career Mistakes I Made as a Software Engineer—and How I’d Avoid Them Now

If I could go back, here are a few of the mistakes I made early on—and what I would have done differently

Foto di Sarah Kilian su Unsplash

I have been working in Software Engineering for 7 years.

In these years, I did cool stuff:

• Met fantastic people from around the world

• Traveled to different countries

• Worked side by side with amazing people to solve problems

• Learned so many things

I am proud of who I am today, and I must thank all the people and the experiences I faced during this journey.

But, if I could go back, there are a few things I would have done differently.

So, here are the 3 mistakes I made early in my career and how I’d avoid them now.

1. Not Building Enough Personal Relationships

When I started working as a software engineer, I was excited about my job.

I just wanted to sit at my desk with headphones and code all day. I wanted to speak about code, software architecture, and tech. Every time, in front of the coffee machine, I asked:

What are you working on?

I wanted to learn as much as possible. I wanted to grow as an engineer, and my goal was to speak to senior engineers to learn from them. I was very interested in the cool things they were implementing and the problems they were solving at work.

What I was missing was the personal aspect of the relationship.

I did not know enough about my colleagues. Did they have any hobbies? Did they like to read something in particular? What kind of music did they listen to?

The situation was even worse when I started working remotely.

When you work remotely, conversations are intentional. There was no coffee machine or lunch break to socialize. So, I knew even less about life outside of the work of my colleagues.

At the time, I didn’t know that this significantly impacted my working experience.

Trust is built with personal relationships.

Trust and vulnerability grow side by side.

You must be vulnerable with your colleagues if you want them to trust you.

If I could go back to that coffee machine, I would start with this question:

How are you?

2. Failing to Write Everything Down

Writing is an essential skill you need to master as a software engineer.

As engineers, we write every day:

• Technical documentation

• Comments

• User stories

However, writing is also crucial in other scenarios.

1. Meetings

During meetings, people talk a lot.

You might receive a lot of information. It is not easy to process all of it, especially if you have no previous context. That’s why you should take notes during meetings.

After a meeting, revisit your notes.

It will help you understand and, if necessary, request another meeting for another discussion.

2. Decisions

I failed multiple times with the illusion of agreement.

I spoke with my team about a problem, and we left the conversation, ensuring we agreed. But, during the implementation of the solution, we discovered our ideas were conflicting. This leads to a waste of time and frustration.

Avoiding this is simple:

When making a decision, write it down.

This way, all the participants can read it and agree on what they read, not what they have in their minds.

3. Problem-Solving

Are you fixing a development environment issue?
Write down the steps to fix it.

Are you fixing a bug?
Write the steps to reproduce it and what caused it.

Are you in a Situation Room?
Ensure someone is writing down everything.

If you don’t know how to start writing everything, try this guide about journaling.

3. Focusing Only on the Code, Not the Product

To be a great software engineer, you must be a product engineer.

This is probably the mistake that mainly impacted my career growth.

I have often heard that an engineer’s job is to write code. That’s not true.

Engineers are problem solvers.

We are not coding monkeys. We should be involved in decision-making and provide expertise to build a better product. Our goal is to find the best solution to solve user problems.

We must know the product.

Engineers should know how the product works and, most importantly, how users use the product. They should understand why some feature is requested or the current functionality implementation is not ideal.

Know your product and know your users.

---

Read Next