Can I Really Say I Know Frontend?

In this post, I want to talk about something a bit more philosophical than the usual development topics. It’s actually a question I’ve been carrying since I first started coding. I still haven’t found the answer, so rather than presenting conclusions, I want to throw out the question and see where it goes.

The question I’ve been mulling over for six years since I started programming is: “What does it mean to know something?”

This question grew out of how other developers perceived me. After about five years of working as a frontend developer across various organizations, I’d received all sorts of feedback from colleagues. Some generous souls would say things like “Evan is really good at frontend,” and I could never bring myself to confidently reply “Why yes, I am.”

The reason is simply that I don’t think I’m good at frontend development. And I don’t trust the subjective assessments others assign to me. What I’ve always wanted — and still want — is to be a “good developer” with objective, universally acknowledged value.

People’s standards differ, of course, but I think “being good” by objective standards means having mastered a body of knowledge. And if you ask whether I’ve mastered frontend development, the answer is obviously “no.” There’s still so much I don’t know, and I spend every day fumbling through new problems and praying to the Google gods.

So for six years, I’ve been wrestling with: “What is true knowledge?”

I “Was” a Good Developer

I didn’t always have this existential crisis. Looking back, it’s quite laughable and arrogant, but when I first started coding, I genuinely thought I was talented and learned remarkably fast.

In 2015, I was working as a sound engineer at an entertainment agency. That’s when a colleague and I started talking about building a product together.

But neither of us knew anything about web development, so we rallied every connection we had to find people who could build it with us. That’s how Lubycon was born — the side project team I’ve been part of for six years now.

My role on the team was frontend developer. That’s when I first started self-teaching programming while building the product. I later quit my job, went back to college, and filled in the gaps in my CS knowledge through coursework. It was a period of rapid growth.

The Days of Walking Tall

In 2015, Angular was just starting to gain traction but wasn’t yet as mainstream as React or Vue are today. Naturally, I started with jQuery.

jQuery gets treated as a relic these days, but at the time it was considered quite innovative — a library that let you select and manipulate DOM elements using CSS selector syntax. I got comfortable with it faster than expected. (document.getElementById('foo') becoming $('#foo') felt like magic…)

The Lubycon service needed a viewer that could upload and rotate 3D model files like obj and fbx on the web, plus a simple model editor for materials and skybox backgrounds. That’s how I first encountered WebGL.

The good old days of building an OBJ parser...

WebGL isn’t something most service developers ever touch, and using it fluently requires a basic understanding of computer graphics and linear algebra — so the learning curve is steep. Whenever I told other developers “I’m building this thing with WebGL,” most would react with “Whoa, isn’t that insanely hard?”

Hearing that reaction often enough, my shoulders naturally puffed up. I gradually developed the cocky thought that “I’m a good developer.” But one day, that naive self-image got absolutely demolished — and that was the beginning of the existential questioning that continues to this day.

I Actually Knew Nothing

One day, a friend invited me to a meetup called Code For Seoul. When I showed up, there were hardly any junior developers like me — mostly seasoned seniors with serious experience. (The vibe was genuinely warm and welcoming though.)

As we sat around eating snacks and chatting about tech, someone asked me the usual question:

I heard you do side projects — what are you building?

I gave my standard answer: “I’m using WebGL to build a simple web editor and viewer.” But the reaction was nothing like what I was used to.

Instead of the typical “Whoa, that’s hard!”, these veterans started drilling me with questions about WebGL’s performance characteristics, memory leaks during canvas rendering, and how I was handling them. I hadn’t even known these issues existed, so all I could do was stand there looking lost.

What made it even more jarring was that the person asking these questions wasn’t even a developer — he was a DA (Data Analyst). That’s when I realized something important.

The world is vast and full of experts... I wasn't even a frog in a well — I was a tadpole.

It makes sense, of course. The gap between a college student and someone with 10+ years of industry experience is enormous. I was “pretty good for a student” inside the walls of school, but in the real-world jungle, I was just a tadpole.

The guy who asked the questions laughed it off with “Well, you can’t know everything” — but I was so embarrassed I wanted to crawl into a hole. Or dig one and crawl into it.

