Writing turns ideas into text others can inspect, question, and use. For programmers, it is not separate from technical work: requirements, proposals, API documentation, reviews, chat messages, demonstrations, and posts all carry technical decisions beyond the code itself. A useful writing practice also doubles as a way to learn and retain what you discover. section 2.5.4
Start with material rather than a blank page. Keep notes, outlines, and small ideas in a system; when a new piece is needed, name it and link relevant earlier insights. Those linked notes become building blocks to arrange, compare, and develop. Daily capture can be quick, thorough, or even an ugly sketch—the point is to preserve observations before deciding what they mean. section 2.5.4
Treat writing as a set of flexible habits:
- Write privately when concentration matters, then reopen the work for revision or discussion. section 8.3.2
- Improve shortcuts, autocorrect, and editor suggestions so routine mechanics leave more room for thought. section 8.3.2
- Keep a diary or knowledge record; technical details that seem memorable can disappear surprisingly quickly. section 8.3.2
- When stuck, temporarily switch tasks, then return; perseverance need not mean staring at one obstacle continuously. section 8.3.2
- Build a daily practice, without equating progress with a fixed word count. section 8.3.2
Interruptions make writing especially valuable. Before context is lost, dump the current mental model: the intended test, next action, open question, and partial idea. Syntax and polish can wait. A few unexplained keywords may fail later, though, so either resume immediately or add enough context for your future self to reconstruct the work. section 7.3.2
Leave yourself a restart note
Before answering an interruption, write: “Testing the failed login path. Next: add a test for an expired token; unsure whether the error belongs in the API layer or domain layer. Check the existing refresh-token flow.” This imperfect note preserves the thread of thought and gives the next work session somewhere to begin. section 7.3.2
Draft step by step. You do not need the whole route before beginning; seeing only the next stretch can still carry a project forward. Resist perfectionism in early drafts, seek help from people with relevant domain knowledge, and shape code or prose around real users and colleagues rather than needless flourish. section 8.3.3
