Some people can't help but want to improve things or face new challenges. Maintaining things as they are is just too boring. Especially as software engineers, it is one of the reasons people move to other jobs or try to climb up the ladder. Most people can't do the same "monkey job" over and over, it is a profession for people who crave an intellectual challenge. Change for change or a challenge only for the sake of a challenge is not a great business model though, and if you want to promote improvements and new solutions at your workplace, you should be aware of a few challenges you will face and skills you will need to harness.
Not every company or team is the same. You will receive different levels of resistance from different places. I have worked in a place where I proposed we unit test our code and heard back from another engineer: "So it means we will need to write more code?". Resistance might also come from poor alignment with business-oriented people who care too much about the immediate delivery speed and disregard maintenance costs. Other places will be way more receptive to change. It can take a little courage and willingness to rock the boat, it might mean that you will make some friends and cause other people to see you as a difficult person.
Alright, so you are willing to fight the good fight and bring the technical level of a project to the next level. Or maybe you are going to streamline the process and give everyone that extra level of productivity. But you still need to figure out what needs to change and what changes need to be made. Worse than maintaining the course is making the wrong change, and even worse is not learning from your mistakes and continuing to bet on the wrong thing.
Egocentrism is a common pitfall. Understandably, you are excited to write code in that cool programming language or with that new library that you use for your personal projects. But it doesn't mean that you should rewrite the project and make the whole team learn it. You will likely have a team of people who will write significantly worse code due to a lack of skill with this new tech. Furthermore, are you able to articulate how it will actually improve anything?
Another common mistake is following trends blindly. If you believe that a hammer is the absolute best tool, every problem will look like a nail. The amount of money that companies such as Meta and AWS spend on evangelising engineers and promoting their tools can heavily shift the market view and make you think that a React SPA website powered by a microservices architecture deployed on AWS is the solution for every single problem. Try breaking down the real problems your project suffers and making a comparison matrix between different tools and architectures. If you think some tool brings only benefits and no downsides you are probably overlooking something.
When thinking about complex systems, be it a software system or even the workflow of a company, you should alternate between two ways of thinking. Holistic thinking enables you to see a system as more than merely the sum of its parts, but how they connect and work together to impact the output of that system. Analytical thinking, on the other hand, focuses on the individual parts that compose a system. Sometimes we assume we can fix the fact that the team is outputting bad code by using a different framework or language, but the problem might lie in the business requirements changing too often and too erratically, or the needs of the business not being translated into well-thought actionable tickets. It is often a combination of multiple factors that influence each other. Don't be so focused on your own domain that you don't see how the other moving parts affect your work. Input from people in all layers of the organisation will make for a much more well-aligned software.
It can be very harmful to your image if you focus on promoting bad changes. It will cause people to doubt you and will give ammunition to the anti-change people that will complain about the fact that they now have to write unit tests.
Your message needs to be spoken with the result it will produce in mind. Who is the person who will have your back and has the power to help you change things? What does this person care about? Are you using language they will understand?
Preaching about technical correctness or code quality to a business person who wants to press a button and make things go is often a waste of time. But making them understand that if you rush things you end up with technical debt that must be paid before you can work on the next thing and that it also might make things not go when they press the button in the future is much more fruitful. Not everyone cares if the quality of your code is good or bad according to abstract concepts they don't understand, but everyone understands the concept of debt. Sometimes using an expression such as "a recurrent task that can be automated" will drive the point to one audience, but calling it a "money waster" is the one that will drive it home to another audience.
Although everyone understands words as debt, we must be careful about the use of loaded words. Some words have different meanings depending on the context, and sometimes the framework in which you are structuring your thoughts and what you are saying is very different from the one the person who is listening to you is using. I worked on a project that had been going on for a while and had a few very disconnected features. We proposed to the client that we should stop and organise the upcoming development effort to deliver a minimal viable product. He strongly opposed it, because he didn't want anything minimal on his product. We pitched the exact same thing without using the word "minimal" and he actually listened to what we were saying and went for it.
It can be very frustrating to work on meaningless tasks and not being included in architectural or more meaningful decisions. But you can't just take it for granted that if you work with software development for enough time you should be considered senior and your opinions should have such weight. The truth is that we all need to work on the quality of our thinking. Self-reflection and seeking feedback are key tools for improvements.
Top comments (0)