I’d been strutting around just because I was using WebGL, a technology with a steep learning curve. But the truth was, I could merely use the WebGL API — I didn’t actually understand the technology.

Six years have passed since that day, and I still can’t bring myself to claim I’m good at anything. When someone says “Evan, you’re good!”, I reflexively reply “Being able to do something and being good at it are different things.” It’s practically a reflex at this point.

That’s when I first asked myself:

How much do I need to know before I can say I’m good at something?

Am I a Frontend Developer?

I don’t think I’m the only one who’s had the experience of realizing that something they thought they knew well was actually something they didn’t understand at all.

The question started as “how much do I need to know?” but after cycling through it repeatedly, it eventually evolved into “what does it even mean to know something?”

Before we dive deep into the nature of knowledge together, let me offer a quick example for those who haven’t had this experience — to illustrate just how fuzzy the concept of “knowing” really is. Here’s the question I want to pose:

Are frontend developers and markup engineers the same position?

For context: in the Korean tech industry, “publisher” (퍼블리셔) is a common title for specialists who primarily handle HTML/CSS markup. This distinction between “frontend developer” and “markup engineer” exists in many tech ecosystems under different names — “HTML/CSS developer,” “UI developer,” “web designer who codes,” etc.

If you work in this industry, you probably have opinions about these roles and how they differ. Let me push the question further:

Can you distinguish between these two positions? If so, what criteria do you use?

What I’m really asking is: what’s the clear, definitive line between the two?

Both positions build web clients. Yet people draw fairly rigid distinctions between them. So presumably, they know how to tell them apart.

Generally, a frontend developer is someone who writes client programs that run in web browsers — defining DOM structures with HTML, exchanging data with backend systems using JavaScript, building standalone client applications, and sometimes crafting elegant UI/UX with CSS.

But laid out like that, it sounds a lot like what a markup engineer does too. In fact, when you look at actual day-to-day work, they’re often identical.

Some say markup engineers aren’t frontend developers because they don’t know React or Vue. But then what about the people who used to build complex web clients with jQuery? Were they markup engineers? Yet the industry clearly recognized the title “frontend developer” at that time — I was called one myself.

Others say markup engineers lack the JavaScript or computer science knowledge that frontend developers have. Okay, then let me ask this:

How much JavaScript does a markup engineer need to know to be called a frontend developer? Does simply acquiring CS knowledge instantly make someone a frontend developer?

This is where answers diverge. Some might say you need to understand closures. Others might say closures don’t matter, but you should be able to resolve CORS policy violations on your own.

Let’s say knowing closures fluently makes you a frontend developer. But is a rough understanding of the concept enough? Or do you need to know how function scopes and closures are created within the JavaScript engine? It’s ambiguous.

What criteria were you using to separate these two positions? Were you actually clear on those criteria? Or was the distinction meaningless from the start?

Be Socrates, Not a Sophist

If you couldn’t properly answer those questions, then you don’t truly know the difference between the two roles. Or perhaps the difference never really existed at all.

Through this example, I wanted to show that things we think we understand well may turn out to be not so well understood when we look closely.

We perceive positions like frontend developer, markup engineer, and full-stack developer as clearly delineated categories. But when we try to define the exact criteria, we either can’t answer or everyone gives a different answer — as if no clear standard exists.

Our lives and the programming we love are littered with problems like this. We just never examine them because we assume we already “know.”

Socrates was one of the people who thought deeply about this. He was famous for going around to the Sophists — the reputed intellectuals of his time — and asking them questions to find out what true knowledge and wisdom really meant.

The Sophists Were Pretty Smart People

In Socrates’ Athens, society essentially ran on rhetorical skill. The Agora at the city’s center was always buzzing with debate, and you could build political power by winning citizens’ support through public speaking.

Citizens frequently sued each other too, and since there was no concept of professional lawyers representing you, you had to argue your own case in court. Simply lacking knowledge or eloquence could cause real, tangible harm.

Ancient Athens: the era when you literally talked your way through life

So Athenian citizens naturally valued the knowledge and eloquence needed for debate. Enter the Sophists — Athens’ premium private tutors.

Sophists charged fees to teach rhetoric, argumentation, and oratory. Since you need extensive knowledge to teach others, most Sophists were renowned orators and philosophers of their day.

