I keep hearing the same best practices for work and personal projects, but I’ll admit I don’t always follow every one of them. Recently, skipping a common best practice caused extra stress and rework, and now I’m trying to figure out what really matters and what people ignore in real life. I need honest advice on which best practices are truly essential, which ones are flexible, and how others decide when to break the rules.
I ignore ‘document as you go’ way too often.
Bad move.
A few months ago I shipped a small internal tool fast. I told myself I would write setup notes later. Then a bug popped up. Then I had to hand it off. I spent 3 hours re-reading my own code and old messages to figure out env vars, one cron change, and one dumb workaround I forgot I added. Took longer than building part of it.
My rule now is simple.
- Write the setup steps first.
- Log weird fixes in one file.
- Add comments only where future-you will get confused.
- If handoff risk is high, record a 5 minute loom.
It feels slower on day one. It saves your butt on day ten. I still skip it soms times, then regret it agian.
Mine is ‘always break work into tiny tasks before you start.’
Yeah… I skip that a lot.
Sometimes detailed planning is just procrastination wearing glasses. For small or messy projects, I need to touch the thing first before I know what the real tasks even are. If I force myself to map every step up front, half the list is wrong by lunch.
Where it bites me is scope creep. I start with ‘quick fix’ energy and 4 hours later I’m refactoring stuff nobody asked for. Then I miss one boring dependency and have to backtrack. Super annoying.
So I kind of do the opposite now:
- start ugly
- poke at the problem
- identify the 3 actual blockers
- then make a task list after reality shows up
Slightly disagree with @himmelsjager on one thing: not every project needs extra artifacts right away. Sometimes docs, comments, loom vids, all that can turn into overhead fast. But skipping structure entirely is also how you end up in the ‘why did past me do this’ spiral. Been ther, done that.
My fake best practice is ‘plan first.’
My real best practice is ‘discover first, plan second.’
Mine is “write everything down immediately.”
I ignore that one more than I should.
Not talking about zero documentation. I mean the idea that every decision, meeting note, and tiny change needs to be captured in real time. For me, that can wreck momentum. If I’m in the middle of solving something, stopping to document each thought feels like tab-switching my brain into low gear.
I partly disagree with @himmelsjager here. “Discover first, plan second” works great, but if you also delay all note-taking, you can create a fog where yesterday’s logic vanishes.
What I do now:
- solve first
- pause at milestones
- document the decisions, not the whole journey
- note what would confuse Future Me
Pros for “”: can improve readability, consistency, and handoff.
Cons for “”: extra upkeep, easy to overdo, can become performative instead of useful.
The times this bites me are handoffs and revisits. In the moment, I “totally remember why I did that.” Two weeks later, absolutely not.