From Developer Annoyance to Automation

Automating the Annoying

Annoyed Cat

Some of the best developers I know are those who do not settle for manual repetition of tasks.  The task is boring/tedious/annoying after a while.  Not only does it become more efficient if it is automated, but it also makes the work satisfaction go up (you aren’t spending time doing things you don’t enjoy as much).  It can be really simple or really complex.  For example, I got tired of changing to a specific directory every time I opened a gnome-terminal to get to a project I was working on (cd dir1/dir2/dir3/dir4/, etc.).  That’s where my post on creating aliases came from.  That is definitely more on the simple side.

On the more complex side, consider continuous delivery.  This basically means you can get your code changes delivered to the customer quickly using the same process.

Delivery

As an example….

  1. Code commit
  2. Jenkins kicks off unit test build
  3. If that passes, Jenkins kicks off a system test build
  4. Repeat tests as needed until complete confidence is given to that end software product.
  5. Automatically make that code available to customers or even automatically update their existing infrastructure.

Some people got tired of running manual tests over and over.  So they started writing unit tests or other automated tests so they didn’t have to repeat themselves and waste time every time a change was made.

Others grew weary of developers breaking existing functionality – they didn’t necessarily run all the automated tests (or it took to much time before a code check-in).  So continuous integration servers were developed that automatically tested code checked into a source code repository.

But that wasn’t enough!  Some can’t stand the manual packaging and deploying code.  So they went a step further and even automated that.

Think of how powerful this is!  That person could have just stuck with the norm and manually tested every time.  Instead, they came up with a way to help tons of other people to automate testing.  That saves lots of time and improves quality.  The same can be said of continuous integration servers and continuous deployment.

Your Turn

Think about your normal workday.  What do you not enjoy?  What do you end up repeating several times?  Can you use automation to alleviate this?  If the task seems to big to automated, can you break it up into a smaller subtask that you can complete quickly?

Question Mark

If you can use these daily frustrations to make the process better, this makes you and everyone else around you (if you share your results) more efficient/potentially happier with their work.  So I’ll ask one more time… what can you automate?

Leave a Reply

Your email address will not be published. Required fields are marked *