I kicked off my career as a web developer back in 1999, when the world genuinely thought everything was going to explode on 1 January 2000. Planes dropping out the sky, cash machines bricking themselves, electricity companies pulling the plug – full apocalypse energy.
Internet Explorer 4 was king, Netscape was its scrappy rival, web layouts were built with tables, CSS was basically a rumour, and the dancing baby meme was somehow cutting-edge.
My first web developer gig was very much “learn on the job.” I was super green and there was no Google, StackOverflow, or YouTube gurus. If you didn’t have a book, you were stuck and if you did manage to find someone on the web that would help – the general response was “RTFM” (Read the f***ing manual). I went from building simple HTML sites to coding classic ASP in VBScript overnight, and the learning curve was steep!
But in that chaos, two big realisations hit me:
1. You have to break everything down. More than you think.
People speak in shortcuts. Computers don’t.
Ask someone to describe walking and you’ll probably get:
“Just put one foot in front of the other.”
Ask a developer?
You’ll get a lecture about balance, muscle engagement, heel placement, weight transfer… the whole anatomy lesson.
Because when you’re coding, that is the level of detail the computer needs. Anything less and it just shrugs at you – or worse, crashes.
2. Computers aren’t people. They’re painfully literal.
Take the sentence: “May I borrow a pen?”
A human fills in all the blanks:
- You need something to write with
- You’ll give it back
- If there’s a pencil instead, that’ll do
A computer?
It’s the Kevin Hart sketch where he tells his son to go to sleep and the kid just stands there and snores.
It’ll do exactly what you tell it, and absolutely nothing more.
This is why Bill Gates’ quote always stuck with me:
“I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.”
Developers live by that.
Example:
Snippet 1
var x;
var y;
x = 0;
y = false;
if ( x == 0 )
{
y = true;
} else {
y = false;
}
Snippet 2
var x, y; x = 0; y = false; y = ( x == 0 );
Two bits of code that do the same thing? One takes 10 lines, the other takes 4? We’re picking the 4-liner every time.
Switching From Dev Thinking to Design Thinking
This is where things get interesting.
Development and design both solve problems – but they’re solving different kinds of problems.
Development is communication with machines.
Precise, deterministic, unforgiving.
If your logic is off by a hair, it breaks.
Design is communication with humans.
Messy, emotional, subjective.
Give five people the same design, you’ll get five different reactions because each of them brings their own expectations and experiences to the table.
That alone was a huge shift for me.
The Hard Parts of Switching to UX
Ego.
This was the big one.
Code reviews? Easy. Someone checks your work, you fix a few bits, done.
Design reviews?
Felt like a mental firing squad.
A room full of designers openly critiquing something you spent hours crafting? In the early days it felt like personal rejection and it took time to detach the work from my identity, but once that clicked, everything became easier.
Getting out of your own head.
Coding is like being a passenger: you decide everything – where to go, when to go, how to get there.
UX is like being the taxi driver:
They decide the destination, and you figure out the best route.
The user leads. Always.
Empathy.
Developers don’t need it because computers don’t have feelings, they just run what you tell them.
Design?
Whole different game.
You’re solving problems for real humans with real frustrations, fears, habits and expectations. Empathy becomes one of your best tools.
The Advantages of Being a Former Dev
And this is where things swung back in my favour.
1. Technical feasibility intuition.
When I design something, the dev inside my head is already muttering about how it would be coded.
This stops me proposing nonsense that’d take six months to build.
2. Database skills for research.
Need quick insights?
Spin up a SQL query, grab the stats, done. Massive time saver.
3. Communication with dev teams.
There’s no language barrier.
They don’t need to “dumb it down,” and I don’t need a translator.
Being bilingual in Design and Dev is underrated.
The Myth of “Be a Master of One”
An old boss once told me I should drop everything except development because it’s better to be a master of one trade rather than a jack of all.
Honestly?
Hokum.
It’s like MMA. Being elite in one discipline gets you far… until someone shuts that one thing down. The fighters who thrive understand multiple disciplines and the principles behind them.
That’s why I rate Miyamoto Musashi so highly. He was a warrior from Feudal era Japan and had around 60 one-on-one sword fights (to the death!), and still found time to be:
- A painter
- A poet
- A calligrapher
- A sculptor
- A farmer
- A florist
- An author
His philosophy?
“Once you know the way broadly, you will see it in all things.”
Master principles, not tools.
Master thinking, not techniques.
Why Development Made Me a Better Designer
My dev background didn’t just give me skills – it gave me perspective.
- I understand constraints
- I communicate across disciplines
- I know how to break problems down
- I think in systems
- I appreciate simplicity
- And I stay curious across multiple fields
Switching from dev to design wasn’t a clean jump – it was an evolution. One discipline shaped how I approach the other, and the combination is what makes me effective today.
It’s not about leaving one world behind.
It’s about using everything you’ve learned to see the bigger picture.
1 comment