The 3 best feedbacks I received as a software engineer that changed my career

Apr 6 | Henrique F. Teixeira

Being a software engineer is not easy. The market is hot, and salaries are attractive, but not without reason. Just as not everyone is born to be a doctor, not everyone is born to be a software engineer. It's not enough to consider working in the field solely based on market demand and salary. The profession is challenging, and even with an ideal profile, we still face many difficulties, requiring significant resilience and practice:

There are over 700 programming languages in the world, and the market requires knowledge of some of them—not all, but a random selection that creates various combinations for each company.

Each language has multiple different tools and libraries, sometimes even 2, 3, or 4 that do the same thing. The market also randomly requires knowledge of these tools.

Furthermore, systems are often like a 2000-page book, written by many different people at different times. Analogously, our job is often to modify a specific page of this book, being careful that the whole remains cohesive and makes sense. In some cases, bugs and code errors can cost us anything from working weekends to billions of dollars and and even lives. After all, software is everywhere.

Beyond technical skills (hard skills), we also need soft skills. If we lack good communication, for example, we might accept impossible deadlines or fail to deliver a feature as specified by our client due to a lack of listening and understanding their needs.

We can easily fall into burnout.

We never know what's coming next; we can become obsolete within 2 to 3 years.

In this scenario, one of the most valuable things we can have is the mutual support of the software engineering community online and from colleagues, leading to numerous open-source libraries, forums where we can seek help, partnerships, and sometimes invaluable feedback.

In my experience, I was fortunate to work with excellent professionals who mentored me and provided feedback. Giving feedback, in particular, is quite challenging. I'm not talking about a pat on the back like 'well done' or 'you do great work.' I'm talking about constructive feedback.

According to my understanding of Dale Carnegie's classic book 'How to Win Friends and Influence People,' people's tendency when receiving constructive (in other words, negative) feedback is to justify themselves. No matter how wrong the person may be, they will try to justify themselves, and if the feedback isn't delivered cautiously, it can create a bad atmosphere between both parties. People rarely accept their own flaws.

Indeed, I believe that knowing how to listen and give feedback are two rare soft skills.

So, I consider myself lucky to have known how to listen and to have had someone who knew how to give feedback.

At the time I received the three pieces of feedback that changed my career, I was working alongside a software engineer who was much more experienced than me (to this day, I consider him one of the best engineers I've had the opportunity to work with; I admire him greatly), and he was about to change companies.

On his last day, we had a 1:1 (a meeting, just him and me) where I asked him to point out areas for improvement. To my surprise, he had already prepared these points even before I asked.

The feedback I received was completely different from what I expected, very precise, and I never imagined that simply following it would create such an impact. By putting just these three points into practice, I went from junior to senior in a very short time. Here they are:

1. Finish tedious tasks as quickly as possible.

According to American writer Michael Stanier, most of our daily tasks are classified as 'Bad Work' and 'Good Work.' 'Bad Work' is all bureaucratic and mechanical tasks, such as filling out spreadsheets, going to the bank, and attending unproductive meetings. 'Good Work' is the type of work you do very well and resolve without much complication. It's the description of your job.

— Luciano Braga in 'The Power of Free Time' p/ 72

In our daily lives, we sometimes have to perform tasks that aren't exactly what we enjoy most. I, for example, love refactoring, architecture, and new project tasks, but my enjoyment of these doesn't prevent other tasks I dislike from appearing in my day-to-day. This is likely the situation for most people.

The biggest lesson I learned from this feedback was not to procrastinate or 'drag my feet' on tasks I don't enjoy. After all, they will have to be done anyway, and the more time we spend on them, the more time we spend on something we dislike.

This is even logical. The faster we finish the tedious part, the more time remains for the enjoyable part, meaning we stay more motivated.

Don't put off boring tasks; try to finish them as quickly as you can!

2. Know your company's entire software architecture 'by heart'; understand exactly how things work 'off the top of your head.'

At that time, I worked at a company with a complex software architecture: various microservices, internal libraries, queues, relational and non-relational databases, daemon workers, cron jobs, and legacy systems (the famous giant, disorganized monoliths). To make matters worse, the system was high-scale, handling many requests per minute.

The business rules were all implicit in the code, but understanding the entire ecosystem seemed extremely challenging, and indeed, few people did.

Some people might tell us how something works or what the business rules are, but we can only be sure if we understand the source and analyze the code. After all, that's where what will actually happen is written.

For me, at the time and in that scenario, it was very difficult to deliver any more complex tasks. To know where to make changes, I constantly had to read a lot of code, understand how various systems integrated, behaved, and what each one's responsibility was. It was also very difficult to contribute opinions in meetings, generate ideas, create solutions, and very easy to make wrong technical decisions.

To deal with this, this was my colleague's secret, and it has now become mine too: voluntarily memorize the entire architecture of your company's systems (within your team's domain) to the point where you can draw it by hand without needing to consult any source. For example: Imagine your team handles the company's payment section. Take one, two, or three days to read code, documentation, talk to longer-tenured colleagues until you can draw (at a high level) everything on paper without needing to consult anything. Memorize everything.

Draw shapes, arrows, describe the responsibilities, processes, and main business rules of each service (or component/class/library), and make it clear how everything works and connects. It doesn't need to be in minute detail, but with enough detail for a good general understanding.

Become a Medium member As much as it might seem like a lot, it's not impossible, and the advantages are highly significant:

  • Agility in decision-making during meetings
  • Ease in proposing and conceptualizing solutions
  • Extreme confidence
  • Assertiveness
  • Higher quality in written code
  • Recognition (from peers)
  • Appreciation for your work

Furthermore, study all the languages and tools involved in the architecture that you don't yet know, so you don't miss any details.

3. Be present, participate in all events (that you can), and build good relationships with your team.

You know when they invite you for a beer after work? Or that special lunch where everyone goes together? Or an event for someone's birthday? That casual chat/coffee break in the pantry?

Currently, with remote work, this might seem strange and distant. But if your company promotes an in-person event or a call with a non-work-related theme, don't miss it. If your team plans something outside of work, go! Participate!

Turn on your camera.

Ultimately, we are all people. Many say it's necessary to separate 'professional life' from 'personal life.' But hold on, there aren't two Henriques. I personally believe there's only one life, and our bodies won't magically stop stressing just because we leave or enter work.

For people with very fragile or superficial relationships with colleagues, a small misunderstanding can become a big problem, feedback becomes difficult, and there's little transparency. I'm not saying we should only work with our best friends, but it's also important to understand the other person—their motivations, what they do in their free time, what they enjoy, their personality—and establish a relationship of trust.

This makes all the difference in the work environment; a comfortable and safe environment provides:

  • Relaxation
  • Better ideas
  • Transparency
  • Peace of mind
  • Assertiveness in dealing with others
  • Good feedback
  • Connections with people (even from other areas)

As much as it might not seem so to people starting in the field, these points are fundamental in the software engineering process.

At that time, I had a fragile relationship with most of the team I worked with. We only discussed work, and this created problems for me:

  • Doubts about how others perceived my work
  • Discomfort
  • Lack of security to ask for help when I didn't know something
  • Imposter syndrome
  • Fear of being laid off
  • Anxiety and premature understanding of some situations
  • Avoiding speaking in meetings

Conclusion

These are the three best pieces of feedback I've received. It's clear they span both hard and soft skills. For me, remembering them daily was a simple way to make my career successful, like a magic formula.

Even today, I find it incredible how powerful their effect was, especially for being just three points.

Hey, what did you think of this article??

Share and give your opinion by clicking on one of the networks below:


Thank you very much!