Snippets 9/8/19
This past week, I was hiking towards an inactive volcano when it dawned on me that I haven't done one of those "bunch of random thoughts" update posts in a while. For whatever reason, disconnecting from technology makes me want to write more, and I've been really digging the newsletter format recently, so let's give this stream of consciousness writing thing another go.
Iceland is a staggeringly beautiful country that seems to have a lot figured out socially, and the hot dogs in Reykjavik are the best I've ever had. Pro tip: if someone asks if you want to try Icelandic fermented shark, say yes. The taste borders on revolting, but it's a culinary experience worth having once in one's life.
Eva Parish, tech writer and editor extraordinaire, introduced me to Semantic Line Breaks, and in the process forever changed my Markdown for the better.
Google released their code review guidelines, a topic that I seem to broadly agree with them on. Surely some of that is attributable to the fact that many of the ideas are straightforward "what would I do if I were designing a good code review process" things, but I'm also sure that there's some shared idea DNA there; the company where I really learned how to code review had some ex-Googlers in its ranks, and it'd be impossible for some of that to not seep into the code review culture there. It's a great document, and I'm really pleased that there are guidelines for code authors as well.
Silvia Botros wrote a great post on being a principal engineer. I'm firmly in the "I have no desire to be a people manager" camp, so it's nice to see writing on what the upper levels of the individual contributor's path are like. In a post filled with great quotes, this one stood out:
[Principal Engineer] is an IC position that is on a different playing field as it involves competencies that no longer apply to only technical prowess. For an engineer to get to the Principal Engineer level, there needs to be cross organizational collaborative signals, there needs to be a clear understanding of architecture and design decisions that go far beyond the immediate technical area of expertise.
I hate the term "soft skills" for a variety of reasons, not the least of which is that the phrase "soft" makes no sense as an adjective describing skills. I'm happy to add "basically required at the most senior levels of IC-dom" to the list. One more:
Once at a certain level, all problems are solved by people. There is no such thing as ‘purely technical problems’.
If I were a craft-y person, I would put that on a poster, frame it, and put it up near my desk.
I stumbled on an old-ish article from Mike McGarr about how he understands culture. The information there is useful, but the pyramid that he uses to visualize culture doesn't make much sense to me. Specifically, "behaviors" and "values"—which are atop each other in the pyramid—feed into each other in a way that's not expressed with that diagram. In fairness, I don't have a better way of visualizing it, though I think a cyclic graph is probably a better start given how much of culture is a positive feedback loop. I also found myself wanting more actionable advice around "here's what you can do to understand your company's culture", but that's probably me wishing for a different article altogether. All critique aside, it's a worthwhile read for anyone who thinks that understanding their company's culture is important (which I hope is everybody. Are there people out there that don't care?)
This was a particularly fun Twitter thread. There's a lot to dig into there, and might warrant a future post.