The software industry is an incredible industry to be part of.

There is always something new to learn.

Over the past 25 years I’ve had a lot of fun, had great job satisfaction, and learned so much.

However, to keep myself grounded, I try to remind myself of two things:

• You can never stop learning.
• Its not all about you.

My journey from a junior to senior dev has taught me some ongoing lessons about myself, technology and, most importantly, that prioritizing user needs above most things is key to any successful project.

I may love what I do and get a kick out of learning, but if it doesn’t benefit users, at the end of the day its of limited use.

Let me explain why I believe users don’t get enough attention from development teams, by detailing my personal journey….

The Early Days: Going Deep

Early in my software development career (dotcom boom and bubble), I was eager to solve any problems with a technology solution.

I would get my head deep into a niggling problem and come out the other side with an enormous sense of achievement. I would agonise over minor, but arguably essential, technical issues and feel real accomplishment when I succeeded.

At that point in my career, I wasn’t aware that customers don’t really care about technology.

If I were to try to explain to a customer what I’d been doing, their fully justified reaction would probably haven been “Why would you spend so much of my money doing that?!? It has very little visible effect on the problem that I have!”.

Customers were at the end of the waterfall model, they were of little concern when I was deep in code at the other end.

Levelling Up: Empathy

Things started to change when I was put directly in front of users.

Once you feel the pain and see the importance to individuals of the solutions you’re developing, it changes your perspective of your role as a developer.

If you want a developer to “care” and build useful products, have them experience the real-world pain they are trying to address.

The main takeaway from being personally deployed into client teams was realizing that users only really care about their problems and whether, what you’re doing, will directly help or hinder them.

Users don’t care about cool new technologies, frameworks, edgy design patterns, architectures, or highly technical concerns; they just want something to make their life easier, now.

Taking the blinkers off: Going Wide

Experiencing the real-world pain of clients broadened my focus from purely technical challenges to understanding and solving real-world user problems.

This transition from deep technical immersion to a wider perspective taught me the value of simplicity and direct impact. It wasn’t just about using the latest technology or dabbling with complex solutions anymore; it was about making a tangible difference in the clients’ lives with efficient and straightforward solutions.

Sometimes a complex solution was required, but sometimes there was another, simpler, cheaper, pain-free, way.

The ‘other’ way only became visible when we understood a client’s pain points, took a step back, and looked wide, instead of deep, for a solution.

It doesn’t add up: It shouldn’t be this hard

But, at this point in my career (early 2010s), even the “easier” way still seemed too difficult, took too long, and cost too much money.

There was a huge disconnect between clients’ expectations (in terms of timescale, cost and complexity) and how frustratingly difficult it was to develop production-ready software.

It just didn’t add up.

Technological solutions to everyday problems still seemed to be the preserve of large teams and clients with deep pockets prepared to wait for 6 months or more for a solution.

Front-end development felt too verbose, server management a speciality for proper geeks, and the ideal interaction between the frontend & backend a dark art.

Clients didn’t appreciate, or, more importantly, place value on, these [highly relevant] concerns.

A New Dawn: Scalable Services, Front-End Frameworks & Powerful Devices

In my personal opinion, around the early 2010s things started to change for the better, especially for web and mobile developers.

For example, frameworks like AngularJs (2010) & knockoutjs (2010) started gaining traction.

Scalable “serverless” services like AWS lambda (2014) started to roll out.

Mobile phones were now mainstream and able to handle JavaScript-intensive webpages and highly interactive apps.

Like them or loathe them, JavaScript frameworks made it easier for a huge number of teams to produce complicated web software quicker and with less code. While these frameworks marked significant shifts in my personal journey and the industry at large, they represent only a fraction of the myriad of tools and technologies that shaped the developer field at the time.

“Serverless” offerings started to reduce the need to manage expensive dedicated on-premises servers and reduced the need for a highly skilled team to manage them.

The pervasiveness of mobile devices made for an explosion in the appetite for, and number of, apps.

All combined, smaller teams could now start to produce complicated scalable software in less time, with less code and with [generally] less cost.

Late 2010s: Levelling the Field for Small Teams & Tech Startups

Towards the end of the 2010s scalable services started to really change the game for small teams and start-up’s.

In the early stages of a start-up, resources are scarce, time is of the essence, and the pressure to deliver is immense.

Leveraging frameworks, scalable services, IaaS (Infrastructure as a Service), PaaS (platform as a service), BaaS (back end as a service) & SaaS (software as a service) turned out to be a game-changer for smaller teams and start-ups. It allowed teams to focus on core product, rather than getting bogged down by the intricacies of backend infrastructure or deployment complexities.

This shift not only accelerated development cycles but also instilled a sense of confidence in the ability of smaller teams to scale and adapt as needed.

On average, today’s developers deliver about 40% as much new and modified code per project as they did 40 years ago.

Quantative software management: https://www.qsm.com/articles/long-term-trends-40-years-completed-software-project-data

Being able to concentrate on solving client issues and less on “invisible-to-the-client” concerns, was something that resonated with my own experiences so far.

At the same time, perhaps the most significant realization in my journey was understanding that the failure of tech start-ups (or innovative ideas in general) is not predominantly due to technology issues.

Instead, it often boils down to marketing mishaps and a poor product-market fit.

The new breed of scalable services started to allow teams to concentrate more time & resources on finding out if their idea is going to resonate with users and less on “invisible” technical issues.

Recognizing that a great product needs an equally great go-to-market strategy changed how I approach my role as a member of any organisation.

It’s not just about building; it’s about building what’s needed and ensuring it reaches the right audience. All startup team members, developers included, need to recognise this existential fact and continuously work with this concern at the forefront.

What Next? Do more with less

The journey that I’ve been on has been incredible, but its only just beginning.

While I believe we are seeing a convergence in web frameworks (signals, pre-compilation over framework libraries, SSR and hydration) & and an acceptance of the value of the “serverless” model, we are still only in the infancy of the tech industry.

AI is definitely changing things, quickly.

Quantum computing has the potential to massively accelerate what we are capable of.

And who knows what advances in human interfaces are in store for us in the next decade (think brain-computer interfaces or VR/AR instead of smartphones).

Although there will be change, some things will remain the same:

• If you build something useless, it wont get used.
• The process of finding out if something is useful or not to users can be seriously expediated if you build on existing tools, knowledge & services (rather than reinventing the wheel) .

For me, this means I will continue to strive to do more with less. Failing faster, with minimal cost, does mean more failures but continually gets us closer to a win more quickly & cost effectively.

I’ll also continue to trust my experience, extrapolate from past successes/mistakes, know when to learn deep or learn wide, when to build or buy, embrace the uncertainty, and understand that empathy for customers is just as important a skill as technical expertise

N.B. All of the above are just my personal experiences and opinions. I would love to hear if anyone else had similar experiences or had different experiences that have shaped their outlook differently.

My career is still in “development”. Gathering more experiences and opinions will never not be beneficial.