Photo by Timothy Dykes on Unsplash

Drinking alcohol — which Google kindly informs me is a psychoactive drug — is widely considered to be normal. (Read that again)

What’s considered just as widely to be abnormal is sobriety. At least it seems by many drinkers of alcohol, my former self included.

Usually described by reference to the things it lacks — the main one obviously being alcohol — we’re told that sobriety is also without style, sophistication, fun, enjoyment or good times. It is a necessary-but-grey alternative for those who, for seemingly unmentionable reasons, can’t or shouldn’t drink. Or so the story goes.

For those of…


Egyptian hieroglyphics, or modern-day laundry?

I guess we could potentially connect most devices to the internet, hence the growing interest in the Internet of Things (IoT).

Whether we gain much from doing so is another question.

I recently had an IoT face-palm moment after hearing that a friend’s cat’s litter tray is now internet-enabled. He is able to tell how full it is via a smartphone app. If only the cat knew!

Of course, it still requires manually emptying followed by use of a weight reset option, to bring internet and cat waste worlds into calibration again. At this point, I found myself asking “Why??!!”


Photo by NordWood Themes on Unsplash

As software engineers, we tend to make rather binary decisions, to favour clear-cut outcomes and black-or-white choices. I guess it’s in our nature.

This applies when choosing technology and architecture, but it also extends to how we like to organise ourselves and our projects.

  • We pick a serverless architecture or an instance-based one.
  • We favour full-stack developers or we see the value in specialisation.
  • We prefer autonomous teams/squads or we go for cross-team coordination.

We tend to pick one extreme or another and to stick with it.

The problem is, even in a field as precise as software engineering, these…


Photo by José Alejandro Cuffia on Unsplash

I get it… We all like something we can point at and that’s why most discussions about new software products and features tend to focus upon UX mockups of those features.

I guess it’s natural. Mockups are the first visual representation of the feature and how it might be used. They facilitate discussion about it. They are tangible and we can point at them, which helps immensely, particularly if the feature is at all complex.

I’ve talked before about why I believe UX mockups need validating against underlying data, but I’d go further and say that UX shouldn’t drive product…


(Written jointly by Ian Cackett & Sasha Bilton)

A key consideration when managing multiple software teams is how much freedom and responsibility to allow each team over their technology choices, architecture and approach, versus insisting that they agree and align their decisions with other teams in the organisation.

Most organisations tend to take an extreme view and sit at either end of the spectrum, having either fully-autonomous “squads” or heavily mandating alignment, commonalities and shared decisions.

Photo by rawpixel on Unsplash

Short-to-Medium Term: Results-Oriented

In the short-to-medium term, autonomous teams certainly appear to be more innovative and effective: They are hampered less by the need…


“What is the most underrated skill in the software industry?”, someone recently asked me.

“The ability to make complex things understandable”, I replied.

(I know they were expecting something like “Scala”, “React”, “JavaScript” or “AWS”)

But of all the things that I’ve found to be missing in software teams, an ability to make complex ideas understandable and approachable to others is by far the most glaring and underrated.

Photo by Markus Spiske on Unsplash

Most people can learn a programming language, a framework or a technical topic in enough detail to make practical use of it. Most people can also gain a decent understanding of a…


User eXperience (UX) mock-ups are wisely used to drive the complex process of defining what a software product will do, from the perspective of its users: How it will look to them, how they will engage with it, and how they will use it to solve whatever problem / gap the product is intended to fill.

Photo by Hal Gatewood on Unsplash

But I’ve seen one mistake with UX proposals time and time again: Failure to validate them against actual data sources.

“Surely that’s ok, and data issues will all be sorted out when the UI is built and integrated with a backend / API?”

Well…


Photo by Hello I’m Nik on Unsplash

I’m sure it can’t be pure coincidence that a large number of the people who are software engineers today grew up playing with toys such as Lego, Meccano and Linka.

I can’t help but think that the countless hours I spent building, dismantling, playing, struggling and eventually understanding them contributed to being better at many of the equivalent activities I perform as a software engineer today.

So what is it about these particular toys?

Component Parts… and Lots of Them!
All of them provide a huge pile of component parts. That’s basically all you get. Occasionally, they come in a kit…


In the past month, I’ve been lucky enough to be introduced to quite a number of startup founders in London, many of whom were on the lookout for a tech co-founder.

Some had already realised the search for that co-founder could take a while, and so they sensibly asked for tips on how to build a software product without one. This article is my attempt to summarise what usually became a very long answer to that question!

Firstly, unless you’re planning to build the product entirely yourself — which is certainly possible if you have the time and appetite to…


Crusher95 [CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0)], Wikimedia Commons

There’s a lot to talk about in the world of software and technology.

I spend much of my time talking, learning or writing about it. As professions go, it’s wonderfully immersive and I wouldn’t trade it in for anything else.

I get so caught up in the glorious details that I often forget why I got so passionately involved with writing software in the first place… to solve real problems, to scratch itches and to provide solutions that stretch beyond the confines of my laptop screen.

It certainly matters to me which programming language we code something in… but only…

Ian Cackett

Building software to solve hard problems (Software Engineer / Lead / Manager) — Opinions are my own.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store