How to build a second brain as a software developer

Something that became obvious to me after reading through this is how variant individual learning can be, super interesting to me generally.

Very few of the premises used in the article are how I solve problems or gather information as an engineer, either now or in the fledging times of the start of my career 15 years ago. Consequently, the second brain concept seems less useful for me at least at a glance.

I thought it was peculiar that in the initial flowchart of "problem requiring information" - there is no mention of RTFS (I use that acronym affectionately here), which is probably the most useful skill I have learned in my time building and maintaining software projects. It may be an innocent omission and its admittedly a steep initial learning curve, but I think it it amortizes incredibly well over the span of a whole career.

Not accepting "black magic" anywhere in your stack and challenging yourself to understand why something is breaking can certainly lead to rabbit holes, but avoiding it altogether introduces a significant opportunity cost, in my view.

Maybe trying to strike a balance there can dodge the information asymmetry/inefficiency issue established in the premise of the article. Really interesting read, whatever the truth may be.

Yes, my notes are just a massive log file. I use it as a scratchpad whenever I do something.

I was disappointed that Joplin (https://joplinapp.org/) wasn't included in the app list.

Having used both Evernote and OneNote, I've found Joplin to be a better choice, especially when I'm bouncing between platforms. It doesn't lock you to a particular ecosystem or cloud service, and the open source app is free for use.

For what it's worth, I'm not affiliated with Joplin, I'm just a user.

Articles like this are nice for picking out ideas to incorporate into your own system. I try to avoid reading much "productivity porn" because it gets repetitive and what captures your attention is the novelty of an idea rather than its effectiveness.

There's no system that works for everyone. You have to develop your own, and it will evolve because you change. I started journaling over 10 years ago - it was a simple "daily log" that I only wrote in occasionally. Over time I got more prolific and proficient at it. The structure of that journal became more complex, with different journals for day-job vs personal, multiple levels of summary vs detail planning/notes/ideas, and links between them. I've had to refactor that structure and the taxonomy of tags many times. And much like he describes here, I ended up adding cheatsheets and Q&A and dev templates. *There's no way I'd recommend this system to a beginner.* You have to build your own system according to where you're at in your journey.

I recently took on a new, super complex project and can attest to Obsidian beyond useful. I’ve put all notes and info into it, everything.. and it’s really paid off. I now see this process rather like unit testing whereby the structure of the notes mirrors your own thoughts but with a better, searchable memory.