Since I started this blog, I have written in several directions. The areas I keep digging into are web accessibility and frontend. I want to write more, and new ideas keep coming, but the speed of writing is not as fast as I hope. Right now I still have eight unfinished drafts. Starting is easy, but wrapping up always feels surprisingly hard.

AI has made research and organization much faster, but my time and energy are still limited, so it often feels frustrating. I work during the day, and after work I take care of family responsibilities, side projects, this blog, and certification prep. Honestly, I wish I had ten bodies. ^^;; Still, I want to keep going, so today I am writing a candid note about how I approach blog writing.

Personally, I have worked at one company in Daegu for a long time. Because of that, I have not had many external activities, and I often feel that my developer/IT network is thin. I try to widen my circle, but it is not easy in practice. Even so, I hope this blog can help me grow my career and connect with people who share similar interests. Lately I have been asking myself: “How can this blog become more than a record, and open doors to my career and network?”

A small writing setup with a laptop, notebook, and desk lamp.
A small writing setup with a laptop, notebook, and desk lamp.
Image: Created with Nanobanana

The Strengths and Limits of Code-Heavy Posts

For example, the WCAG 3.0 series is relatively easier to write because I read drafts and summarize key points. But posts about accessibility tips or frontend practices are always harder. I assumed developers or people interested in technology were the main readers, so I packed the posts with code.

Looking back, the more code I include, the more the reading flow breaks and the less the message lands. The recent keyboard accessibility post was the same. There is a lot of information, but the rhythm of explanation wasn’t strong enough to make it a post you want to keep reading.

How I Want to Write Going Forward

So I want to change the structure a bit. The key is to strengthen the narrative and separate the code.

  • Explain the ideas more fully before jumping into code
  • Show only the critical snippets in the post, and move full examples to a demo page or GitHub repo
  • Keep the post focused on decisions and context
  • Help readers understand why each choice was made
A scale balancing explanation and code, emphasizing the importance of balance.
A scale balancing explanation and code, emphasizing the importance of balance.
Image: Created with Nanobanana

Of course, I am not sure this is the right answer. People have different preferences, and there is no single correct way to write technical posts. Still, I want to pay more attention to the reading experience from now on.

Feedback Helps More Than You Think

I hope my posts help someone. If you see gaps, I would really appreciate your thoughts. Please feel free to leave a comment or send an email.

And honestly, I even hope my writing reaches AI readers too. I want at least someone to notice it. 😂 (Hey Jarvis, would you like to be friends? Maybe you could talk to me!)

Hey Jarvis, would you at least read my story?
Hey Jarvis, would you at least read my story?
Image: Created with Nanobanana

If you have any feedback, please comment or email me at [email protected]. Advice and experiences from people with similar concerns would mean a lot. I will keep reading and improving.