Automating the pain away

Automating the pain away has been a motto of mine through my career. Starting as massive find and replaces to large code migrations. I have always found myself looking for ways to extract as much efficiency from my tasks and those around me.

What pain sort of pain are we automating?

In practice we are not actually focusing on pain, but rather bad habits. Another great way of thinking about this is making best practices the easiest option on the table.

How are we automating?

For the past few years, this passion as led me to discover and engulf myself with learning and using ASTs (Abstract Syntax Trees). These trees are a representation of code and are the foundation of compilers and lints. In that you can imagine my excitement.

ASTs have been foundation for a lot of my recent work on eslint plugins, codemods, and even gather metrics about our codebase.

However, that isn't the only way we can automate. CI/CD (Continuous Integration and Continuous Deliver) pipelines are other ways we can automate the tedious tasks through the development process. Being able to lint for code styling rules is much faster than needing to find it in a review. Running the tests or build process ensures that new code added doesn't break the existing. Along with test code coverage to ensure our confidence in the code we ship has not changed. For me, these are all ways we can fall into good habit and automate the painful ones away.

Where do I start?

As with anything the best place to start is simple. I prefer to start with a manual task and ensuring I know all of the necessary. I find doing the task and meticulously writing out the steps to help me find the pattern in what I am doing and finding ways to automate it.

For example, last year around this time I was working on moving our React applications from one repository to another. Within that process I needed to complete many smaller tasks beyond just a simple copy and paste.

• Copy folder (with git history)
• Move all files into a src directly (except package.json)
• Rename all test files to match new standards
• Update package.json to include all new fields
• Rename from App.js to app.js including references
• Create a new standardized entry point
• Run prettier
• Update CODEOWNERS
• Run repo validation checks

My team did this work for over a total of 100 packages.

These steps were boring and tedious, it was easy to forget a step making it take even longer. Once I had a good understanding of these steps I began finding ways to automate them.

I started with a node script written in TypeScript and used inquirer to ask basic questions at first, like what app are you moving and where should it go in the new system. Then I automated the first few steps. Then I ran the process against a few to ensure it worked and added more steps. Then making automated commits with the steps that had been done and outputting errors and next steps.

Eventually I got the process of migrating a package to the new system down to only minutes.

Is automating always the option?

Absolutely not! As much as I wish this was true there are times where the automation is not worth it, or if there is too much variability to the step that it cannot be done.

As with all things in life, there is an XKCD for this.

I find that understanding how frequently you are going to do the work is helpful. Automating running lint against your codebase is small and has large impact. My example above of moving packages was only beneficial because of the time and amount of work needed to do it manually.

Even on large efforts I recommend you keep the automation small. As you get better with the tools the definition of small will adjust and with that the value in automating.

OH ASTs are cool, where can I learn more?

I was inspired to go on this journey after reading Jamie Kyle's repo - the super tiny complier. From there I read the Babel Plugin Handbook and started working on my first babel plugin, captain's log. At the same time I watched the live stream of this Kent C. Dodds talk on Frontend masters which put a nice bow on all my learning and gave me exposure to using ASTs for lint and not just babel plugins.

UPDATE: Another great resource for ASTs is https://astexplorer.net/. It allows you to visual and work with ASTs directly in the browser.

I also love talking about them, so feel free to reach out to me with any questions.