Introduction
A friend recently approached me for help and professional advice. This conversation made me think.
What if I were in his shoes, looking for advice on how to pursue a career as a programmer or software architect?
"That’s why I’m writing today to my past self and to those who are just starting out on this journey."
When a software architect or programmer faces a challenge, the temptation to start coding right away is great. However, this rush can result in ineffective solutions and wasted time. Often, what is being developed does not address the root of the problem, leading to future complications.
On the other hand, when taking on the role of software architect, it can be tempting to apply our “magic architecture” or follow the latest technology fad. This approach can be risky and, in many cases, irresponsible.
Understanding the problem in a comprehensive way is essential, especially in a critical sector such as the pharmaceutical industry. With a deeper understanding, we can identify the real needs of users and find appropriate solutions, resulting in more effective code that meets industry requirements.
It is vital to remember that what really matters is not just how we solve a problem, but rather finding a solution that works. However, a poorly structured solution may seem appealing at first glance, but will become complex and costly to maintain over time.
Expanding Your Toolkit
While coding is essential for developers, it is not the only skill required. There are several technologies and resources that a software architect or programmer can explore to enhance their skills and deliver more robust solutions.
In this article, we will consider a scenario where the professional is experienced, familiar with multiple projects, and has knowledge of cloud architecture, microservices, and object-oriented programming.
However, it is vital that, throughout this journey, the developer does not fall into two major mistakes:
The Imposter Syndrome
The Superman Syndrome
These syndromes can harm not only the individual, but also negatively impact the team and professional reputation.
Understand the Problem from the Customer's Perspective
Understanding the problem at hand is essential, but this must be done from the customer's perspective, and not just based on how the developer sees the situation. In a previous experience, we faced a disorganized project in React, where two previous teams gave up due to complications. When talking to the analyst, we realized that, by understanding her expectations and the reasons why we had not been able to deliver what she wanted, we radically changed our approach. This exchange of understanding led us to specialize instead of remaining generalists.
Be what we call the "Middle Dev", acting as a central link between the business rules and the areas of technology, development and architecture. This way, tasks start to be completed efficiently and clearly, resulting in a more productive and organized workflow.
Be an Expert in Your Client's Processes
Offering a robust solution is not limited to defining the best system architecture or the best cloud configuration. Even if you use on-premises servers, write clean code in Java and Spring Boot, or implement a serverless solution on AWS, none of this is valid if it does not meet the client's real needs.
Having a deep understanding of your client's problem is essential. Understanding both worlds — programming and architecture — allows you to think more clearly and propose effective solutions.
It's like planting a tree: for it to grow and bear fruit, its roots need to be firmly established. Many times, we try to make a project work without the necessary foundation, leading to abandoning ship.
On the other hand, we also have clients who never stop thinking about new problems. In a startup where I worked, the original architecture was quickly restructured, evolving over time. If there had been more careful planning from the beginning, the restructuring could have been avoided.
Right or Wrong Decision
There are projects that are born great, and this is mainly due to the vision of their creators (stakeholders). In another startup where I worked, the application was conceived in a grand way from the beginning. The frontend of the application was excellent and, once implemented, it was in a sector that is experiencing explosive growth worldwide: industrial automation, known as Industry 4.0. The project was fantastic, and the stakeholder managed to integrate some concepts from Industry 5.0, which was impressive.
I am mentioning this project in particular because I have worked on more than 50 software projects, and there was a phrase said at an early stage that helps us understand what I want to share in this article.
Once, as software architects, we were invited to have lunch with the client (stakeholders). At the end of the meal, he paid the bill, we thanked him and he left a phrase that will stick in my memory.
"There is no such thing as a free lunch."
To translate this sentence for you: "I have a problem that can only be solved with advanced technology and architecture. I want you to understand what I'm thinking and implement it in a system."
After some time, we finished our part of the project. The client then formed a team to continue the work, which was good news. We did a knowledge transfer to his team, based on a learning process. However, when we arrived, we realized that the team wanted to change everything. Remember that I mentioned earlier that there are systems that are born big. Here, I could say that it was a big problem. We must always consider two points.
Was the first decision wrong? No. And the second? Neither.
The system was delivered, met the client's needs and was successfully implemented. However, it was still a small growing tree. Today, the same system has artificial intelligence integrated into the automation.
Don't Be the Lazy Expert
For a long time, I conducted interviews to select good professionals for the company, both for backend and frontend. One day, a colleague asked me about a specific selection process, because the other candidate had more technical qualifications and a longer career than the one I had chosen.
The issue was much more complex than it seemed. In a selection process, the interviewer often feels like he or she is in court. After going through several selection processes, I realized that this approach needed to change. I always proposed a conversation where the important thing was not just the answers or the effort to impress, but rather transparency and sincerity. Admitting "I don't know" – even if it costs you the job – is actually one of the most valuable characteristics of a professional. What motivated me the most to choose the other candidate was his ability to pursue knowledge, even without knowing the answer at that moment. In the second phase of the interview, he brought a newspaper that showed his research and interest in the subject. This attitude made a difference, and yes, it was one of the best choices we have ever made, because he really went after it and solved problems.
You, who are reading this far, have probably asked yourself:
Why were technical qualifications considered less important than the search for information that eventually emerged during the interview?
The answer is simple, although it is one of the most difficult to accept in our field: we don't know everything, but having the willingness to search and discover is the least we can do.
At this point, you may be thinking: why didn't they do this with you?
One of the good things in life is choices. Everything I went through as an interviewer during the selection processes taught me to be better. When I went for an interview again, all I did was be myself, "senior yes, but I don't know everything." What I expected from people should also be reflected in me. I have listed here qualities that can set you apart with recruiters who seek the best for their teams:
- Be truthful: "I don't know" is a valid answer.
- Be frank and honest.
- Don't try to beat around the bush in an interview; often you only have 30 minutes.
- Be someone who goes after it. If you don't know today, ask again tomorrow.
- Be willing to learn (everything changes quickly in technology).
- What is new should not surprise you (take time for proof of concepts).
- Don't be a one-trick pony; learn several ways to accomplish the same task.
- Listen first, listen again, think. Maybe you can talk, think again, and then talk.
- Don't just present an idea; bring a solution (don't feed POs without being sure).
- Be to someone what you would like them to be to you.
- Don't play with your reputation (your reputation is worth a lot, don't risk it by trying).
- Well-written code allows you to take a vacation (and it's not just about vacations).
- Don't get carried away by technological fads, but don't get left behind either.
- Your new version may always come with flaws, but it is certain that it will present improvements (don't let time pass without evolution).
Communication
At the beginning of our professional careers, our entire focus is on becoming the best in hard skills (knowing how to program well and knowing the tools). Today, after more than 20 years in the profession and with more than 50 projects developed in various areas of knowledge, I have a broad understanding of Frontend, Backend, Database and Cloud. However, 10 years ago, I considered myself a senior, but I discovered that I was not.
I will tell you how this discovery happened. I went through a humiliating experience, the kind that could make anyone cry. However, I have never been the type to play the victim. It was a difficult situation, especially because I faced a person who believed he was the best. He yelled at me and said that I knew nothing about what I was doing. It was terrible. After the confrontation, I went to my superior and asked to be fired, because I realized that some people might think the same way he did. However, when I laid my head on the pillow, I realized that the reason for that behavior was much more complex than I imagined.
So, I reflected and decided that I wanted to become a better person. I wanted to learn how to express myself more effectively and ensure that I would never experience anything like this again. My goal was to stand out in my field, not by becoming just another professional, but by mastering the languages and methods until I understood them in depth. Today, I can say that I am a senior, but that is only part of the story. It was on that day that I understood that communication is what really makes someone considered senior. Knowing how to ask questions is important, but knowing how to listen is even more essential.
Of course, you should excel in hard skills, but your pay can be much better if you are also good at soft skills. Knowing how to talk to people, listen to them, and propose solutions that have been well thought out, often after a proof of concept, makes all the difference. Today, I am a senior because I learned what no one teaches in schools, colleges or Architecture and Development courses.
Conclusion
The biggest challenge in life is learning and being able to teach. Today, more than ever, we have access to resources and people who can provide us with valuable lessons. Being the best in your field is important, but being human and contributing to your team is essential. I work with a Scrum Master who constantly seeks to be better for his team, which has transformed our environment and increased productivity.
Learning from each experience and never considering yourself the best are principles that drive us to be better. I end this article with a phrase that resonates to this day:
"Perfect is the enemy of good!"
Focus on solving problems in the best way you can, without demanding perfection from yourself.
The code is merely your tool. So don’t waste all your time fixating solely on writing code. Instead, focus on the challenges at hand and how you can effectively address them. Remember, it's about finding solutions, not just writing lines of code!
Top comments (0)