My 30 years of dodging repetitive work with automation tools

Last updated on

Written by Conor O'Neill

I blame my life-long work obsession with automation and avoiding repetitive drudgery on my first boss and mentor Danny in S3. He was horrified to see me doing the same thing over and over in a VAX code editor and introduced me to the magical world of macros.

From that point onwards, I was a man on a mission to save us all as much time as possible in our working days.

But first 

If you enjoy this post, then you'll love the in-person No-Code Automation Meetup that is happening in Dublin Ireland this Thursday Feb 10th. We have two fantastic speakers in Joe Drumgoole from MongoDB and Thomas Kinsella from Tines. If you're not in Dublin, fear not, we'll live-stream those talks. For everyone else, we'd love to see you in Huckletree D2 for drinks, pizza and networking. RSVP here.

I'll definitely use this again 

My time-saving has always been split between automating the automatable and finding better and better tools to do so. Of course, I have fallen into the XKCD trap on occasion and spent more time automating a one-off task than it would have taken just to do the work. My excuse is always that I might find another use for the work in the future.

Write-only scripting languages 

I'd love to see the stats on lines of code written for "apps" vs lines of scripting code written to support all the context around those apps. I suspect there are far more scripts out there. It's one thing to bash (sorry) out a bunch of C++ that implements an algorithm. It's quite another thing to test it, get it deployed, monitor it, upgrade it and make sure it's not riddled with security issues. Hence "scripting".

I had a fantastic time discovering languages like Tcl and Perl and AWK and Sed and Lua. They gave me back a ridiculous amount of my day despite often turning into unmaintainable monstrosities. I doubt I'd now understand a single line I wrote back then. There's a reason they call Perl a "write-only language".

We even built an entire Professional Services team in one big company that used a simple set of scripts which ingested GBs of XML every night to generate high-value reports.

Space for Python? 

Then for 10+ glorious years, I had Python. It's still awesome. I've done everything with it. I moved from Runkeeper to Endomondo for my running. I built a startup on it. I've mis-identified two kittens as a Panda bear using it (thanks to AI). It truly is the Swiss Army Knife of languages.

But it's still programming and it still requires a ton of mental effort to start any new project, particularly if it has been a while since the last one. For many situations, it's overkill and I have always kept my eyes open for alternatives. Once again XKCD was on the money.

Yahoo! Pipes! Got! Canceled! 

In 2007 Yahoo announced Pipes. It was a web-based tool to "build data mashups that aggregate web feeds, web pages, and other services".

I loved it. Zero programming - just visually wiring APIs together and filtering the data. But it was Yahoo, so it had absolutely no chance of success or survival. They never found a commercial angle for it and it was killed by 2015. But it made me realize that, for a lot of scenarios involving data, events, and APIs, coding just wasn't necessary.

Yahoo Pipes

Google Invents Apps 

Jump forward to 2010 and Google App Inventor (now MIT App Inventor). Another moment of shock as I found myself able to build Android Apps graphically in the browser. I was so blown away by it, that I spent a semester teaching a class in my kids' Primary School on how to use it.

App Inventor, Scratch, Blockly, etc. all share a very similar model, which is "relatively" easy to understand. I learned a huge amount about how non-technical people get a handle on tools like this in the school. It was second nature to some and unfathomable to others.

MIT App Inventor

I still fundamentally believe that everyone should be given the opportunity to learn these types of tools so they can be the creators of our future, and not just rely on the good intentions of a small number of technologists.

IFTTTTTTTTTT 

2010 also saw the launch of IFTTT but it was 2012 before I started using it. It's still a great tool for lots of simple scenarios and I have to think there are millions of IFTTT recipes chugging away year after year providing benefit to their users. There are lots of pre-baked connectors/integrations and you can easily point tool X at tool Y. I still use it mostly for Twitter integrations.

IFTTT

But IFTTT is limited by design. It is a single IF statement. And the biggest issue I've had over the years is the constant breakage of the connectors by the sites they connect to. This is no fault of IFTTT, just the ever-changing priorities and business models of lots of consumer websites and web apps. I'm starting to think we need an LTS for APIs or a commitment to not break them for at least five years from bigger organizations.

Forms and Storms 

In 2013 I started working in Mobile Enterprise Application Platform vendor FeedHenry. One feature I doubled down on was its Forms integration. You could build a series of Forms and then use FeedHenry to turn them into a mobile App. Customers in the utilities and maintenance spaces adored it, despite its initial simplicity.

One customer was able to generate a series of damage-reporting Apps in under a week during the horrendous storms in Europe, and provide live reports to the UK Government. All without any developers!

I was regularly surprised by the places such a tool could provide value. One giant cement company was transformed when they replaced 6 layers of carbon paper for every delivery followed by a month's wait for the invoice, with a Low-Code App.

Node-RED and All The Things 

I always think of Node-RED as Yahoo Pipes for IoT (Internet of Things). Officially it is "A programming tool for wiring together hardware devices, APIs and online services in new and interesting ways."

Node-RED

It comes into its own in fast IoT prototyping. I've wired up devices like ESP8266, ESP32, Espruino, Arduino, and Raspberry Pi to the internet or each other by lashing together something in Node-RED. Its ability to connect to lots of home automation systems makes it ideal for home hobbyists and there are quite a few people using it in "production" in their houses for years.

My main issue with Node-RED is that I have to install, run and maintain it myself. There have been times when I've forgotten which Raspberry Pi it was running on and I've re-flashed the SD card!

I think I spot a pattern 

We've just covered 30 years of tech in a few paragraphs. So many great tools, some sadly no longer with us.

When I look at all the automations I've done, they all follow the same pattern. In fact, it's the basic pattern of most software:

  1. Take data from system X, Y, and Z

  2. Do something to the data

  3. Send the updated data to system A, B, or C.

What data? Well, there have been test run results, XML, JSON, CSV, RSS, river levels, weather, news alerts, server alerts, security alerts, my weight, calendars, people's locations at an event, stock levels, price alerts, etc, etc.

And A, B, C, X, Y, and Z? There aren't enough days in the year to tell you how many of those systems there have been. From GSM Base Stations to the South China Morning Post and everything in between.

And then I met Tines 

When I first heard about Tines more than 18 months ago, I assumed it was a niche tool for a niche set of people and seemed like it would only be appropriate for a tiny number of my personal use cases.

Then earlier in 2021 I had the moment everyone has with Tines. The OMG moment. The 'Wait a second, I can use it for that? And that? And this? And that? And the thing yonder? And, no way, that's incredible.'

It's like Eoin, Thomas, Brian, Jonny, and the team have been hiding out in my head looking at all the automations I've built over the years and created a tool that can not just do them all but also make them 10x easier to complete.

Even the simple fact that Tines does IMAP is huge. I have so many things I've tried to build based on Inbox integrations but my last attempt on Lambda was such as disaster that I locked myself out of Gmail.

Bit by bit over the past few months I've been replacing existing flakey or broken Lambdas and other integrations/automations with clean, simple, cloud-hosted Tines Stories that I never have to worry about. Last weekend I upgraded my home Conor-Is-On-A-Call system to Tines.

I haven't written a single line of automation code in many months. I just use Tines and I do it with a smile on my face, thinking about Danny and those keyboard macros.

Built by you, powered by Tines

Talk to one of our experts to learn the unique ways your business can leverage Tines.