Ask Dan: How Do I Know If My Developer Is Doing a Good Job?

Q: How do I know if my software developer is actually doing a good job?

A: This is a good question.

The tricky part is that if you're not a developer yourself, it can be difficult to evaluate the work.

You might look at an application and think, "It works. I guess they're doing a good job."

But working software and good software aren't necessarily the same thing.

Here are a few things I would look for.

They Ask Questions

A good developer should ask a lot of questions.

And I mean a lot of questions.

If you're explaining how your business works and your developer immediately says, "Yep, got it," I'd be a little nervous.

Good developers want to understand why you're doing something, not just what you want them to build. They'll ask about exceptions, edge cases, users, existing processes, data, and what happens when things don't go according to plan.

Those questions aren't slowing the project down.

They're helping prevent you from building the wrong thing.

If you are a high-level thinker and are irritated by detailed questions, you will probably not get the results that you want. Be prepared to answer detailed questions or assign a subject-matter expert who can.

They Can Explain What They're Doing

Your developer doesn't need to teach you how to program.

But they should be able to explain important decisions in language you understand.

If you ask, "Why did you build it this way?" you should get an answer that makes sense from a business or technical perspective.

And if the answer is, "Because that's just how we do it," keep asking questions.

They're Honest About Problems

Every software project has problems.

Every one.

Something will take longer than expected. A requirement will change. An integration will behave strangely. Someone will discover an edge case nobody thought about.

That's normal.

What matters is how your developer handles it.

A good developer tells you when something is going wrong instead of hiding it until the last minute. They explain the problem, tell you what your options are, and help you decide how to move forward.

I'd much rather hear, "We found a problem, and here's how we're going to fix it," than hear nothing until the project is already in trouble.

The Software Is Maintainable

This is one clients can't always see immediately.

Good software isn't just built to work today. It's built so someone can understand and maintain it tomorrow.

That means things like organized code, appropriate documentation, sensible database design, and an architecture that makes sense.

Eventually, someone else may have to work on this system.

Maybe that person will be another developer.

Maybe it'll be the developer who built it.

Either way, you don't want the software to depend on one person's memory.

They Understand Your Business

Your developer doesn't need to become an expert in your industry.

But they should understand what the software is actually supposed to accomplish.

The best developers I've worked with don't just think about screens and buttons. They think about the business process behind them.

They understand that the goal isn't to build an impressive piece of software.

The goal is to solve a business problem.

And Here's the Biggest Test...

Ask yourself this:

Has your developer made your life easier or harder?

Do you trust them?

Do they communicate?

Do they tell you when they disagree with an idea—and explain why?

Do they take responsibility when something goes wrong?

Do they seem genuinely interested in solving your problem?

Those things matter.

I've been doing software development for more than 30 years, and I've learned that technical ability is only part of being a good developer.

You can write excellent code and still be terrible to work with.

The best developers I've known combine technical skills with curiosity, communication, honesty, and a willingness to understand the people they're building for.

So if you're wondering whether your developer is doing a good job, don't worry about whether you understand every line of code.

Pay attention to the questions they're asking, the problems they're solving, and the way they work with you.

That's usually where you'll find your answer.

— Dan