本站提供正體中文版。切換到正體中文本站提供简体中文版。切换到简体中文このサイトには日本語版があります。日本語で表示이 사이트는 한국어로도 제공됩니다.한국어로 보기Diese Website ist auch auf Deutsch verfügbar.Auf Deutsch ansehenEste sitio web también está disponible en español.Ver en españolQuesto sito è disponibile anche in italiano.Visualizza in italianoCe site est également disponible en français.Afficher en françaisEste site também está disponível em português.Ver em portuguêsDeze website is ook beschikbaar in het Nederlands.In het Nederlands bekijkenЭтот сайт также доступен на русском языке.Смотреть на русскомयह वेबसाइट हिन्दी में भी उपलब्ध है।हिन्दी में देखेंهذا الموقع متاح أيضًا باللغة العربية.عرض بالعربيةSitus ini juga tersedia dalam bahasa Indonesia.Lihat dalam bahasa IndonesiaBu site Türkçe olarak da mevcut.Türkçe görüntüleTa strona jest dostępna także po polsku.Wyświetl po polskuTrang web này cũng có phiên bản tiếng Việt.Xem bằng tiếng Việtاین وب‌سایت به فارسی هم در دسترس است.مشاهده به فارسی

From "It Runs, Good Enough" to "Confident Enough to Change It": A Rookie's One-Month Coding Diary

AI2026.04

Let me say this up front: I’m not a software engineer, and the coding I’m talking about here is all what people call Vibe Coding—the kind where you just go with the feel of it.

A laptop on a desk showing code, next to sticky notes, a small whiteboard mapping out the editing workflow, a Pomodoro timer, a handwritten coding diary, and a cat mug

Lately, to make my work go a bit more smoothly, I’ve been building my own little tools. Over the past couple of days I did three things: I started backing up with Git, fixed a few bugs in the program logic, and hooked up a new AI model.

The Hardest Part Isn’t the Syntax—It’s Turning What You Want into Code

After a month of this, my biggest takeaway is that the hardest part of coding isn’t actually the syntax—it’s turning “what on earth I want” into “concrete code.”

Take “fixing a bug,” for instance. It’s three easy words to say, but before you actually get your hands dirty, you have to ask yourself a whole pile of questions:

  • Should I save first?
  • Should I open a new branch?
  • When do I test? And how do I test?
  • After I’m done, what counts as “done”?
  • Should I tag a version number while I’m at it?

None of these are really programming questions—they’re questions of “working habits.” This kind of workflow may be commonplace in the industry, but for a coding beginner it’s an absolute nightmare.

A Few Small Things I Learned

Over this one month, I learned a few small things, which I’ll share with fellow beginners like me:

  1. Put up your safety shield first, then start hacking away. Use Git for version control, and even if you break everything, you can be back to the past in thirty seconds—as reassuring as a save point in a game.
  2. Do one thing at a time. Never “just change one more line while you’re at it”—that’s the kind of thing that makes your future self want to bang their head against the wall.
  3. Slow is normal. Get a single small feature working in a whole afternoon? Yes—that’s just daily life. Those get-good-quick tutorials are mostly lying to you.
  4. Write notes for your future self. Otherwise, next time you come back to it, you’ll think someone else wrote the program. (Okay, fine—this program really was written by an AI.)

From “it runs, good enough” to “confident enough to change it,” what lies in between is probably exactly these working habits—the ones that look unremarkable, yet have to be filled in one by one.