a8b.io

I (very) recently accepted a new position, joining back into the workforce as an engineer. This is a slightly bittersweet and hopefully not final departure from the more entrepreneurial things I've been engaged with over the last few years. However as I shift into this new position, something that comes with it is clarity. It is easier than ever to see what needs to be done and how to succeed in my role. If there is anything I've learned over the last few years it's how to deal with ambiguity and my own moods.

I'm doing my own "pre-onboarding" process where I'm shifting my knowledge intake, that has been primarily focused on entrepreneurial, business, and marketing material to more engineering and domain (insurance) material. One thing that strikes me is how little of the information in front of me I consume now, and how relevant the notes I take are. I used to methodically read books and take very high level notes. However more recently I've become set on this idea that books are subjective. What you'll take from them depends on what you're working on, what mindset you're in, etc. even factual books.

Today I've reinforced the idea that the most useful way to take notes is to take notes on what you think is important. This means your notes are probably less generally useful, but are more useful to you. And that those notes should probably tie to what you're working on. In my case my notes are highly specific for what I think will be relevant to this role. I think a lot of these principles on note taking are similar to what I've seen in the summary of "building a second brain" however I haven't dug into the actual book itself as it's low priority. The way I determined that was from reading the summary and seeing how many things stood out as relevant or surprising. If I read the whole thing and nod my head in agreement to the summary, there's probably not much to be gained

I gave the book Staff Engineer by Will Larson a skim today, and it was quite good. I read the part about writing engineering strategy quite thoroughly as I think the concept is quite new to me. In general I don't think I've operated under written out engineering strategies in the past, and they seem extremely helpful for improving design. The details about how to do it, and the heuristics of when to do it outlined in the book where amazingly useful. Of course the fact that I found this section useful, and not the section on prioritization for example is just dependent on who I am reading the book and what other information I know which is why I say what I take away from things is subjective. There's also a lot of interesting threads w.r.t. links in the book to articles and the books and papers referenced in the back of the book. I think that might be the main reason for me to be convinced to check out a book that I already mostly agree with, would be to check the referenced or recommended material.