Good code isn't the whole job
Knowing a language, a framework or a database well is the entry ticket. It gets tested at interview, and it matters. But once you're in a team, almost everyone can ship a feature. What separates a good developer from a great one usually happens around the code rather than in it.
Great developers know what they're building and who it's for before they open the editor. They leave behind code the next person can follow without having to ask. They'll say “I don't know yet” rather than guess, and they flag early when an estimate isn't going to hold.
Put simply, the best developers aren't measured by how much code they write, but by how much time their code saves everyone else. Clear, tested, documented work keeps paying off for years. Clever but opaque work costs the team every time someone has to touch it. And most of these qualities never make it onto a CV or into a coding test. Your colleagues are the ones who see them.
The technical skills that matter day to day
Some technical skills carry far more weight in real work than others, because you use them every day whatever the stack happens to be:
- Reading other people's code. Most of the job is changing code someone else wrote, often with no documentation. Finding your way around quickly is worth more than being able to rewrite everything.
- Breaking a problem down. Turning a vague request into small, shippable steps, each one checkable, is what makes a project predictable.
- Testing. Writing tests that protect the behaviour that matters, not just the ones that push a coverage number up.
- Debugging methodically. Reproduce, isolate, form a hypothesis, check it. The opposite of changing things at random until the symptom goes away.
- Thinking about production. Useful logs, clear error messages, monitoring and a way to roll back are part of the work, not a phase that comes later.
- Security basics. Validating input, protecting personal data, and never leaving a secret in the repository.
- Picking the boring option. Resisting the shiny new tool when a proven one will do, and being able to explain why.
What only your colleagues see
A lot of what makes a developer valuable happens in conversations rather than commits. These are the things colleagues mention unprompted when they're asked about you, and the things no interviewer can measure on their own.
Code review is the clearest example. A great review is specific, reasoned and never unkind. It separates what genuinely needs changing from what's a matter of taste, and it suggests a way forward rather than just saying no. Junior developers remember good and bad reviewers for a long time.
Then there's translation. Explaining to a product manager why a tiny-looking change touches half the system, or telling the support team what actually happened during an outage, without jargon and without talking down, is a rare skill. So is turning down a feature by offering a simpler version that meets the same need.
And there's passing things on: writing down a decision when it's made, helping a new starter find their feet, pair programming without grabbing the keyboard at every pause. A team where only one person understands part of the system is fragile, and the best developers know it.
Five moments that separate good from great
These moments come up in every development team. They're also the ones colleagues write about in a recommendation, because they lived through them with you:
- Production goes down one evening. A good developer fixes it. A great one restores the service first, keeps the team and the support desk updated while they dig, then runs a blameless post-mortem the next day and proposes what will stop it happening again.
- Inheriting the legacy module nobody dares touch. Rather than rewriting it from scratch, they start by writing tests around what it does today, then refactor in small steps without breaking what worked.
- A fuzzy request. Before writing a line, they come back with the right questions: what happens if the user cancels, who's allowed to see this data, what should the screen show when the list is empty? It saves the team from carefully building the wrong thing.
- A deadline closing in. They say so as soon as an estimate slips, suggest what can ship on time and what can wait, and write down the technical debt they're taking on so it isn't forgotten.
- A junior's first pull request. They explain each comment, point out what's been done well, and turn the review into a lesson rather than an exam.
Habits that hold good developers back
None of these stops you doing a decent job. They do tend to keep good developers from becoming great ones, and spotting them in yourself is half the battle:
- Rewriting instead of understanding, because someone else's code looks wrong at first glance.
- Optimising too early, or adding a layer of abstraction for a need that doesn't exist yet.
- Staying stuck in silence for hours rather than asking for help after a sensible amount of time.
- Treating documentation, tests or error messages as someone else's job.
- Saying “it's nearly done” for days, instead of being straight about what's left.
- Leaving curt review comments and forgetting there's a person reading them.
- Choosing a tool because it's new, without weighing what it'll cost the team over the years.
What hiring managers look for, and what they can't see
For a development role, hiring managers usually rely on a technical interview, a take-home exercise or a live coding session, and sometimes on public projects or open source contributions. All of these show what you can do on your own, faced with a well-defined problem.
What they don't show is how you work with other people: how you review code, how you behave during an outage, how you explain a trade-off to a product manager or warn them that a deadline's slipping. Yet that's often what tips the decision between two candidates with similar technical ability. With AI coding assistants now part of the job, the human side counts for even more: our guide on AI and jobs explains why judgement and collaboration are hard to hand over to a tool.
Written recommendations from people you've worked with fill that gap. On Take Your Skills, they sit together on a public profile in your name, showing the name and job title of each person who wrote them. You can add the link to your CV or application, or download the profile as a PDF to attach, so the hiring manager reads what your colleagues saw before the technical interview even starts.
Which personality profiles thrive in this role?
There's no such thing as a developer personality, and every profile can do brilliantly in this work, each in its own way. Some natural dispositions do line up well with particular moments in the job, though. The Take Your Skills personality test for work describes sixteen profiles, based on how you'd handle around forty workplace situations. A few links stand out:
- The Clarifier cuts through the muddle and spots the flaw in an argument before it proves costly. That's exactly what debugging a hard-to-reproduce issue asks for, or reviewing a design that's missed an edge case.
- The Fixer stays calm when nothing's working and looks for the practical way out. During a production incident, that disposition matters: the service gets restored, and nobody adds panic to the outage.
- The Builder builds things that last and keeps every promise. Reliable tests, code others can pick up, estimates the team can count on: quiet work that everything else rests on.
- A less obvious one, The Connector, brings together people and ideas that had never met. In a technical team, that's the developer who bridges support, product and code, notices that a support ticket and a product manager's idea are really the same problem, and gets everyone keen to tackle it.
How to get recommendations that show these qualities
The strongest recommendations for a developer come from a mix of perspectives: a colleague who reviewed your code for months, the product manager you shaped features with, your line manager or tech lead, someone you helped settle into the team, a support colleague who watched you track down a customer's issue, or a client if you freelance. Together, they show what no coding test can.
The best time to ask is straight after something memorable: a smooth release, an incident well handled, the end of a contract, or a colleague moving on. Memories are sharp, and people are happy to talk about it. If you're not sure how to word the request, our guide on asking for a reference has messages you can adapt.
On Take Your Skills, the “Ask for a recommendation” button on your profile gives you a link to send by email or message. In your request, remind the person of a specific moment you shared: the outage that evening, the module you untangled together. Whoever writes about you can use an assistant that asks them one question at a time about real situations they've seen you in, then suggests a draft they read and edit before publishing. Their answers are never published, and they're free to write it themselves instead.
As public recommendations come in, Take Your Skills writes your professional portrait, in English and French: the skills people mention most and what sets you apart. For a developer, seeing other people say your reviews or your calm in an outage made the difference often tells a recruiter more than a list of languages.
Software developer reference examples
Here are eight examples, written from different points of view. Swap in the details in square brackets, and above all add one thing only you would know: that's what makes a recommendation believable.
- From a fellow developer: “I worked with [Name] on [project] for [length of time]. What stays with me most is their code reviews: precise, always reasoned, never unkind. When an approach didn't hold up, [Name] would suggest another way in, often with a small example. I learnt more from those threads than from most courses I've been on.”
- From a product manager: “With [Name], a vague request never stayed vague for long. Before writing any code, [Name] came back with the right questions about edge cases and who'd actually use the feature. On [project], that habit stopped us building the wrong thing, and taught me to write better requirements.”
- From a line manager: “The evening [service] went down, [Name] was remarkably calm. The service came back first, the team and the support desk were kept in the loop throughout, and the next day [Name] ran a blameless review and put forward two changes that stopped it happening again. [Name] is the first person I'd call.”
- From someone they mentored: “When I joined the team, [Name] took the time to walk me through how [application] fits together and why it was built that way. My first pull requests were reviewed with real patience: every comment was explained, and the things I'd got right were pointed out too. I found my feet far faster thanks to [Name].”
- From a colleague, on legacy code: “[Name] took on [module], an old piece of code nobody wanted to touch any more. Instead of rewriting it, [Name] wrapped the existing behaviour in tests first, then refactored it step by step. Nothing broke, and today the whole team understands it.”
- From a client, for a freelance contract: “We brought in [Name] to rebuild [application]. Every technical choice was explained in plain English, any risk to the timeline was flagged early with a way round it, and the code was so well documented that our own team took it over without a hitch. I'd work with [Name] again in a heartbeat.”
- From a customer support colleague: “When a customer reports a problem, [Name] reproduces it first, then explains the cause in words I can pass straight on. On [project], those quick, clear answers turned some very unhappy customers into loyal ones. With [Name] around, you never feel on your own with a technical issue.”
- From a product designer: “With [Name], the details matter: error states, keyboard navigation, how a page behaves on a slow connection. When one of my designs raised a technical problem, [Name] told me early and suggested something buildable that kept the intent. On [project], the finished product was closer to my vision than I'd hoped.”