.png)
The story goes like this: you are sitting at your desk doing your day-to-day job as a Software Developer, then out of nowhere you’ve got a meeting with the tech lead or the architecture team. The meeting subject is The New Exciting Fantastic Team Tool. If you’re a Senior Engineer, you already know what this kind of meeting will lead to. Sooner or later, as a software engineer, you’ll have to deal with decisions that you didn’t make, and the exciting news is that these decisions will affect the way you work, and you’ll have to deal with the consequences.
This article is about how you can handle decisions made by other people (usually those ranking higher than you) that you may or may not agree with.
There were two situations in my life where these kinds of decisions directly impacted my day-to-day work. My role was the same for both. I was a Backend Engineer, and the only difference between these situations was the level of freedom that each contributor had when making decisions. This attribute can change the environment where developers work drastically, as you will find out later in this article.
In the first scenario, I worked in a team that made the authentication, authorization, and cryptography backend for a huge web portal. This company had an excellent tech environment; they always allowed the developer to decide which technologies they used. As you can expect, the developers at the company had a great opportunity to build and test the most exciting technologies - we could run any number of distributed systems that we wanted.
You might be thinking “OK, but there must be constraints, right?”
Yes, resources like virtual machines, proxies, and load balancers aren’t unlimited, and all developers were responsible for the resources they were using. Another constraint was the projects we’d work on; you couldn’t select which project to work on, but you were fully responsible for all the tech stack. Do you want to use GO plus PHP in the backend and Flutter Web in the front-end? Go for it; you will be accountable for the maintenance.
This scenario sounds like a dream for any developer, but it has its drawbacks. Imagine that you are not the developer who started working on the project but someone who was chosen to continue the project’s development. You have to decide whether you’re going to throw everything away and start developing your new shiny code from scratch or just continue with the first developer’s idea. This is why every developer needs to consider other developers’ opinions when choosing the tech stack for the project.
According to the well-known Spider-Man principle: “with great power comes great responsibility.” Since you have the power to decide how to tackle the problem, you will be responsible for anything that might go wrong with it.
Even if you are working on the project by yourself, I strongly recommend discussing every technology decision with others within your organization. If this is not possible, find some discussion group to have more eyes on your ideas. At some point, you may regret some technology decision you made; if this happens, you must communicate with everyone involved and try to figure out how to handle it gracefully. Always stay open to feedback on your code.
Most common problems have already been solved by someone else so don’t waste your time or your company’s time by attempting to create a gigantic complex solution for an issue that has a well-known and tested solution simply because you are able to. At the end of the day, you are responsible for delivering value to the business, not a technology case for some conference.
The second scenario was when I was a Backend Developer at a financial technology company, working with payments. My responsibilities were to develop payment gateways for financial institutions.
Sounds exciting, right? And it was, until I discovered that I wouldn’t have any freedom to choose the technology I’d be working with. I started experiencing stress when the architecture team decided that using queues structures as a communication pattern between systems was strictly forbidden. And this is just one example of the company’s restrictions. I had never faced such a restricted environment, and this taught me some valuable lessons.
I didn't have the freedom to exercise my creativity to create solutions or even to suggest new solutions because all the architecture was already done.
In the first feedback cycle with my managers, I told them that with so many constraints, my work as a Backend Developer in the company was merely to follow other teams’ decisions and implement them. They told me something that I will never forget: You have to focus on what you have, and not on what you don’t have. This changed everything in my work environment.
As my manager said to me, if you focus on what you don’t have, you won’t be happy anywhere. Instead, you should think “with all these constraints, what’s the best I can do?”
You might find yourself in a situation where the team's technical decision was wrong. Try not to point fingers at other people and teams; this attitude isn’t helpful at all. In The Art Of War, Sun Tzu said: "Supreme excellence consists of breaking the enemy's resistance without fighting.”
I know you won’t always be able to deploy that new fancy frontend framework. However, you should at least stay up-to-date when it comes to new technologies so you are able to suggest other solutions and eventually create a better work environment as well as stay motivated.
In any situation it’s good to have a strategy to help you handle your stress and responsibilities. The important thing to focus on is how to best manage the freedom and constraints in your work environment. Remember that freedom isn’t necessarily the best option, and that actually being under many restrictions is a perfect opportunity to exercise your creativity. You just have to find your way inside your organization. Finally, it is up to you to decide what environment you want to work in and what type of management you are willing to work for.
I’m an Italian-Brazilian software engineer with 10+ years of experience developing software for a variety of tech stacks. I’ve being working in back for 7 years as a Java developer but for the last two years I’m love with iOS development. I had some experience in software management being scrum master for two years and loved study software development methodologies, but my real passion is to code. In my free time I like to hang out with my wife, write tech stuff online, read articles and chat about life, universe and everything else.
.png)
.png)
