Reflections Q4 2021

Below are some quotes and reflections from my zettelkasten fed by the books & articles I read in the last few months of 2021.

Show Your Work by Austin Kleon

Main takeaways;

Being a valuable part of a scenius is not necessarily about how smart or talented you are, but about what you have to contribute—the ideas you share, the quality of the connections you make, and the conversations you start.

The best way to get started on the path to sharing your work is to think about what you want to learn, and make a commitment to learning it in front of others.

Become a documentarian of what you do.

“Whatever excites you, go do it. Whatever drains you, stop doing it.” —Derek Sivers…

The First Minute by Chris Fenning

Chris attempts to boil effective communication down to a formula; context + intent + key message. On the whole there's some really good practical advice in here, although, the later chapters were somewhat repetitive and felt slightly too prescriptive.

The longer it takes to state the purpose of your message, the greater the chance your audience will form their opinion of your intent.

You must prepare your audience to receive your message before you deliver it.

When framing a message, ask yourself the following questions: Why am I telling them this? Is there something I need them to do? If the answers aren’t clear to you, they certainly won’t be clear to your audience.

Clear communication starts by getting the first minute right

Outcomes Over Output by Joshua Seiden

It’s common to get caught in this kind of confusion, mistaking “making stuff” for making progress.

When you combine outcome-based targets with a process that’s based on running experiments, you really start to unlock the power of agile approaches.

An MVP is simply an experiment. Teams make MVPs to test an idea.

We have to be honest with ourselves about what we know and what we don’t know.

Building Microservices by Sam Newman

I have not completed this book yet but every page is packed with practical advice and content. My main takeaway so far is to remember to think about microservices as a solution to an organizational problem, not a technical problem.

Rolling out a feature that requires changes to more than one microservice is expensive.

Arguably, with microservices we have made a decision to prioritize high cohesion of business functionality over high cohesion of technical functionality.

Don’t share databases unless you really need to. And even then do everything you can to avoid it.

If we want to make it easier to make changes, instead we need to change how we group code, choosing cohesion of business functionality rather than technology.

Forget About Setting Goals. Focus on This Instead

I'm currently reading Atomic Habits, a book by the same author, which goes into this concept in far more detail. On the surface it's obvious, but it's so easy to get wrong.

If you want better results, then forget about setting goals. Focus on your system instead.

Goals are good for setting a direction, but systems are best for making progress.

Against 3X Speed

I really enjoyed David's points here. His main point boils down to applying the quality over quantity rule to your learning and reading.

Rather than relentlessly flooding your brain with content, be selective on what you really want or need to learn and focus on that, then reflect and revisit regularly. This first quote says it best…

True learning requires contemplation. And implementation. And a commitment to reflecting on great ideas over and over again.

Trivia is an ignorant person’s idea of what knowledge looks like

The smartest people I’ve met reject the “Water in a Cup” theory. They focus less on consuming as much information as possible and more on cultivating the deepest possible understanding of the ideas that resonate with them most…

It’s okay to not know everything…

Spaced repetition yields exponential benefits…

Arthur Schopenhauer: On Reading and Books

Another article with a similar sentiment.

Reading has always been about this website’s tagline: Mastering the best of what other people have already figured out.

In Norwegian Wood, Haruki Murakami makes the argument that "If you only read the books that everyone else is reading, you can only think what everyone else is thinking…"

We need to digest, synthesize, and organize the thoughts of others if we are to understand. This is the grunt work of thinking. It’s how we acquire wisdom.

Reading Better

Start books quickly but give them up easily.

Skim a lot of books. Read a few. Immediately re-read the best ones twice.

Time sorts the books worth reading from the ones that should be skimmed or ignored.

Writing Matters: How to Improve Your Written Communication Skills

When reading, people skim. So, when writing, read it from someone else's perspective. Ask yourself "what would I think if I was reading through this quickly and had never seen the material before?"

As engineering leaders, our jobs become less and less about writing code, and more about writing the expression of large strategies or sets of ideas…

It's Performance Review Season

Shift the focus from why you or others think it’s important for your teammate to change their behavior, to why the feedback recipient might care about changing their behavior…

Don't Soften Feedback

Managers: it’s your responsibility to clearly (and kindly) articulate what’s expected of your teammates in their roles, and what the gaps are.

“Bottom lining” is a skill I learned in coach training: succinctly say, in as few words as possible, what your point is

For each piece of feedback, get really clear about the who, what, when, and where

If you find yourself trying to soften parts of the feedback or make it a little hand-wavy, remind yourself that your teammate deserves to know what specifically they can be doing better, and why. You owe it to them to give them all of the information they need to be successful.

Feedback Equation

Observation (of a behaviour) + Impact (of the behaviour) + Question or Request = Actionable, specific feedback that has a chance of landing.

Writing Better Performance Assessments

How often do you see a response like, “Nothing, he should keep doing what he’s doing!”? How often is their positive feedback generic and useless (e.g. “She’s a superstar!”)? I kick these back frequently and ask them for more specifics. If someone says they can’t think of any improvements, I ask, “What could they start doing that would make you think they were performing at a higher level?”

My Management Lessons From Three Failed Startups, Google, Apple, Dropbox, and Twitter

Cruel Empathy - There’s a Russian anecdote about a man who loved his dog so much that when the vet told him he needed to cut the dog’s tail off he couldn’t do it all at once, so he did it an inch at a time. Don’t be that kind of manager…

Getting Started With the SPACE Framework

Before you even begin to think about metrics, you need to define explicitly what you value as an engineering organization…

There isn’t a one-size-fits-all approach to a sound engineering metrics strategy. The one “silver bullet” metric does not exist. Finding the right approach for you and your team will be a journey, so don’t put off getting started…

The SPACE of Developer Productivity

The most important takeaway from exposing these myths is that productivity cannot be reduced to a single dimension (or metric!).

Myth: Productivity is all about developer activity…

Myth: Productivity is only about individual performance…

Myth: One productivity metric can tell us everything…

Myth: Productivity Measures are useful only for managers…

SPACE, a New Framework to Understand and Measure Developer Productivity

Interestingly, SPACE does not advocate for using all of the metrics at once, rather to carefully select a reduced set of metrics that span across all three levels and capture different productivity dimesions.

What Are DORA Metrics? And Why is Everyone Talking About Them?

“You can’t improve what you don’t measure.”

How We Measure Backstage Success at Spotify

Developer productivity is the ratio of output (i.e., the quantity of work completed) to input (i.e. effort, time). This metric is easy to measure, but it doesn’t tell the whole story.

Developer efficiency is measured by the amount of resources (i.e., time, computation power, human resources) used per unit of best possible output. It accounts for all the input required, so you can see if the team is doing enough of the right kind of work.

(Developer) Effectiveness evaluates important contexts that allow your organization to address low morale, stress/burnout, and other factors that can contribute to poorer quality and high turnover in the long term.

You Need to Practice Being Your Future Self

Being busy is not the same as being productive. It’s the difference between running on a treadmill and running to a destination.

Sometimes you need to be irresponsible with your current challenges in order to make real progress on your future self.

The 10/10/10 Rule for Tough Decisions

To use 10/10/10, we think about our decisions on three different time frames: How will we feel about it 10 minutes from now? How about 10 months from now? How about 10 years from now?

Perhaps our worst enemy in resolving these conflicts is short-term emotion, which can be an unreliable adviser…

The Flywheel Effect

Each turn of the flywheel builds upon work done earlier, compounding your investment of effort…

From the outside, they look like dramatic, almost revolutionary breakthroughs. But from the inside, they feel completely different, more like an organic development process.