How to Know If Your Developer Is Any Good When You Cannot Read Code
The signals that reveal developer quality without requiring you to read a single line of code. These patterns show up consistently across good and poor technical partnerships.
You cannot read code but you can read behaviour. Good developers ask uncomfortable questions before estimating, push back on parts of your plan, surface problems early with proposed solutions, and can explain what they built in plain language. How they handle a production bug is the most revealing test of all.
You cannot evaluate code quality if you cannot read code. This is a real constraint and there is no point pretending otherwise. What you can do is observe the behaviours that correlate reliably with code quality, the signals that distinguish developers who produce durable work from those who produce work that looks fine until it needs to change.
The Signals Before Any Code Is Written
Do they ask clarifying questions before estimating? A developer who gives you an estimate after a 15-minute conversation either has a very simple task or is guessing. Good developers ask uncomfortable questions. What happens if this fails. What does the user do if the data is wrong. How does this connect to the rest of the system. These questions feel like friction but they are the sign of someone who is thinking about the real problem.
Do they push back on any part of your plan? A developer who agrees with everything you say is either not paying attention or is telling you what you want to hear. Good technical partners have opinions. They will tell you which part of your plan is going to cause problems and why.
Get posts like this when they go up no noise, just relevant.
The Signals During the Work
How do they communicate about delays? Every project has surprises. Good developers surface problems early, explain why they happened, and propose solutions. Poor developers surface problems late, explain why it is not their fault, and wait for you to propose solutions.
Can they explain what they built in plain language? Ask them to explain, without jargon, what they built last week and why they built it that way. Good developers can do this. The ability to explain technical decisions in plain language is not a separate skill from writing good code. They correlate.
The Signals After Something Goes Wrong
How a developer handles a bug in production is the most revealing test. Good developers move quickly, communicate clearly, identify root causes rather than just symptoms, and tell you what they are going to do to prevent the same issue recurring.
A developer who responds to a production bug with a clear explanation of what happened and a proposed fix for the underlying cause is a developer who was thinking about failure modes when they wrote the original code.
When to Get an External Assessment
If the behavioural signals are mixed and you need to make a significant decision about the relationship, the most efficient approach is to pay an independent senior developer to spend a day reviewing the codebase and giving you a written assessment. This costs between 500 and 1500 pounds. It is the most reliable way to get an informed technical view without developing technical expertise yourself.
If you are trying to evaluate a current or potential technical partner and want a second opinion, hamza@forgex.systems.
Frequently Asked Questions
How do I know if my developer is actually good if I cannot read their code?
Watch their behaviour rather than their output. Good developers ask clarifying questions before giving estimates, push back on parts of your plan, surface problems early with proposed solutions, and can explain what they built in plain language without jargon. These behaviours correlate reliably with code quality.
My developer agreed with everything I said from day one. Is that a good sign?
It is a warning sign. A developer who agrees with everything you say is either not paying attention or telling you what you want to hear. Good technical partners have opinions and will tell you which part of your plan is going to cause problems and why. Pushback early is a sign of engagement, not difficult behaviour.
Should I be worried if my developer asks a lot of questions before starting work?
No, that is a good sign. A developer who gives you an estimate after a 15 minute conversation is guessing. Good developers ask uncomfortable questions about failure cases, data errors, and how a feature connects to the rest of the system. Those questions feel like friction but they mean the developer is thinking about the real problem.
How should a good developer communicate when something is delayed or goes wrong?
Good developers surface problems early, explain what happened, and propose solutions. Poor developers surface problems late, explain why it is not their fault, and wait for you to propose solutions. The pattern of how they communicate about delays is more revealing than the delay itself.
What is a simple test I can do right now to check if my developer is any good?
Ask them to explain in plain language, without jargon, what they built last week and why they built it that way. Good developers can do this clearly. The ability to explain technical decisions in plain language and the ability to write good code correlate directly, so this test is more reliable than it sounds.
How does a good developer handle a production bug compared to a poor one?
A good developer moves quickly, communicates clearly, identifies the root cause rather than just the symptom, and tells you what they will do to prevent the same issue recurring. A developer who responds to a production bug with a clear explanation and a fix for the underlying cause was thinking about failure modes when they wrote the original code.
Is there a way to get a proper technical assessment of my developer without becoming technical myself?
Yes. Pay an independent senior developer to spend a day reviewing the codebase and give you a written assessment. This costs between 500 and 1500 pounds and is the most reliable way to get an informed technical view without developing technical expertise yourself. It is worth doing before any significant decision about the relationship.
Work with Forgex
If this sounds like where you are, I'd like to hear what you're building.
hamza@forgex.systems
