Having fast code is essentially the same principle applied to programming. If I am developing, testing, or debugging stuff that can be slow it is worth the effort to make the run time as short as possible. I will truncate test data or use the debugger to run only the section of code I am interested in.<p>What I am saying is well known and obvious, the trick is to remember to do it when you need it! It’s very easy to slip into thinking you will only need to run your 3min runtime code a few times to fix the bug and then end up spending hours on the problem.
This is one of those “duh” concepts that are hard but very high ROI.<p>The whole “become a better writer” is great, the benchmark IMO is when you start to accumulate reusable nuggets like <a href="https://notes.andymatuschak.org/Evergreen_notes" rel="nofollow">https://notes.andymatuschak.org/Evergreen_notes</a><p>Well crafted writing can be leveraged and re packaged for multiple purposes.<p>And even if you only ever write for yourself remember “Better note-taking” misses the point; what matters is “better thinking”<p><a href="https://notes.andymatuschak.org/zAf4oNSV9qB38ncSvYEZGAb" rel="nofollow">https://notes.andymatuschak.org/zAf4oNSV9qB38ncSvYEZGAb</a><p>The articles on this stuff are all missing the “how” though.<p>So how do you get better?
Glad to see someone else reflecting on this. I've been using long form code review for the last ten years of my career with these same goals in mind: concrete and actionable generative feedback. I know other people lurk on PRs, even outside their own teams, and benefit from the concepts. Plus, it's useful for posterity.