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…
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??!!”
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 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…
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…
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.
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.
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.
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.
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?”
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…
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…
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…
Building software to solve hard problems (Software Engineer / Lead / Manager) — Opinions are my own.