You must log in or # to comment.
I just remember things. Usually I think about the next steps in a projects while cycling or something. And then I implement them.
I tried using trello and similar couple of times but in the and I would barely use it and eventually forget to update it.
I have a more mixed approach.
Decisions or attempts, i try to document them as comments on the ticket. It feels a bit like a conversation with my future self 😄
Things that pop up in my head that I don’t want to forget, but don’t have time to write out, I put in a new tab on nodepad++
Archi things go as markdown in de source code
Investigations and reports in a wiki
All these have all the pros of an engineering handbook out of the box (date, issuer, …)
I only use paper for the stuff I don’t want a trail off and just want to throw away afterwards.
This article mentions “writing by hand” but I’ve gotten a lot of value out of using project specific markdown files for keeping track of project info, logging discussions and decisions, and generally keeping a small knowledge base. These have been wildly useful for remembering small details and project histories, and if you sync them between devices, you always have access to your project notes!
I like the idea of documenting what I’m doing all that, but I have a hard time rationalizing what should actually be recorded.
like if I’m debugging something, and I’m putting silly print statements to quickly troubleshoot, should I document that?
there are certainly times where it makes sense to have a record, but there seems to be many more instances of not needing it at all, which then makes you see recording it as a silly formality, which then kills any motivation to continue recording.
I don’t currently have any sort of notebook. Instead, for general notes, I prefer A3-sized loose sheets of paper, since I don’t really want to use double the table surface to have both verso and recto in front of me, I don’t like writing on spiral or perfect bound notebooks, and I already catalog my papers into 3-ring binders.
if I’m debugging something, and I’m putting silly print statements to quickly troubleshoot, should I document that?
My read of the linked post is that each discrete action need not be recorded, but rather the thought process that leads to a series of action. Rather than “added a printf() in constructor”, the overall thrust of that line of investigation might be “checking the constructor for signs of malformed input parameters”.
I don’t disagree with the practice of “printf debugging”, but unless you’re adding a printf between every single operative line in a library, there’s always going to be some internal thought that goes into where a print statement is placed, based on certain assumptions and along a specific line of inquiry. Having a record of your thoughts is, I think, the point that the author is making.
That said, in lieu of a formal notebook, I do make frequent Git commits and fill in the commit message with my thoughts, at every important juncture (eg before compiling, right before logging off or going to lunch).
I do more or less this for work tracking and meeting minutes, but in org-mode so I can grep notes later. I prefer writing by hand otherwise, though.
I think I like the idea, but I’m not sure I get what this is… could you share a couple pages?
Wow - I applaud the effort but that’s… a lot.
I have frequently used notebooks to sketch out high-level ideas and designs which in itself seems to be a rarity. But at the “It’s detailed enough that someone else could come along and replicate the steps” level is unfathomable to me.
Having to write out what I’m going to do on a physical medium is orders of magnitude slower than typing it out and would just take ages. Maybe it’s just a lack of discipline thing but for me coding is a ton of trial / error / re-write. I refactor code constantly. But it has inspired me to maybe keep more of a log “generally” for things I’ve been working on. It can be useful to be able to refer back to notes rather than needing to dig through emails or git logs hoping to find some rational for a decision…
