No effort is too small to automate.
That’s one of Patrick Pierson’s mantras. He’s seen how time-consuming it can be when small tasks build up over time without being automated. Engineers often re-encounter “one-off” tasks down the road.
In this interview, we cover:
- Why no effort is too small to automate
- How to automate to benefit your work as a software developer
- What happens when software developers decide not to automate
The conversation below has been edited for length and content.
How do you incorporate automation into your daily routine?
Automation is everything. Even the smallest parts of automation are important. If you view them as one-time things instead of a process, they can build up over time. Alternatively, if you create a process of automating everything – even the smallest things – your life ends up being much easier in general.
Let’s take security groups as an example. In AWS, it’s very easy to create a security group, attach it to something, and have that security group open to the internet. For developers testing something out, it might only be out there for 20 minutes before its deleted. However, as a cybersecurity company, we want to make sure we’re controlling what we expose to the internet because we know what attack vectors are out there. We try to get our developers into the mindset of locking down their security groups.
Building automation keeps me from accidentally setting something up with an open security group. These simple automations – keeping your security groups protected and specifying IP addresses – help keep your systems secure.
Do you have any tips for automating in a way that’s beneficial to an entire team?
I recommend teams use a build system like Jenkins or GitHub actions. Ultimately you want to build a good system that you can trust to execute your automation and communicate to your team so that they can improve on it as well.
It might not be perfect the first time you set it up, but as you start to build on it and iterate, you’ll start seeing the benefits.
That one little automation you built two years ago may not have been a big deal but two years of built-up automation is very powerful.
What advice would you give knowing that automation decisions may differ from team to team, depending on their size and scope of work?
We recently started providing my team with the Jenkins environment.
Jenkins has been out there forever and many people see it as outdated. However, when we came together with folks from different parts of the organization and discussed what we wanted in a build system. We realized Jenkins was the choice that checked off every single thing people were looking for.
While it felt like a step back in the automation world, we provided a tool that everybody can use and scales up to every single build we’ve wanted to throw at it. It’s turned into a really nice automation platform for us.
Don’t be afraid to use a system that you might see as out of date. It might solve everything you’re trying to. Work with your team to find the tool (or tools) that work for you.
You don’t need to get stuck on just one tool. You don’t need to be well versed in every single tool out there, but it’s okay to use a mix of them. Automating first and always is the real goal.
What is the outcome from deciding not to automate?
The first thing that comes to mind is knowledge attrition. When someone leaves, they will take information with them that may not be documented or automated. If they haven’t automated much, you can very quickly see a team with good workflows turn into a team with a system that nobody understands.
If you’ve got a good automation platform in place and strong documentation in that automation, it doesn’t matter who leaves. In my opinion, anybody can pick it up, and as new hires begin to understand that process, they can expand upon it pretty easily.
