Redefining Makers

Korean version

We call people who build apps or develop products “makers.” But I think that definition sells them short. Lately, I’ve started to think of a maker as someone who doesn’t just build things but also produces knowledge in the process. It is because while trying to improve documentation in engineering teams, I've noticed something interesting: the people who consistently share knowledge are rarely just passive consumers of information. They’re makers. This might seem obvious, but it points to a deeper truth about how people grow in their careers.

The Maker threshold

Most of us start our careers as knowledge consumers. We read docs, follow tutorials, and implement what others have created. It's necessary, but it's also exhausting. You're always playing catch-up, always dependent on others’ insights.

The real transformation happens when you cross what I call the ‘Maker threshold’. This isn’t just about creating documents or giving presentations. It’s about developing a fundamentally different relationship with knowledge of your work field. Individuals who have contributed significantly or introduced innovative ideas in their field typically develop their expertise through their professional journey.

Look at how Apple's best innovations emerged. Their engineers didn't just implement existing patterns - they observed real users, identified pain points, and synthesized entirely new solutions. They were researchers in the workplace. It happens to us too, even when we don't notice it. In this way, when a consumer becomes a maker, they also take on the role of a researcher.

And developers who use an open-source library at work too. Over time, they become familiar with its limitations and, driven by this experience, contribute their own improvements or bug fixes. So It feels like people who is autonomous and make some differences in work serve dual roles as both researchers and workers.

My journey

I discovered this pattern in my own journey as a technical writer. When I first started four years ago, I was desperate for blueprints. The Korean tech writing scene felt like a desert - hardly any reference materials, few established best practices, no documented success stories to learn from. I did what most beginners do: looked for established patterns.

But something interesting happened after three years of consuming everything I could find. The disparate pieces - documentation patterns, user feedback, failed attempts, successful experiments - started forming their own coherent picture. Now I'm not just writing docs; I'm developing writing principles and teaching our developers how to create better technical content. The shift happened so gradually I almost missed it: I'd moved from seeking best practices to defining them. More importantly, I'm working to make this knowledge scalable. Instead of just producing more documentation myself, I'm helping others become makers. It's a different kind of leverage - one that multiplies rather than adds.

Why Maker Matters

What’s particularly interesting is that this maker mindset seems to correlate strongly with workplace autonomy and satisfaction. I think this happens for two reasons:

1. Knowledge production forces you to think deeply about problems rather than just implementing solutions. You become an active participant in shaping your field rather than a passive recipient of others’ wisdom.

2. The act of producing knowledge creates a virtuous cycle. The more you produce and share it, the more you learn, and the more confident you become in tackling new challenges.

But becoming a maker isn’t just about career advancement or personal satisfaction. It’s about sustainability for individuals and also for teams. Or even far for communities. Maker elevates the entire team and community’s capability. Makers’ writing, insights, discoveries become part of the communal intellectual infrastructure.

The transition from consumer to maker isn’t always comfortable. It requires vulnerability – you have to be willing to share incomplete thoughts, to be wrong publicly, to put your ideas out there before they’re perfect. But that’s exactly what makes it valuable. Like this, today.

Creating Systems for Makers

Fostering a culture of writing documentation, I help the developers on my team not only write but also effectively use documentation. So maybe the real question for me now isn’t how to motivate people to document more; it’s how to create an environment where they can cross the maker threshold. In my role, I’m not just improving documentation processes—I’m building a system where knowledge flows naturally. Once developers cross that threshold, documentation, knowledge sharing, and creation will happen naturally.