What Makes a Good Developer?

From starting my first job as a developer in 2016 to now in 2019 as I write this, I’ve always wondered: what does it mean to be a good programmer, or a good developer? I thought I’d jot down some thoughts.

Back when I first fell in love with programming as a college student, I was a complete techno-optimist. I was hungry for things like researching patterns that fit well with the languages I used, having efficient algorithms become second nature, and creating flexible, extensible designs. The reason I thought this way is simple.

A Technically Excellent Person?

In late 2014, while still in college, I formed a team called Lubycon with some friends and started what I thought was an ambitious(?) dream project — which, looking back now, was pretty insane. Our team composition at the time was roughly like this:

Role	Skill Level
Frontend (me)	All I knew was C and Java from school. Last time I touched JavaScript was in 4th grade.
Backend	Had a web design certification. The only one with any web experience on this team. Took the backend role but had never touched a server.
Backend 2	Electrical engineering major. Also had zero knowledge of databases or web. Too busy to show up often.
UI/UX Designer	In the military. Hadn’t even been discharged yet. Would work occasionally while on leave.
Planner	Korean-Canadian. Music major. Zero IT experience.

Just looking at the team composition, it’s obvious we were a ragtag bunch. Writing this out again, I realize we really were out of our minds. Where did we get that confidence from?

None of us had ever done web development. Ignorance breeds courage, as they say, and here’s the thing — what this group of people was trying to build was a 3D model editor that runs on the web. And that was just part of the plan; there was even more chaos to come after that. (This project taught me the importance of MVPs during my college years.)

Since I was in charge of frontend, I just dove in headfirst and somehow cobbled things together with JavaScript and jQuery. It was my first time doing anything with graphics, and my first time using Three.js, so I struggled quite a bit with the 3D work. But thanks to that, I studied math intensively, and after about three months, I had built a prototype with basic features — loading obj files on the web, changing textures and materials, placing lights to change the atmosphere of the space, and so on.

The nostalgic café next to Hakrim Hall at Dongguk University

At one point, I saw this bald guy more often than my own mother. After completing this, my feelings were roughly like this:

Oh God... I had no idea this was what I was trying to build... What's Euler? What's a quaternion...?

Still, having made it through all that struggle, I felt some pride and developed affection for the result. At that point, I think the idea that a good developer is someone who can whip up technically difficult things took root in my mind.

After Joining My First Company: A Changed Perspective on Business

Then I graduated in 2016 and, luckily, got a job at a startup about two weeks later. This was when I first properly collaborated with people from other roles — not just developers.

When bugs occurred in programs I built, customers would contact the CS team, and the CS team would report bugs to the dev team. Or I’d share ideas with designers and planners while building products. In college, it was all just side projects with friends, so I only had simple concerns like “how do I build this?” But at a company, it was completely different. Here, I had to think about additional things:

---

• What risks or benefits might arise from deploying this feature?
• Should we use an external solution to save development time, or build it ourselves with a long-term view?
• If feature A takes about a month to develop, but we could build two other features in that time, what choice should we make?
• We’ve received a lot of VoC (Voice of Customer) related to this feature — how should we solve it to satisfy users?

---

At the time, designers, developers, and planners freely exchanged opinions on these issues. That’s when I realized that ultimately, the most important things for a company are customers and money.

This might sound obvious. But arriving at this thought has had a huge influence on my values as a developer. Sure, there are many other important things at a company — employee satisfaction, culture, and so on — but customers and money are the fundamentals. No matter how well I build a program, it’s meaningless if no one uses it. And no matter how great a company’s culture and benefits are, if there’s no money, the company will eventually fail. So this was the first time I thought:

Even as a developer, only thinking about technical things might be a narrow perspective. Ultimately, what I’m building is a product that people use, and I should build it for people.

From then on, I thought a lot about how becoming a good developer means thinking deeply about business and users too.

Are Emotions Unnecessary in Professional Work?

I still continue to work at startups. The reason is that I can take on diverse work that wouldn’t be possible at larger companies, and I enjoy freely sharing opinions and deriving rational conclusions through healthy debate.

