A productivity tip: Automate first!

In recent years I have developed a lot of projects on various scales. Some of these have been developed and deployed very quickly. But maintaining these projects were not as fun as developing them.

While I’m trying to fix issues or adding new features to my projects, I notice that the boring part for me is not the development phase. Generally, it’s about being ready for development and publishing the work.

I’ll define with a simple example: Let’s assume a button doesn’t show up while I am navigating my project on a mobile device. When I saw that issue, I understand the technical problem behind it immediately, even with being aware of the place of the problem by source file and the line number. The solution could be as easy as adding a line like position: absolute; to a style file. But, to make this fix, I need several mandatory steps:

1. Sit in front of your computer.
2. Add a line to a CSS file.
3. Test it.
4. Commit your change.
5. Build your project.
6. Deploy it to your server.

And I usually postpone fixing the code, considering these steps. And then my projects are having many small issues and my motivation falls.

During the last years, I’ve embraced automation in order to transform these steps into a useful process far from being tedious. The approach, which is very popular as Continuous Integration (CI) and/or Continuous Delivery, is to automate as much as possible the process outside of doing the job. However, in general, this is not considered as a requirement for simple hobby projects, although it is considered to be a requirement for complex projects or large teams in terms of developers, and is regarded as unnecessary time loss.

Last year I decided to change my mindset about that and I’ve started to automate each project beginning from the “hello world” phase. When I started to deploy my projects to the production automatically with every commit to my master branch and deploy them to a testing URL with every commit to my develop branch, my development flow changed a lot.

Firstly Bitbucket’s Pipelines feature and then Gitlab’s Gitlab CI feature helped me a lot to come to that mindset. Both of the Pipelines and Gitlab CI are free with a reasonable quota for your private repositories. For example, Gitlab gives you 2,000 minutes of Gitlab CI for free and this is way more than enough for many small size development teams. Last 1 year, after I started to work with Gitlab CI, my new flow for fixing something became something like that:

1. Find and edit the file on Gitlab’s web UI.
2. Save it.

There is no 3. step! Because, build, test and deploy steps are already defined and handled by my Gitlab CI configuration. And I can see the result in a few minutes in my mobile browser. If it’s a risky fix for my project, I usually prefer to fix and commit the change in the develop branch. In this case, my change is automatically publishing to a testing environment and after being sure it’s working very well, I’m just merging develop to master to have it in production. That’s it!

After switching to automation approach, whenever I saw a problem about my project at home, at a cafe, on the way, at a park or somewhere else, I’m just fixing it without thinking any boring part of the process. And after I noticed the big motivation gain of that approach, I strongly suggest using that style of development to every of my developer friends.

Like we have “mobile first”, “test first” or “customer first”, I think we should also have a new slogan: “Automate first”