I’m curious about PKM workflows and systems that can help software engineers and people like them develop their knowledge. In some ways, developers are the classic knowledge worker case study, but it seems rare that I see systems and workflows for people like this discussed.
Does anyone have examples of systems and workflows of programmer-like people? Have you noticed a lack in this area too?
I agree, there are a lot of resources about the different PKM tools, extensions… but how to develop a workflow that suits different tasks or jobs is another challenge.
I work in AI so my approach is a little more research oriented than a system only dedicated to software engineering, but I think most of it could still apply.
I have “operational” and “encyclopedic” notes.
I think some people would call my encyclopedic notes evergreen notes. It’s my notes about Python, about libraries, web service and my experience with them, etc. They live in the root of my vault. Most of my encyclopedic notes are actually empty: I only use the backlinks to my operational notes. That way, I get a history of all the times I had trouble with [[LibraryX]] while I was working. It’s a good way to find the answer to a question I know I solved a few months ago, for instance.
Operational notes are anything that is related to a task, a job, etc. and that is well defined in time. I put them in two places. First they go in my daily notes. If they get too big, I create a mini-report in a folder I called “Documents” for lack of a better name. In a mini-report, I always take care to describe the context, and then what I did and what was the result. I mark the releveant project at the beginning.
I like the “mini-report” method better because I find that most notes are not useful without context. Even if I write: “I solved problem X with stack overflow post Y”, sometimes it’s difficult to understand what really happened without context if a lot of time has passed. So I always have a paragraph at the beggining like
As I was working on [[Task]], I considered using [[API]] for problem x. I evaluate this API because [[OtherAPI]] was not doing the job (see [[2022-03-03 Mini Report Title]]).
and so on.
I also have a note for projects, for instance PROJECTX2022. I mark all the notes I do for this project with [[PROJECTX2022]]. Then, if I want to recall how I solved a problem and I know i did it in PROJECTX2022, it’s easy to find with backlinks. I can easily search for my notes on how I used [[LibraryY]] in [[PROJECTX]] using a query. Also, I have Dataview queries in my project pages make the list of all the mini-reports I have for a given project, ordered by date.
I hope this gives you ideas on how to write down your own notes.
I think the key is to remember not to write down code snippets and notes that you can easily google or ask ChatGPT about. I Like the idea that david said of writing about your own experience with tools and problems.
I experience this challenge to and intend to noodle on it again in the near future.
In terms of “learning”, my ideal approach would be to keep what I capture broad to aid connection and to avoid recreating another existing knowledge base. If I come to know something vaguely enough (perhaps some relevant key words in my own phrasing), that vague recollection can draw me back to the appropriate resource in my vault using search or topic notes. This way, I like it to be more of an interface to other sources of knowledge, and the knowledge of existence of that thing and what it’s about/why it matters is what I want in my PKM.
Similar to the above folks, I write notes on experiences, and that is usually within task notes where I think through a task.
Thanks for sharing @davidlandry! Your operational notes remind me of “engineering notebooks” that I’ve heard about in the past. I tend to think that notes are better for developing knowledge rather than helping me remember things (though both are important). In the past I’ve tended to focus too much on collecting data and not actually learning via making notes.
I’m genuinely curious, how often do you find yourself digging through your mini-reports and finding something that helps you weeks or months later?
I agree, although when I’m trying to learn an API, there are some commands and such that I want to install in my brain but I know I will need a reference in the beginning. For these, I make a note that acts as a “cache” for going to google or chatGPT.
For those interested, I’ve been working on a little guide for myself re: PKM practices for programmers, devops, ai, and data folks. I made the note public for sake of feedback: Mikepedia :: PKM for Coders.
I don’t have all of the linked notes fleshed out yet and there are definitely some missing pieces. My sense is that there should be enough good practices to actually build a course about this. it seems like very underserved group. I think like @davidlandry did above, it’s important to name various types of notes and how they might connect to each other.
Yeah it’s a good question. I think it relates to the fact that I do research. Information i might need to dig up months later: the source of a particular statement, the reason why I did such or such choice, or deciding which results are affected by a bug I found later. When I meet someone, I also really like to know what our last interaction was, so I tend to tag people’s names in meeting notes.
I argue my system works for learning but it does deserve some explanation. I use the mini-reports when I have “an idea” (Zettelkasten like). For instance I have a note called “20230101 Cards are documents” where I come up with the idea that I can use the documents for Zettel-like content, instead of having a separate folder for cards. Another example that I would call learning is “20230205 Dataset Management Tools Reseach”. Here I wrote down all the tools I considered and why I chose or rejected them. This last example is useful to prevent “thinking loops” where you come back to consider the same ideas periodically because I didn’t write it down the first time.
@davidlandry Interesting. The work I do is more oriented around building prototypes, production systems, and leading teams. There is a lot of PKM methodology talk around the research / writer role (especially in the Zettelkasten realm!). I’ve been thinking about if being a software engineer is relevant to that role and it’s associated workflows, or if it is something else entirely.
Recording decisions is something that has been common for a long time in the tradition of engineering + lab notebooks, so you are on firm ground there!
For others who come to this thread, I’m still hoping to hear from others who code or work in software engineer adjacent fields, what are your PKM workflows? What are you recording in Obsidian (or other tools), how do you know if it’s worth writing down, and what prompts you to come back to it? There have to be more of you out there that have found useful ways to work with information and develop your knowledge 
In the meantime, I’m still recording some of my workflows at the PKM for Coders link posted above. Recently, I fleshed out why/how I create Placeholder Notes.