But it’s not all good. Since people gather together, there are various events — feelings get hurt between colleagues, conflicts arise between team members and the company. Especially since the atmosphere is so free, we treat each other almost like friends, and occasionally, mistakes happen. (Of course, no matter how flat or free the organization is, everyone maintains basic courtesy.)

Some mystery meme someone registered. When you use @everyone mention, this image automatically gets attached...

Among these things, I’ve been thinking a lot about emotions lately. I used to strongly agree with sayings like “separate work and personal life” or “responding emotionally, no matter how difficult things are, is unprofessional.” I still think nothing good comes from emotions getting mixed into professional work. But lately, I’ve also been thinking:

No matter how much you try to exclude emotions, isn’t that impossible since we’re all human?

Whether someone is smart, senior, or junior — they’re all human, so of course there are difficult times and happy times, right? I’ve seen a senior developer dismiss such things as whining and call it unprofessional. Sure, if someone is going around broadcasting their emotions everywhere, that person has issues. But forcing someone to completely suppress emotions that inevitably leak out seems strange too.

Emotions are said to occur through hormone secretion triggered by brain signals. This isn't something you can control by willpower.

Personally, I don’t think of the POs, designers, and developers I work directly with as just coworkers. It’s more like “somewhere between coworkers and friends.” It might sound like splitting hairs, but anyway, I don’t think of them as purely professional relationships. We’re all people running hard together toward the same goal, around the same age, and our values aren’t that different either.

So if a team member is going through emotional difficulties because of something bad that happened, and it’s showing, I think “Isn’t there something I can help with?” rather than criticizing them for bringing emotions to work.

Helping isn’t even difficult. It’s just casually saying “Whoa, you don’t look so great today. Want to grab a coffee?” then going to a café, listening to them talk, and hanging out for 20-30 minutes. Just doing that much might help the troubled team member organize their thoughts, sort out their emotions by talking to someone, and focus better on work again, right?

Humans are emotional beings. I don’t think you can understand anything while excluding emotions. Overlooking this means there can be no healthy communication.

Conclusions So Far

Ultimately, my current thinking leans heavily toward: “Even as a developer, you can’t become a good developer by only pursuing technical things” — if I want to be remembered as “that person was a good person; it was great working together” even after leaving a job.

After all, aren’t developers also workers who must collaborate and communicate with someone? Even freelancers must communicate with clients. A developer who’s simply good at coding won’t be remembered by others as “a developer who’s great to work with.”

The person you want to work with isn’t necessarily someone who’s just good at their job.

An attitude that fully respects someone’s opinion during meetings, even if they disagree with me, even if they have less experience, even if they’re an elementary school student.

An attitude that, when someone is emotionally struggling, helps them recover their pace by listening to their concerns rather than criticizing them for being unprofessional.

Or an attitude that can at least acknowledge that someone felt a certain emotion, even if you don’t understand it.

Having these basic attitudes is what allows you to become not just a good developer, but a good colleague, right? Of course, I’m shy by nature, so I’m not exactly a warm person. (I’ve been told since childhood that I give bad first impressions.) But regardless of individual personality, I believe we should at least have respect and consideration for the people we collaborate with. Personally, I think anyone can improve their technical hard skills if they work hard — the speed might differ, but everyone improves. And I believe developers are already putting effort into their technical specs without anyone having to tell them.

But soft skills like communication and consideration for others are easy to neglect unconsciously unless you pay attention regularly, so I think it’s important to keep reflecting, stay mindful, and maintain an attitude of seeking continuous feedback. Recently, I received feedback from someone on another team that my tone is too stiff and intimidating, which was a bit discouraging. But since then, I’ve been trying to be more mindful of how I speak. I’m not sure if it’s working though… haha

So these are my thoughts and conclusions so far, after four years of working as a developer and pondering what makes a good developer. I still have many more years of work and life ahead, so my current conclusions might change again. But I think “an attitude of consideration for others” remains important whether I’m a developer or doing something else entirely.