A few years ago I had fallen into a deep rut in my career. I had worked as a full time developer for about a year, and had spent that year maintaining a very old and complex api service that most developers at our company avoided. Despite the bad perception of the api service, it lived at the heart of the company's biggest product, and needed regular updates. I felt like this maintenance work was a dead end, and that I would never be allowed to move on from this project. I began to think that quitting was the only way I would ever be able to move on.
But I didn't want to quit. Despite the rut, I really love the company and the people that I work with. I didn't want to abandon ship and just dump this project in someone else's lap. I wanted to stay, and that meant taking real ownership of this api service.
Over the next week, I dug into the code, and realized that by replacing the way the service loads new data, it would eliminate most of the complaints that I had about the service. I started discussing the project with my manager. I wrote up my very first project proposal, and soon found myself discussing the project with the CTO. I was terrified and excited that my work was important enough that the CTO wanted to make it one of the company's top priorities.
Over the next six months I worked with a small team to eliminate over 1,000,000 lines of generated code, replacing it with cloud-hosted json files that could be updated and loaded into the service without any downtime. With this one fundamental change our turn-around time for new features went from weeks to days, and our release process went from a manual 8 hour process to a matter of minutes. Best of all, the service became truly stable for the first time in years!
When I decided to take ownership of the old api service, it went from a heavy ball and chain to a set of exercise weights. Rather than dragging me down it became a training ground for all the skills that I needed to become a senior software engineer. Ownership is hard, and it means accepting responsibility for failure. I had to ask for a lot of help from senior engineers who know way more than I do, and I had to spend some late nights troubleshooting issues brought up by customers after the initial release. But each failure made me more careful and gave me a deeper understanding of the system I was building.
Taking ownership of this service finally allowed me to move on. I have worked on many new projects, built new services, and enjoy working with new and exiting technologies like Kubernetes, dotnet core and React. I still get to spend time assisting with upgrades and improvements to the old service as the need arises, but I'm glad to say that I'm no longer alone.
This post originally appeared on my free Reflective Engineer Locals community
Top comments (0)