More on this book
Community
Kindle Notes & Highlights
by
Tanya Reilly
Read between
October 20 - December 20, 2022
Charity Majors’s “The Engineer/Manager Pendulum” is an excellent article on this topic.
Figure 2-2. It’s easy to lose perspective about what other people know (source: https://xkcd.com/2501 by Randall Munroe).
Taking an outsider view
(See the website Is Tech a Meritocracy? for more.)
As Burr tells us, people who aren’t in the room “don’t get a say in what they trade away”
Will Larson’s article “Getting in the Room”
Coordination Headwind: How Organizations Are Like Slime Molds” is a fantastic presentation about the failure modes of bottom-up coordination.
Resources for Writing a Technical Vision
Fundamentals of Software Architecture by Mark Richards and Neal Ford (O’Reilly)
The canonical book on strategy is Good Strategy/Bad Strategy by Richard Rumelt (Currency).
“Getting to Commitment: Tackling Broad Technical Problems in Large Organizations” by Mattie Toia
Bear in mind that getting people to agree isn’t a chore that stands in between you and the real work of solving the problem: the agreement is the work.
technology radar or
Show your work However you make the decision, document it,
“Don’t call for a vote until you know you have the votes,”
Avoid dense walls of text. Use images, bullet points, and lots of white space.
I have seen so many documents die at this point because the authors didn’t know how to make them real.
In my experience, you’ll all be more successful if you stay with it, making sure the work maintains momentum and the plan stays clear as the vision or strategy turns into actual projects.
interviews build up a pattern and let you see what’s going on.
Every new feature change needs complex logic changes in a set of shared components.
You show him the list of challenges you’re not focusing on too, to make it clear that you see them but don’t think they should come first.
Being the least skilled person on a team of superstars will teach you more than being the best person on an otherwise mediocre team.
Working groups can be effective if there’s organizational buy-in, a clear time commitment, exit criteria, and a process for making decisions.
If you tend to let distractions pull your attention in lots of directions at once, try to build the habit of pausing for a few seconds before reflexively volunteering or agreeing to do something.
You don’t get to that level without knowing how to defend your time.”
told that bullet journaling is helpful for letting go of things, because every day you copy the things you still care about to the next page.
it’s that you’re dealing with ambiguity: unclear direction; messy, complicated humans; or legacy systems whose behavior you can’t predict. When the project involves a lot of teams; has big, risky decisions along the way; or is just messy and confusing, it needs a technical lead who will stick with it and trust that the problems can be solved, and who can handle the complexity. That’s often a staff engineer.
number one tool for success—writing things down.
“Working with Product Managers: Advice from PMs”
Remember that tenet of Amazon’s principal engineer community I mentioned in Chapter 2: “Respect what came before.”
senior levels, engineering roles start to blur into each other: the difference between, say, a very senior engineer, an engineering manager, and a technical program manager might not be immediately clear.
Table 5-1. Example table of leadership responsibilities
I’ll just note that RACI turns the preceding list into a matrix, so you can set everyone’s expectations even more clearly.
Avoid the Lake!”
I’m always suspicious when a brand-new project already has a design document or plan, and even more when those include implementation details: “Build a GraphQL server with Node.js to…” and so forth.
If you’re creating a design where it’s difficult to articulate the goals (or if the goals are just a description of your implementation!), that’s a sign that you haven’t spent enough time in this exploration stage.
In The Art of Travel (Vintage), Alain de Botton talks about the frustration of learning new information that doesn’t connect to anything you already know—like the sorts of facts you might pick up while visiting a historic building in a foreign land.
love that quote and think about it a lot while trying to help other people understand something. How can I hook this concept onto their existing knowledge?
Take the time to understand what words are meaningful to the people you intend to communicate with, and use their words when you can. If you’re trying to talk with multiple groups at once, provide a glossary, or at least be deliberate about describing what you mean by the terms you’re using.
written design is a very cheap iteration
The specific implementation should serve the goal; it should not be the goal. Leave the design decisions to the design section.
Wrong Is Better Than Vague
write with active verbs that have a subject who does the action:
“What I Think About When I Edit”: Instead of saying “this” or “that,” you should add a noun to spell out exactly what you’re referring to, even if you’ve just mentioned it.
The Write the Docs website also offers a ton of resources on how to write well.
“Writing code is rarely the highest leverage thing you can spend your time on.
however, that coding gives you a depth of understanding that’s hard to gain otherwise and helps you spot problems. What’s more, “If spending a day a week coding keeps you engaged and excited to come to work, you will likely do better in the rest of your job.”
Think of your code as a lever to help everyone else.
Sometimes it’s better to let someone set a pattern that’s good enough and not overrule them,
whatever you do will set expectations for the team.
