Preface

“I will always choose a lazy person to do a difficult job because a lazy person will find an easy way to do it.” — Anonymous

Author’s note

I think we can agree that working in the technical field can be fun, but in it, we often encounter some not-so-fun tasks. For these not-so-fun bits, I try to filter out all of the repetitive administrative work with something that I am better known for as a developer: writing code. Yes, I can be a bit lazy, but that is because I value my time. You would be surprised at how much time goes into updating comments on Jira, zipping files and emailing them to colleagues, updating configuration files, and copying and pasting directories.

At a previous job, I found myself doing things that could have easily been automated by a script. Anything that feels repetitive should ring alarm bells for you. If it does not, then you should change your mindset now. Look at what you do on a daily basis, think about it, read this course, and see if it changes your perspective. Ideally, it should.

On one weekend, after noticing the repetitive tasks at work, I took note of the steps involved in these tasks from start to finish and set out to build a suite of commands that would automate them. It proved to be efficient for both me and some of my teammates, and it gave me more time to concentrate on Reddit…I mean, my work.

I remember reading a funny story about a programmer who automated anything that took longer than ninety seconds. His coffee machine was connected to the local network, and he sent commands to it and timed how long it took for him to walk over to pick up his freshly brewed cup. He even programmed it to send a text message via Twilio to his wife if his machine was logged in fifteen minutes after the end of the working day, saying he was working late that night.

Being fairly accustomed to using Bash scripting in the past on a Linux virtual machine, I decided it was the right tool for what I wanted to achieve. I would need access to the file system. I could make use of the powerful searching commands, store variables, read in standard input from the user, and use conditional statements to decide on how to proceed. Perfect! But then I thought: I wonder if I can achieve the same with Node.js?

Initially, I created the Bash version, but upon some digging, I learned that I could create the project with npm directly. Therefore, I rewrote the project and presented it to the team. The great news was that my team and I were allocated time to work on the project during work hours, and one of the technical architects was keen to integrate this tool into our workflow!

There are two ways we can implement the code that you will be learning in this course. You can treat it as a global list of commands, which behave in the same way as an alias on a terminal, or you can create a build tool that deploys your project while taking care of all the tedious tasks you are used to doing.

This course will help you build something along the lines of what I have built, but it is important to point out here that every company’s workflow follows a different path and set of business rules. Do not worry though. Section two of this course explains a good way of identifying and detailing your workflow. Once you have identified this path and the associated workflow, it should be easy to apply the knowledge acquired from this course.

End goal

Let us not beat around the bush. Once you finish this course, you should be able to create global commands and a working bespoke Node build tool that allows you to automate the repetitive tasks you hate doing. This build tool will be shaped around your company’s goals or your own. Either way, the intention is to make your life easier. Because life is hard enough as it is, right?