When I started my career as a software engineer, I was young and inexperienced. I was not sure what I needed to learn, how to do my job, and I was missing information that could help me. I didn’t have a mentor or a coach, nor did I have senior engineers that could guide me easily; they were very good at their job, but they couldn’t explain why. I always wished there was a guideline or a rulebook that I could follow so I could improve myself and my work. I searched the internet for articles and books with opinions and experiences from other engineers. It helped, but it didn’t make a big difference. Now, after many years of developing software, mentoring others, and coaching teams, I want to say that there is a simple principle that can drive a software engineer’s career when it’s continuously applied. It’s one of those things that can propel any engineer on an upward spiral and generate compound interest over time. It’s the simple principle of automation. It can be applied by automating the self, the team, and the business.

Automate yourself

When I started as a junior software engineer, I was full of energy and ambition. I wanted to learn as much as possible, and my enthusiasm caused me to make many good and bad mistakes. For example, I thought that if I put in extra hours at the office, my manager would appreciate it and promote me when the time would come. However, that was not the case. I also thought that working on more challenging tasks would help me learn more, but in the end, it proved to be a source of stress, and my manager didn’t like it when I missed deadlines or use cases. I realized one day that I had to become more productive at the work that I was comfortable doing, specifically the tasks for which I had the most knowledge and skills. I realized that simple things like bash scripts that transformed five commands in one saved time and prevented me from making errors. Then I realized that I could use bash scripts to test if my staging deployments were done correctly (a form of automated testing). After this, I understood that proper implementation of unit tests saved hours when it came to regression testing. Taken separately, none of those things made a difference, but combined, they had a powerful impact on my productivity. As months passed by, I started automating as many things as possible: I added email filters, implemented notifications for low disk space, git hooks that executed LINT before pushing branches, CRON jobs for clearing temporary folders and committing my work at the end of the day, etc. That was also the moment when I began to appreciate unit tests and automated testing in general. Because of all these small things, I started to have spare time for learning, more energy, and I was confident with my work. Soon my manager and team noticed the improvements, and I received excellent feedback. In the end, the company gave me an opportunity in another group, but by that time, I decided to start working as a freelancer. Only by continuously automating my work, I was able to go from a junior developer to a freelancer.

Automation for the team

After working as a “lonely” freelancer for about a year, I decided to go back to company work and benefit from interactions with other engineers. I joined a small team of 6 people in a brand new software development hub. The company had minimal processes in place, and we were using whatever we knew from previous jobs.

Since this was an Agile environment, we had retrospectives every two weeks. I decided to stick to my principle of automation, and I always prepared for these meetings by thinking about one thing that we could automate as a team. I was coming up with monitoring and alerting implementations for our production environments, running scripts for testing, and slowly automate the release process (many times a release would last more than 2 hours). People were receptive to the concept of automating our work, and of my proposals got implemented, and they proved to be a success. The appreciation for this came quickly: 6 months after joining the company, I was promoted to Team Lead position, and I was leading a team of 3 engineers. I never stopped asking

What is the one thing that we repeatedly do and how can we automate it?

Are we permanently checking the logs in production for errors? — let’s build a script that does it for us. Are we pushing and pulling branches every morning? — let’s have a CRON do it for us. Do we need to ssh to 3 servers separately to deploy our code? — let’s see if Capistrano can do it for us.

Automation for everybody

In my new position, I had different responsibilities and activities than before. One thing I didn’t expect was to collaborate more with the stakeholders. I was suddenly involved in business decisions, user testing sessions, shadowing, and sometimes I played the role of the product owner. I wasn’t sure what to do, how to react to all the information, and what decisions to make. I thought that as a Team Lead, I would be more focused on technical aspects, but it turned out that it was only one of the things that were expected from me. By the time I got into this situation, I was applying the principle of automation without even knowing it, and I continued to do so when working with people from other departments. I saw users making three clicks for an operation that would only need 1, so I proposed to make their life easier by creating a new button that executed all the business logic in one process. In another case, I noticed that people were sending emails to other departments after completing each of their tasks, so I proposed a feature for that. When support engineers came to my team for help, I would keep an eye on similar requests and build scripts that would catch the issues automatically. Over time, my small team transformed into three teams of 15 software engineers, and all that time, I always kept using the principle of automation and started teaching it to others. I noticed that many engineers were using it without knowing it or being conscious about it, but it was effective nonetheless.

As a software engineer, no matter the stage of your career, you should always be mindful of the principle of automation. As a junior, it’s best to automate your work, and after you become successful at it and learn the tools and techniques that improve productivity, you should take it to the next level and automate your team’s work. Always remember that at the end of the day, the software you are building serves a purpose and has an end-user, and making his or her life more comfortable through automation is the end-goal.