- Published on
Ten Korean Posts on Technical Writing and Side Projects — Not How to Start, How to Keep Going
- Authors
- Name
- Youngju Kim
- @fjvbn20031
- The first post is easy; the tenth is hard
- How this list was assembled
- Why developers write
- Habits, and where to publish
- From side project to revenue
- Related writing on this blog
- Limits of this list
A note on language. Every linked piece below is written in Korean. The descriptions here are mine, in English, but the destinations are Korean-language pages.
The first post is easy; the tenth is hard
Advice to start a technical blog is everywhere. Choosing a platform and publishing the first post is usually not difficult. The trouble comes after. You have no idea what the second post should be, and around the third your hands stop because it feels like everyone already knows this much. Side projects behave the same way: the early design is fun and you run out of energy just before shipping.
So this list contains almost nothing about getting started. Instead it gathers writing about the conditions that let you keep going: why you write, how to lower the cost, where to publish, and how to carry a built thing all the way through.
How this list was assembled
An editorial pick by one person, not a ranking. I have no way to measure view counts or popularity, and I did not try. I used three criteria.
First, I chose pieces carrying judgment earned from experience. Writing that records where the author's thinking changed after doing the thing was preferred over general summaries.
Second, I excluded anything whose main purpose is selling a course or coaching. Some candidates read like case studies but routed to paid programs throughout the body, and that compromises the reader's judgment, so they are out.
Third, I opened every link and checked it. Candidates blocked from access, returning a service error, or whose content did not match the search snippet were dropped. Several fell out at exactly this step.
Every link was opened and verified on 2026-08-12. Personal blog posts can disappear or change addresses.
Why developers write
All three answer the same question and reach slightly different conclusions. Read together, they make it easier to pick your own reason.
Developer writing
Brunch — 쿠우보이 · January 30, 2019
Argues that programming education cannot stop at code and must include writing and speaking.
Read this if — you have treated writing as separate from engineering.
The central claim is that writing and coding are not different activities. Both are about expressing intent precisely and building a logical structure, so if someone is good at one and poor at the other, the author reads that as a training gap rather than a matter of taste. It goes as far as proposing that documentation and learning logs belong in the curriculum, which opens room to think about this as a team practice rather than a personal habit. An older post, but the argument holds up.
Why I write as a developer
Brunch — swimjiy · July 29, 2020
Frames technical blogging as something done for self-understanding rather than for a resume.
Read this if — you have thought of your blog as a hiring artifact and consequently struggle to keep writing.
This piece identifies that where you locate the motive determines whether you persist. If employment is the goal, the reason to write disappears the moment the goal is met; if understanding is the goal, the reason remains. At its center is the observation that explaining something in writing exposes how much you actually know. Most developers have had the experience of stalling while writing up something they assumed they understood, and this reframes that experience as a learning instrument.
A developer's writing
Velog — 콜트 · July 24, 2021
Proposes principles for writing technical posts more easily, plus a four-way classification of post types.
Read this if — you stop because you feel you cannot write about anything you have not fully mastered.
The most practical piece on this list. The advice to drop topic-consciousness in favor of material-consciousness, and to write at your own level rather than calibrating to the reader, all points toward lowering the threshold for starting. The four-way classification is especially useful, because deciding which kind your post is settles the structure automatically. The advice to stop trying to explain everything and link out for the gaps is realistic too.
Habits, and where to publish
Once the reason is settled, what remains is sustaining it and choosing a place.
How to build a writing habit
Brunch — 글장이 · April 7, 2024
Builds a writing habit out of two devices: repetition and ritual.
Read this if — you intend to write and postpone starting every time.
The useful move here is treating habit as a matter of environment and cues rather than willpower. Write at the same time in the same place, repeat the same short action immediately beforehand, and you no longer have to decide whether to start each time. The line about habits reducing deliberation captures the thesis well. It was not written for developers, which is precisely why it transfers regardless of subject matter.
Writing books for developers
Brunch — gnugeun · May 24, 2023
Recommends several books, from the view that logical writing is a trainable skill.
Read this if — a few blog posts are not enough and you want to study this properly.
It is a book roundup, but the selection criteria are explicit enough to make it worth reading. It separates literary writing from logical writing and starts from the premise that the latter rewards effort more than talent. Splitting general writing books from developer-targeted ones lets you pick whichever side you need now. Recording the errors the author found inside a recommended book raises the credibility of the whole piece.
Comparing blog platforms for developers
Velog — 박은미 · June 15, 2021
Compares the strengths and weaknesses of several platforms and records the reasoning behind choosing one.
Read this if — you have not written a first post because you cannot decide where.
Platform choice is commonly overrated as a decision, which is exactly why so many people stall at this step. This piece lists the candidates, characterizes each, and then chooses on the author's own criteria, which helps you finish the same decision quickly. What matters is that you gain an axis for judging even if you disagree with the conclusion. It is an older post, so each platform's features and policies may differ now.
Is Brunch acceptable as a development blog?
Brunch — 홍기린 · August 8, 2024
Explains choosing a particular platform while fully aware that code display on it is awkward.
Read this if — you are considering something other than the default everyone uses.
Good as a pair with the previous piece, because it is the same decision made on different criteria. This author optimizes for whether responses arrive and whether the reading experience is good, not for feature superiority, and accepts the drawbacks because those criteria match the purpose. It is a demonstration that in tool selection there is no right answer, only fit with intent. The method of deciding on your own criteria rather than deferring to others is itself worth borrowing.
Notes on running a development blog
공부 블로그 Blue log — Lee Jeongan · April 7, 2024
Nearly three years of running a personal blog, sorted into what lasted and what turned out meaningless.
Read this if — you have blogged for a few years and are looking for a reason to continue.
This is a piece only someone with accumulated time could write. It sorts the author's own posts into three kinds and concludes that records of personal experience and growth outlast simple information transfer, a judgment hard to reach without several years of evidence. The observation that a blog becomes an obligation the moment view counts become the goal is accurate. Concluding that a blog is a filter for refining your thinking connects back to the earlier pieces and closes this section naturally.
From side project to revenue
Building and selling are different problems. Both of these address the gap.
A side project from MVP to monetization
Velog — 정선교 · September 25, 2024
A one-year retrospective on running a self-built service from minimum viable product through to monetization.
Read this if — you built a side project and stalled because nobody came.
The largest lesson is the choice to prioritize product quality and fast deployment over marketing. It also records that much of the growth came from search rather than advertising, a structure that matters enormously for someone building alone. When you cannot spend on ads, making something discoverable through search is the only sustainable acquisition path available. Problems encountered working as a team are included too, so it is useful for people starting in twos and threes rather than solo.
Turning a side project into a business with monthly revenue of 45 million won
Brunch — 솔비나 · October 27, 2024
Profiles an overseas solo developer who started a personal finance service as a side project and grew it over several years.
Read this if — you want to know what people who sustain side projects long-term actually endure.
The only piece here reported about someone else rather than written as self-retrospective, which surfaces things personal write-ups tend to omit — notably the early launch mistakes and repeated burnout, treated together. Concrete errors such as mispricing and setting the free trial too long are recorded, so someone approaching the same stage can use it as a checklist. The conclusion that growth came from long improvement and honest storytelling rather than advertising meets the previous piece. Note that this case's figures are one individual's outcome, not a general expectation.
Related writing on this blog
- Persuasive writing for engineers — the stage after technical writing.
- Building a blog pipeline with AI — on verification, not drafting, being the bottleneck.
- Where AI-written text falls apart — what you still have to check yourself when using tools.
- Why Diátaxis gets mistaken for four folders — on why mixing several purposes into one piece collapses.
Limits of this list
Eight of the ten sit on the writing side and only two are side projects. That imbalance was not intended; it is the result of verification. There were many candidate revenue-disclosure posts, but opening them usually revealed pages routing to paid courses or memberships, or pages that would not load at all. Rather than lowering the bar to fill the section, I published only the two that passed.
One thing to keep in mind when reading revenue stories. What gets published is generally the case that worked, and the far larger number of projects begun the same way leave no record. Read these as one person's path rather than as a guarantee of method.