Socrates was actually eloquent enough to work as a Sophist himself, but he believed he wasn’t teaching people — merely drawing out knowledge they already possessed through questioning. So he taught for free, which naturally made him unpopular with the other Sophists.

Then one day, Socrates received an oracle from the Temple of Delphi that would spark his lifelong quest into the nature of knowledge.

I Know That I Know Nothing

The oracle declared that Socrates was the wisest person in Athens. In an era still governed by mythological thinking, oracles carried the weight of law. But Socrates refused to believe it and resolved to find someone wiser than himself.

From then on, Socrates went around questioning the Sophists — the highly-paid intellectual elite — to gauge how wise they truly were. If we map Socrates’ line of questioning onto our earlier topic, it would go something like this:

Q: What is a frontend developer? A: Someone who has the knowledge needed to build web clients and can actually implement them.

Q: Then isn’t a markup engineer also a frontend developer? A: No.

Q: What’s the difference between the two? A: I’d say markup engineers have less computer science knowledge than frontend developers.

Q: So if a markup engineer studies computer science, do they become a frontend developer? A: I think they’d also need to get hired as a frontend developer to truly be called one.

Q: So the position assigned by a company matters? A: …I suppose so.

Q: Then if a frontend developer at a prestigious tech company takes a markup engineer position at a web agency, are they a frontend developer or a markup engineer? A: … (contradiction)

This was Socrates’ method. He’d ask fundamental questions, and when someone answered, he’d probe the inconsistencies in their response with follow-up questions. After a few rounds, the Sophists would hit a wall — realizing that what they “knew” was actually flawed. They’d become flustered or angry.

This state of being shipwrecked on contradictions and impasses is called "aporia"

After visiting Sophist after Sophist and finding that none could fully withstand his questioning, Socrates concluded: “These people don’t truly know anything.”

What about you? If Socrates questioned you about programming, or about the criteria separating frontend developers from markup engineers, could you answer all the way to the end?

If you could, then at least on that topic, you’ve bested Socrates. But if Socrates came at me with questions like those, I’d probably answer earnestly for a while before inevitably falling into aporia myself.

And this method of questioning wasn’t just for the Sophists — Socrates applied it to himself too. After repeating this process over and over, he arrived at a single realization:

The only thing I know is that I know nothing.

This was a statement directed at himself as much as at the Sophists. Neither you nor I truly know anything — but at least I know that I don’t know.

And Socrates’ conclusion isn’t wrong, either. You have to acknowledge your ignorance before you can pursue deeper truth. Someone who thinks “I already know this” won’t dig any deeper into the subject.

Naturally, the Sophists didn’t take kindly to Socrates’ attitude. He was eventually charged with “corrupting the youth and undermining Athenian traditions.”

He could have survived the trial by playing politics and talking his way out, but Socrates refused to bend his convictions. He gave a provocative defense that antagonized the jury, effectively sealing his own fate with a death sentence. (He could have applied for exile to another city-state, but he chose to drink the poison instead — a true hard case…)

In the end, this man chose the hemlock

Even someone as brilliant as Socrates, after all that deliberation, arrived at “I know nothing.” It’s an almost absurdly anticlimactic conclusion.

Wrapping Up

After this long exploration, my question has merely shifted from “What is knowledge?” to “Do we truly know the things we think we know?” — without actually finding an answer.

I suppose it makes sense that I can’t easily answer a question that even Socrates — counted among the great sages of history — could only resolve with such an empty-sounding conclusion. But since becoming an “objectively good developer” is my ultimate goal, I need to find my own answer to this question. So the pondering will continue.

This post was never meant to provide answers. Even before writing it, I’d spent six years turning this over in my mind, and all that happened was that questions bred more questions, diving ever deeper, without catching even a thread of an answer.

I know that when you’re busy working and studying, philosophical musings like these are easily forgotten. I know there are more urgent things to worry about at work tomorrow. (I’ve got a mountain of work piled up too…)

But sometimes, stepping back from direct programming concerns and looking at things from a distance can be more helpful than you’d expect. That’s why I wanted to share my struggle — in the hope that you might give it some thought too.

That’s all for this post on whether I can really say I know frontend.