What Is Good Code? On the Illusion of Readability
Breaking Free from the Obsession with Right Answers
Throughout life, we face countless problems. Just looking at the practical ones — education, careers, job changes, finances, growth — we encounter all kinds of missions. And when I talk to people about these things, I often hear them speak as if there’s a predetermined right answer, or at least wishing there were one.
Sometimes it feels like society is the one enforcing these answers. “Get into a good university and life will work out.” “You need to own a home to be happy.” “You need to earn at least this much to be middle class.” Hearing all these conditions and benchmarks, I sometimes wonder: are the decisions I make truly my own, or am I just following standards that society has laid out for me?
Students don’t study to explore and acquire knowledge — they study to match the answers that the majority proclaims as correct. This problem isn’t limited to schools. It shows up in private education, in coding bootcamps, in all sorts of organizations that teach developers. At the end of the day, customers want right answers, so providing right answers is the business.
These formulas for success that society offers have conditioned us. Most problems we encounter in reality are unstructured and have no single correct answer. Yet when we face a problem, we often fall into the illusion that a right answer must exist somewhere.
This social conditioning runs deep in how we think, and developers like me are no exception. So in this post, I want to unpack a concern I’ve been carrying for a while.
The Drive to Find the Right Answer
Developers are, by nature, a group accustomed to seeking correct answers. Given the nature of working with logic, we’re trained to make decisions that are logically sound and grounded in clear evidence.
The “right answers” developers tend to champion usually revolve around code structure and relationships. It’s not uncommon to see someone adopt a monorepo without a clear reason, or introduce a global state management library or memoization without any particular context demanding it.
But as I mentioned earlier, reality isn’t that simple. In most cases, what counts as “best” varies depending on context, circumstances, and who’s interpreting it.
“What is good code?” “Code with good readability.”
I’ve been conducting interviews since 2016, early in my career, and I’ve kept at it ever since. Having done this for so long, I’ve developed a few go-to questions.
One of them is: “What is good code?” It’s a topic I’ve personally pondered for a long time, so I genuinely enjoy hearing different developers’ perspectives. But when I ask this question, a remarkably large number of people answer: “Code with good readability.” With slight exaggeration, I’d say 99 out of 100 give this answer.
Every time I hear it, I feel a subtle awkwardness — because readability is inherently subjective and abstract. The same code can be called readable by one person and unreadable by another.
Sure, there are elements that many people would agree make code more readable — writing in a familiar programming language rather than Egyptian hieroglyphs, for instance. But we all know that’s not the level of readability we’re actually talking about.
Can there really be a technical quality that all ~26 million software developers worldwide would universally agree on? If it’s a value that not everyone can agree on, shouldn’t we question whether “readable code” even exists as a meaningful concept?
With this in mind, when I follow up with “What makes code readable?”, the answers start to diverge. Some emphasize cohesion and coupling. Others point to clear, intuitive naming. Some talk about separation of concerns. In other words, rather than a definition that captures the full essence of readability, most people cite specific real-world examples: “When you do this, readability improves.”
This means every developer has a different idea of what’s most important for achieving good readability — and these varied answers actually reveal just how subjective, abstract, and context-dependent readability really is. It’s like looking at the same painting where one person sees beauty and another can’t figure out what it’s trying to express.
Yet many people answer “code with good readability” to the question of what good code is. As if the answer were predetermined.
“How should I grow as a developer?”
This instinct isn’t limited to developers — it shows up in the big and small decisions we make in everyday life. I occasionally have 1-on-1s and mentoring sessions where I get to hear other developers’ concerns and offer guidance. And in these settings too, I’ve seen the same drive to find the right answer.
The questions and concerns I typically hear go something like this:
- How do I become a good developer?
- What skills should I build to get into company X?
- I want to have this kind of experience in the future — what should I do?
I completely empathize with the motivation behind these questions. When you desperately want to achieve something but don’t know what steps to take, that frustration is something everyone has felt at some point.
The people asking these questions are genuinely passionate about growth and sincerely want to get better. But the problem is that they approach goals like success or growth through overly standardized methods.
As a result, I’ve often seen people follow generic “right answers” that don’t fit their own circumstances, goals, or capabilities, and end up pouring effort in the wrong direction. It’s like trying to force yourself into clothes that don’t fit.
Between the lines, there’s also the idea that if you just put in enough effort — like the 10,000-hour rule — you’ll eventually achieve what you want. I absolutely disagree with this. Time and effort are extremely limited resources, so where you invest them matters enormously. (If you invest 10,000 hours only to discover it contributed nothing to your growth, those 10,000 hours are gone forever.)
What ultimately matters is the direction of where to invest your time and energy. The problem is that while we believe we’ve chosen this direction ourselves, that choice is often the product of standards set by others or by society.
Truth That Shifts with Context, Not Fixed Truth
It’s natural for humans to seek stability and certainty — we’re psychologically wired to be uncomfortable with uncertainty. So this kind of thinking isn’t unnatural at all. If anything, believing that there’s no right answer might be the act that goes against human instinct.
That’s why in the examples of readability and growth I mentioned earlier, many people who were eager to become great developers likely absorbed information from blogs, books, or fellow developers without critical examination. But we shouldn’t overlook the fact that problems like readability and growth simply don’t have predetermined right answers.
In philosophy, concepts like relativism and contextualism are used to explore these kinds of problems.
Relativism holds that truth and value aren’t universal — they vary depending on culture, perspective, and circumstances. This means that standards for readability can also differ based on an individual’s criteria or the situation they’re in.
Contextualism means that whether a proposition is true depends on the context in which it’s used.
For example, the same code might be evaluated differently depending on team culture, the nature of the project, or the business situation.
Many people proclaim “code with good readability” as if it’s the definitive answer to what good code is. But this isn’t a fixed truth — it’s a relative concept that shifts across different contexts.
Of course, since many people treat interviews as a game of guessing the interviewer’s expected answer, some bias may have crept in. But I’ve seen similar responses not just in interviews but also in mentoring sessions and 1-on-1s, so I don’t think the bias is significant. (If you grab any 10 developers around you right now and ask “What do you think good code is?”, readability will almost certainly come up.)
We use programming languages — abstractions built from symbols familiar to humans — rather than machine code precisely because we want humans to easily understand how computers work. So if we could truly achieve “readable code,” there’s no question it would be great code.
But readability is something that inevitably gets judged differently depending on circumstances and context. To glibly declare it as your answer without any fundamental questioning or reflection on what readability actually means — that’s something a programming professional shouldn’t do.
So what criteria should we use to find essential value?
My Choice, or Others’ Expectations?
The first step is to reflect on whether your decisions — or the things you believe are right — are truly your own.
As I’ve mentioned several times, we live in a culture with strong collectivist tendencies. What we believe we decided for ourselves has often actually been determined by others’ or society’s standards.
- Everyone says a developer’s starting salary should be at least X, so I should get at least that much.
- AI is supposedly the next big thing, so I should study AI.
- Big companies test algorithms, I hear. Time to start solving one algorithm problem a day.
- I absolutely must buy a home in Seoul.
- To be at the frontier of technology, I need to move to the US.
I catch myself thinking like this too. Most recently it was: “If I drove a nice imported car, wouldn’t my life satisfaction go up a bit?” It felt great at first, but after about three months it just became normal — I spent the money but never got the satisfaction I was looking for.
In the end, that was a decision influenced by society’s symbols of success, not one that truly came from within. I acquired what’s commonly recognized as a status symbol expecting it to improve my quality of life — a decision shaped by society and others’ perspectives, not my own.
So when the logic “to do A, you must do B” pops into your head, it’s often not the right answer — or more precisely, it might be the right answer for someone else but not for you. That’s why it’s worth pausing to reflect.
Understanding Yourself Is the First Step
The right answer isn’t far away. To find it, you first need a deep understanding of yourself.
You need to know what you enjoy, what brings you joy, what makes you sad. You need to look back and identify what makes your heart race, what activities you lose yourself in. Without this kind of self-reflection, we’re easily swept along by standards that others or society have set for us.
I believe this is an incredibly important factor. Unfortunately, when we’re busy navigating day-to-day life, we spend all our mental energy on external problems and rarely take the time to look inward and reflect on ourselves.
“Self-reflection” might sound old-fashioned and heavy, but it really starts with small questions you ask yourself:
- When have I felt truly happy?
- Why do I go to work?
- Why am I working as a developer?
What matters is checking whether every decision you make truly originates from your own will, and confirming that what you’ve thought and decided actually fits you — like clothes that are actually your size.
I paid a premium for an imported car, but the novelty wore off in three months and I never got the satisfaction I wanted. Yet someone else might do the exact same thing and be perfectly content. It simply wasn’t the right fit for me. (Though I still drive it because it feels wasteful to sell.)
The right answer isn’t far away — it’s inside you. We may live in a society with strong collectivist tendencies, but it’s precisely in such an environment that building your own standards is the path to genuine satisfaction and fulfillment.
Wrapping Up
Existentialist philosopher Jean-Paul Sartre said, “We define ourselves, and the meaning of our existence is something we create.” He emphasized that humans are free to choose, but must also take responsibility for those choices.
This suggests that when our choices come from our own values and standards rather than others’ expectations, we can live a truly satisfying life.
Of course, navigating the real world sometimes requires meeting conditions that society or others demand. But what matters is whether you’re aware of why you’re meeting those conditions and have consciously chosen to do so.
The statement that good code is readable code, or that you need to do this and that to become a good developer — these are just data points among many. Our role isn’t to accept that data as-is, but to filter it through our own standards — taking what fits and discarding what doesn’t.
So rather than believing the data itself is the answer, I’d encourage you to invest deeper thought into the process of using that data as raw material to build your own values and philosophy.
That concludes this post on the illusion that right answers exist.