Specimen: Developer. A field study in how developers think, on a sample size of one
Abstract
This is an unscientific study of what a developer is: how they think, how they take in information, and what you need to give them so they can complete a task efficently.
The subject of the study is little ‘ole me. Sample size: one. Peer review: none. Ethics committee approval: I asked myself a question and agreed with the premise.
I voluntarily left my development career, which means for the first time since 1995, I can reflect on this specimen from an outside perspective. Released back into the wild, blinking at daylight, I’ve been doing some introspection. It turns out sitting at my computer listening to some AI slop story with terrible AI text to speech conversion working out why I am what I am and what I am needs no… sorry that was a Shirley Bassey moment.
Why did I leave? Well it’s really simple: It simply stopped being fun. Rather than hire new developers, management invested in AI tokens instead and sent us an API key.
I was being converted from a Developer to a AI Hand Holder. The pay was good, the job sucked.
Don’t get me wrong, AI’s a fine tool. It’s a lousy work colleague. I enjoyed using my mind: to write code, to fix code, to work out why Z appeared unexpectedly. I didn’t enjoy checking code and copying and pasting it. Correcting someone else’s work all day isn’t why I love coding. That’s not a developer, that’s a glorified babysitter. Count me out.
What follows are my findings. Some of them will sound familiar if you are one. If you manage one, live with one, or keep sending one tickets that say “it’s broken”, consider this a field guide.
Finding 1: The wiring is different
A developer’s mind is wired differently. Not ones and zeros, whatever the films suggest. Logic processing.
Normal people see a problem and a solution. A developer sees a chain. A leads to B, but it’s gone via C, D and E to get there. Each of those links has to hold, and if one doesn’t, you need to know which one and why.
Then there’s Z. Every developer has met Z. You’ve traced the whole chain, A through E, every step accounted for, and somehow the output is Z. There is no Z. Z isn’t in the code. Z isn’t in the database. And yet, there it is, on the screen, mocking you.
Half the job is building the chain. The other half is finding out how the fuck Z appeared.
The wiring shows outside work too:
- Instructions get debugged. Tell a developer “just pop it on the system” and they’ll ask which system, which environment, and what “pop” means.
- Edge cases are automatic. You say “everyone gets the email”. We think: what if they unsubscribed, what if the address bounces, what if there are two of them?
- “It should work” is not evidence. Should is a word that has cost me entire weekends.
- “Got a quick minute?” is never a minute. By the time you interrupt, I’m holding A through E in my head. Your question takes thirty seconds. Rebuilding the chain afterwards takes half an hour.
Finding 2: We’re not antisocial, we tolerate
The stereotype says developers are antisocial. We’re not. We tolerate.
There’s a difference. Antisocial means we don’t want people. Tolerating means we can do people, we just know exactly what it costs, and we’d rather spend that energy on the thing we actually like doing: code.
So, client-facing meetings? We tolerate them. Asked to lead a training session? I’d rather not. I’ll do it, and I’ll probably do it well, but I’d rather not.
Anecdote #1: The dungeon
I used to go into client meetings and training sessions with at least three drinks inside me.
I’d explain this to the clients, as a joke, but not entirely as a joke. I’m a developer. We’re kept in a dungeon. They let us out for an hour a week, then put us back. So I’m not used to talking, and anything over five minutes needs a bit of liquid assistance.
They laughed. They thought it was a bit. The specimen would like the record to show it was about sixty percent bit.
And the clients loved it. It broke the ice every time.
Here’s the bit that wasn’t a joke. I suffer from anxiety, and self-deprecating humour is the only way I know to break myself in gently while a dozen people stare at me, across a table or on a video call.
That one line did a lot of work. It said: I’m here to teach you. I know how to do this. I don’t particularly want to be doing it, but I was asked to. I’m an expert, but I’m fallible.
Which, as it turns out, is exactly the right thing for a room full of nervous clients to hear. They relaxed, I relaxed, and we got on with it.
Finding 3: You can teach the syntax, not the mindset
I’ve trained developers from scratch. People with no technical background at all. Three of them, in fact, which by the standards of this study is a large-scale clinical trial.
Two succeeded. One didn’t.
The two who made it weren’t the ones with the best qualifications or the most confidence. They were the ones who thought like me. They liked a puzzle. When something didn’t work, they got curious before they got frustrated.
And they asked questions. Questions I can handle. Questions show interest, a keenness to learn. Keep it simple: say one of them asked about an array. How to index it, how to search it, how to sort it. I’d explain it, and off they’d go to work it out.
Sometimes their method was inefficient. It didn’t matter. Nobody was going to notice a few milliseconds. What mattered was that they’d achieved something they never dreamed they could, on their own, under direction. You could see it click. That’s when you know the mentoring has worked.
The one who failed didn’t ask for help. Ever. He was so cocksure, so convinced he was the dog’s bollocks, that asking would have meant admitting there was something he didn’t know.
A few hours in, I’d ask how he was getting on. I’d get some non-committal crap like “almost got it working”.
“Let’s see your work,” I’d say. And he’d subtly roll his chair back, just enough to make room. An invitation for me to sit down and do it for him.
I didn’t. He left the company, involuntarily. Not because he wasn’t clever, but because he was lazy. He never thought at all. There was no chain in his head, no A to B. Just a gap where the work should have been, and a chair pushed back waiting for someone else to fill it.
That’s the finding. Languages, frameworks, tools: all teachable, all temporary anyway. The bit that makes a developer is the itch. If something not making sense doesn’t bother you, no amount of training will put that itch there.
Finding 4: We love researching
Developers love researching. Not in the sense of reading the manual cover to cover first. Nobody does that. In the sense that a problem is an invitation to go and find out.
Issues have reasons behind them. Always. Computers don’t do things out of spite, whatever it feels like at 2am. Somewhere there’s a cause, and the cause can be found.
The process, roughly:
if (reason == unreasonable || reason == beyond_knowledge) {
google(); // or Claude, these days
}
That isn’t laziness. Knowing you don’t know something, and knowing how to find out fast, is half the skill.
A developer who claims to know everything is a liar. Simple as that.
A mechanic doesn’t know how the car was built. He, or she (let’s be modern about this), didn’t design the engine or press the panels. But they can keep it running, and they know where to look when it isn’t. A builder didn’t make the bricks, but knows how to build a house. Given enough tea with five sugars.
The point is that an individual knows their field, but they’re backed up by decades, sometimes centuries, of other people’s experience. And, more usefully, other people’s mistakes.
Sir Isaac Newton, inarguably the greatest scientist ever to wander this poxy planet, put it best: “If I have seen further, it is by standing on the shoulders of giants.”
In case that’s lost on anyone: every fix you build, every line you write, is built on the mistakes and successes of the people who came before you. Somebody hit this exact error in 2009, swore at it for three days, and wrote down what fixed it so you wouldn’t have to.
Look at Stack Overflow, for Christ’s sake. Millions of questions, each one a developer admitting they didn’t know something, and someone else who’d already been there answering. That’s not a weakness of the profession. That is the profession.
Anecdote #2: The scientist. About fifteen years ago I worked with someone fresh out of university, newly minted computer science degree in hand. One day, with a completely straight face and a measure of arrogance, he announced: “I’m now a scientist.”
I had headphones in. I still heard it. And I couldn’t help myself: I burst out laughing at him.
My low opinion of computer science degrees started with that schmuck. All I could think was, you know absolutely fuck all. Newton stood on the shoulders of giants. This lad thought he was one.
A piece of paper says you learnt what someone else told you. It doesn’t say you know how to use it. The real world doesn’t work like that. The real world hands you a client’s site at 4pm on a Friday, broken in a way no lecture ever covered, and the certificate on your wall doesn’t fix a thing.
To be fair, I’ve since met plenty who earned theirs. He wasn’t one of them.
He pissed off to London to start his own web company. I do wonder how far he got. Nope, not researching that one. Lost interest. Moving on.
And the research is often the fun part. You go in to fix one error and come out an hour later knowing how the server handles memory, why a particular browser does that odd thing with dates, and the history of a bug that’s been open since 2011. None of it was asked for. All of it will come in handy eventually.
It’s the puzzle again. The answer exists. We just haven’t found it yet.
Finding 5: Mostly, we build things
Bug-hunting gets the war stories, so it’s easy to forget the main event. Developers build things. Things that didn’t exist yesterday.
I started on the Commodore 64 in my mid-teens, then the Amiga, writing things nobody asked for because I wanted to see if I could. Decades later it was WordPress plugins and themes, a landing page builder that exported static sites, and an exporter I wrote to drag client sites out of Joomla and rebuild them in WordPress. Different tools, same itch.
Building is the same logic chain as debugging, just run forwards. Debugging is standing at Z working backwards to find where it went wrong. Building is standing at A and designing every link so Z never turns up in the first place. It still does, obviously. But you try.
And there’s nothing quite like it. An empty file, a problem, and a few hours later something exists that works. Nobody else might ever look at the code. Doesn’t matter. You know how it fits together, and that’s the satisfaction.
Finding 6: How to feed a developer
This is the useful bit, if you skipped to it.
Developers get fed two kinds of work: something new to build, and something broken to fix. Both need the same thing from you. Enough of the chain that we’re not guessing.
Briefing something new
- The problem, not the solution. “Supporters can’t update their own details” beats “add a button”. You might be right about the button. Let us check.
- Who it’s for. Staff, the public, one admin who logs in twice a year?
- What done looks like. How will you know it works? If you can’t say, we can’t build it.
- What it mustn’t break. The systems it talks to, the data it touches, the things that already work.
- What’s fixed and what’s flexible. Deadline, budget, design. Tell us which ones are carved in stone.
- Examples. A sketch, a site you like, a rough mock-up. Something to point at saves a dozen emails.
Then expect questions. Lots of them. That’s not us being difficult, that’s us building the chain before we build the thing. A developer who takes a brief and asks nothing is the one to worry about. See Finding 3.
Reporting something broken
A developer needs a ticket that says what failed and where. Above all, we need to be able to replicate it. If I can’t make it happen on my screen, I’m not fixing a bug, I’m guessing. And guessing is how Z gets in.
“X has stopped working” doesn’t help. It’s not a ticket. It’s a mood.
The anatomy of a useful ticket
- What you were trying to do. “Submit the donation form”, not “use the website”.
- Where. The exact URL or screen. Live site or staging.
- What you expected to happen.
- What actually happened. The error message, word for word. A screenshot is gold.
- How to make it happen again. Step by step, as if I’ve never seen the site before.
- When it started. And what changed around then. Something always changed.
- Who it affects. Everyone, one user, one browser, one phone?
The same problem, twice
Ticket A: “The contact form is broken.”
Ticket B: “On the live site’s /contact page, submitting the form in Safari on iPhone shows ‘There was an error’ and no email arrives. It works fine on Chrome desktop. Started Tuesday morning, the day after the plugin updates. Screenshot attached.”
Ticket A starts an investigation. Ticket B starts a fix. I can practically see which plugin did it from here.
In defence of pedantry
I was often told I was extremely pedantic. And I’d admit it, very proudly. Yes, I am.
There’s a damn good reason for it. A poor explanation of an issue, or an incomplete specification, wastes time. Worse, it leads to mistakes, and to “fixing” something that was never the problem in the first place.
Imagine the Titanic. Captain Smith’s only question is: what happened? And the officer answers the way most tickets I received were written.
“Something’s not working with the boat, sir.”
That’s it. No mention of an iceberg. No mention of which side, how far down, or the fact that the front compartments are filling up.
So the Titanic carries on. Nobody radios for help. Nobody lowers a lifeboat. The captain only realises it might be more serious when the water’s up to his knees, at which point he turns to the officer and says:
“I think you left something out of your report.”
It’s a ridiculous scenario my brain made up on the spot. But swap the ship for a client’s website and it’s a Tuesday.
Pedantic, yes. Fussy, no. Fussy is caring about the wrong details. Pedantic is refusing to skip the right ones. It’s the logic chain again. Give us A and Z, and we’ll find C, D and E. Give us just “it’s broken” and we have to start by working out what A even was.
Conclusions
After extensive study of one subject, the findings are:
- Developers process the world as chains of logic, and spend most of their time hunting the link that broke.
- We are not antisocial. We tolerate. Occasionally with three drinks.
- The mindset can’t be taught. You either itch when something doesn’t make sense, or you don’t.
- Every issue has a reason. If we don’t know it, we go and find it. Anyone who claims to know everything is lying.
- Mostly, we build. Debugging is just building in reverse.
- Feed us properly. Give us the problem, not your solution. Give us something we can replicate, not a mood. Pedantic, yes. Fussy, no.
The specimen has now been released. It is adjusting well, though it still instinctively asks “can you reproduce that?” when people complain about things that are nothing to do with computers.
Further research is not planned. The subject has declined to be studied again.
Comments (0)