Recently, during a mentorship session with a junior developer, we stumbled onto a topic that surfaces often but isn’t always discussed directly: what does “good” code really mean?

This developer was feeling disheartened because their test code looked, in their words, “ugly.” It followed more of a procedural structure, and compared to the more architecturally polished areas of the codebase, it stood out. They assumed this made it bad. But what they were really reacting to wasn’t the quality of the solution — it was the aesthetic of a pattern not matching what they perceived as “the norm”.

This sparked a deeper reflection in me on what makes a developer good at software design. It’s tempting to think of design skill as a binary trait — you either have it or you don’t. But that’s not how it works.

In reality, the ability to design thoughtful, effective solutions is a skill that can be learned and sharpened. It’s more like a muscle: the more you use it, the stronger it gets.

The Social Dynamics of Software Development

Software development is, at its heart, a social activity. Its a team sport. It involves teams, shared goals, competing priorities, and — inevitably — opinions. The culture of a team or an organization plays a powerful role in shaping how developers think about their work. In these environments, certain patterns, architectures, and idioms rise to prominence not just because they’re effective, but because they become socially accepted as “the right way” to solve problems.

These practices emerge from real experience. They’re the product of countless developers facing common problems, testing ideas, failing, iterating, and eventually settling on approaches that work well most of the time. That’s valuable. But problems arise when these best practices are treated as gospel rather than guidance.

When developers prioritize convention over comprehension, they risk missing the core purpose of their role: solving problems.

Pattern-Following vs. Problem-Solving

One of the habits that many developers — especially those newer to the field — fall into is seeking the “right way” to solve a problem by finding what others have done before. This instinct makes sense. The software community is rich with shared knowledge, and accessing that knowledge can help you move faster and avoid common pitfalls. But this can become a crutch.

There’s a fine line between learning from others and outsourcing your thinking entirely. Blindly applying design patterns without deeply understanding the problem at hand can result in solutions that are over-engineered, misaligned, or unnecessarily complex.

Design, in its purest form, emerges from clarity. Clarity about what problem needs to be solved. Clarity about constraints, goals, and trade-offs. And clarity about how different approaches might achieve or fail those goals. The most elegant and effective designs are not born from following rules, but from deeply understanding the challenge and reasoning deliberately through the solution space.

The Importance of Building the Right Reflexes

As developers gain experience, they encounter increasingly complex problems — problems for which no Stack Overflow thread has a silver bullet. In these cases, design skill becomes critical. And the developers best equipped to handle them are those who’ve built up the reflex to pause, analyze, and think critically before reaching for their favorite design pattern.

This is why it’s so important for junior developers to start exercising these muscles early. While they may rely more on convention at first — and understandably so — that shouldn’t exempt them from the responsibility of thinking critically. Teaching them to treat best practices not as answers but as hypotheses encourages them to ask better questions: Why does this work? In what context does it succeed or fail? What are the trade-offs?

By cultivating that lens, they don’t just use patterns — they understand them. And in understanding them, they gain the power to improve on them.

Manifest Design

Design is not a discrete activity layered on top of coding. It’s not something that happens only in UML diagrams or architecture documents. Design is the natural result of a developer engaging deeply with a problem, reasoning through the solution space, and making decisions rooted in that understanding.

To do that well, a developer must prioritize clarity above all else — clarity about the problem they are solving, and clarity about what they need to optimize in order to attain the solution. Only then can they begin to test hypotheses and measure the fitness of their design against the goals it is meant to achieve.

Conclusion

The next time you find yourself writing code that feels “ugly,” pause to ask: what problem am I solving? Does this solution serve that purpose well? If it does, maybe it’s not ugly at all — maybe it’s just unfamiliar. Over time, with repetition and reflection, the skill of turning clarity into design becomes second nature. Not because you’ve memorized the right patterns, but because you’ve trained yourself to truly understand problems before reaching for a solution.