Kotlin

Kotlin Cheatsheet

A Kotlin cheat sheet is a quick reference guide that provides a concise summary of the most important Kotlin syntax and features. Most of the content in this cheat sheet has been collected from the official Kotlin documentation while avoiding detailed explanations. This cheat sheet is designed for quick review purposes and not for providing detailed information, so I suggest that you also read the official Kotlin documentation.

If there is any issue, please open an issue or feel free to contribute to its expansion. If you’d like to support me, please give a star to this repository.⭐

Kotlin logotype

Introduction
Control Flow
- If-else
- When
- Conditional Expression
- For loop
- Ranges
- While
- Do while
- Break and Continue
- Exceptions
Functions
Collections
- Array
- List
- Map
- Set
Classes and objects
Other Topics
Kotlin Keywords and operators (Document link)

Introduction

Kotlin is a modern, open-source programming language that is used for building multi-platform applications. It is concise, expressive, and powerful, with features such as null safety, extension functions, lambdas, and many others. This cheat sheet will cover some of the essential Kotlin concepts.

First Kotlin program

This is an example of printing “Hello world” in Kotlin:

fun main() {
    println("Hello world")
}

Get input from user

To get input from the user in Kotlin, you can use the readLine() function. This is an example:

fun main() {
    print("Enter your name: ")
    val name = readLine()
    println("Hello, $name!")
}

Comments

// This is an end-of-line comment

/* This is a block comment
   on multiple lines. */

Block comments in Kotlin can be nested.

/* The comment starts here
/* contains a nested comment *⁠/
and ends here. */

KDoc

KDoc is the documentation format for Kotlin, similar to Javadoc for Java. KDoc is used to generate documentation for Kotlin classes, functions, and properties. KDoc comments start with the /** and end with */. This is an example:

/**
 * Calculates the sum of two integers.
 *
 * @param a The first integer to add.
 * @param b The second integer to add.
 * @return The sum of the two integers.
 */
fun sum(a: Int, b: Int): Int {
    return a + b
}

Variables

In Kotlin, variables can be declared using either the var or val keyword.

var variables are mutable, meaning their value can be changed after they are initialized.

var x = 5
x = 10

val variables, on the other hand, are immutable, meaning their value cannot be changed after they are initialized.

val y = 5
y = 10 // This will result in a compilation error

Data types

Here’s a brief overview of the most commonly used data types:

    val booleanVar: Boolean = true
    val byteVar: Byte = 127
    val shortVar: Short = 32767
    val intVar: Int = 2147483647
    val longVar: Long = 9223372036854775807L
    val floatVar: Float = 3.14f
    val doubleVar: Double = 3.14159265358979323846
    val charVar: Char = 'A'
    val stringVar: String = "Hello, world!"

Type Inference

Kotlin supports type inference, which means the compiler can infer the type of a variable from its initial value.

val x = 5 // The type of x is inferred to be Int
val y = "hello" // The type of y is inferred to be String

Variables in Kotlin can also be declared without an initial value, but in that case, the type must be explicitly specified:

var z: Double // Valid, z has no initial value
// println(z) // Invalid, z is not initialized and has no value yet
z = 3.14 // Valid, z is initialized with a value

Type Conversion

Kotlin provides several methods for converting between data types. Here’s an example in Kotlin that demonstrates various methods of type conversion.

    val str: String = "123"
    val num: Int = str.toInt() // Convert String to Int

    val dbl: Double = 123.45
    val int: Int = dbl.toInt() // Convert Double to Int

    val lng: Long = 9876543210
    val flt: Float = lng.toFloat() // Convert Long to Float

    val bol: Boolean = true
    val strBol: String = bol.toString() // Convert Boolean to String

    val char: Char = 'A'
    val intChar: Int = char.toInt() // Convert Char to Int // Conversion of Char to Number is deprecated. Use Char.code property instead.

    val byte: Byte = 127
    val short: Short = byte.toShort() // Convert Byte to Short

String templates

val name= "Ali"
val result= "My name is $name"

Character escape

\n insert new line
\t inserts a tab
\r inserts carriage return

Operators

Arithmetic operators

  val a = 10
  val b = 5
  println(a + b) // 15
  println(a - b) // 5
  println(a * b) // 50
  println(a / b) // 2
  println(a % b) // 0

Comparison operators

  val c = 10
  val d = 5
  println(c > d) // true
  println(c >= d) // true
  println(c < d) // false
  println(c <= d) // false
  println(c == d) // false
  println(c != d) // true

Assignment operators

 var h = 10
 h += 5
 println(h) // 15
 h -= 5
 println(h) // 10
 h *= 2
 println(h) // 20
 h /= 4
 println(h) // 5
 h %= 3
 println(h) // 1

Logical operators

  val i = true
  val j = false
  println(i && j) // false
  println(i || j) // true
  println(!i) // false

Bitwise operators

  val k = 0b1010
  val l = 0b1100
  println(k and l) // Prints "8" (0b1000)
  println(k or l) // Prints "14" (0b1110)
  println(k xor l) // Prints "6" (0b0110)

Range operator

  val o = 1..10
  println(o.contains(5)) // Prints "true"
  println(o.contains(11)) // Prints "false"

Control flow

If-else

if (condition) {
    // Code to execute if condition is true
} else {
    // Code to execute if condition is false
}

When

when (value) {
    condition1 -> // Code to execute if value matches condition1
    condition2 -> // Code to execute if value matches condition2
    else -> // Code to execute if value does not match any condition
}

Conditional Expression

Given if and when are expressions, we can directly assign them to variables.

val seasonFirstMonth = when(season) {
    "spring" -> 1
    "summer" -> 2
    "autumn" -> 3
    "winter" -> 4
    else -> error("There is only 4 seasons")
}

Thus, it allows a similar ternary operator using a regular if.

val max = if (a > b) a else b

For loop

for (item in collection) {
    // Code to execute for each item in collection
}

Ranges

There is a set of tools for defining ranges in Kotlin.


for(i in 0..3) {             
    print(i)
}

for(i in 0 until 3) {       
    print(i)
}

for(i in 2..8 step 2) {     
    print(i)
}

for (i in 3 downTo 0) {     
    print(i)
}

Char ranges are also supported.

for (c in 'a'..'d') {   
    print(c)
}

Ranges are also useful in if statements.

if (x in 1..5) {           
    print("x is in range from 1 to 5")
}

While

while (condition) {
    // Code to execute as long as condition is true
}

Do While

do {
    // Code to execute at least once
} while (condition)

Break and Continue

for (i in 1..10) {
    if (i == 5) {
        break // Exit loop when i is equal to 5
    }
    if (i % 2 == 0) {
        continue // Skip even numbers and continue to the next iteration
    }
    // Code to execute for each odd number between 1 and 10
}

Exceptions

To throw an exception object, use the throw expression:

throw Exception("Exception...")

To catch an exception, use the try…catch expression:

try {
    // some code
} catch (e: SomeException) {
    // handler
} finally {
    // optional finally block
}

The Nothing type: This type has no values and is used to mark code locations that can never be reached. In your own code, you can use Nothing to mark a function that never returns.

fun fail(message: String): Nothing {
    throw IllegalArgumentException(message)
}

Functions

Function Declaration

fun sayHello() {
    println("Hello!")
}

fun greet(name: String) {
    println("Hello, $name!")
}

Default arguments and named arguments

fun greet(name: String = "World", greeting: String = "Hello") {
  println("$greeting, $name!")
}

fun main() {
  // calling function with default arguments
  greet() // output: Hello, World!

  // calling function with named arguments
  greet(greeting = "Hi", name = "Ali") // output: Hi, Ali!

  // calling function with some named arguments
  greet(name = "Reza") // output: Hello, Reza!
}

Function Return Types

fun add(a: Int, b: Int): Int {
    return a + b
}

fun multiply(a: Int, b: Int) = a * b

Unit-returning functions If a function does not return a value, its return type is Unit.

fun printHello(): Unit {
  print("Hello")
}

fun printHello() {
   print("Hello")
}

Local functions

Kotlin supports local functions, which are functions inside other functions. printMessage() is a local function defined within the main() function.

fun main() {
    fun printMessage(message: String) {
        println("Message: $message")
    }

    printMessage("Hello, world!")
}

Member functions

A member function is a function that is defined inside a class or object.

class Sample {
    fun foo() {//...}
}

Generic functions

Functions can have generic parameters, which are specified using angle brackets before the function name

fun <T> function(item: T){ 
 //Code
}

Lambda Expressions

val sum = { a: Int, b: Int -> a + b }

val square: (Int) -> Int = { it * it }

Extension Functions and Properties

Extension Functions and Properties in Kotlin allow adding new functionality or properties to existing classes without modifying their source code.

// Extension function
fun String.reverse(): String {
    return this.reversed()
}

// Extension property
val String.firstChar: Char
    get() = this[0]

fun main() {
    val str = "Ali"
    println(str.reverse())  // Prints "ilA"
    println(str.firstChar)  // Prints "A"
}

Higher-Order Functions

A higher-order function is a function that takes another function as parameter and/or returns a function.

Taking Functions as Parameters

fun calculate(x: Int, y: Int, operation: (Int, Int) -> Int): Int { 
    return operation(x, y)                                         
}

fun sum(x: Int, y: Int) = x + y

fun main() {
    val sumResult = calculate(1, 7, ::sum)                         
    val mulResult = calculate(1, 7) { a, b -> a * b }             
}

Returning Functions

fun operation(): (Int) -> Int {                                     
    return ::square
}

fun square(x: Int) = x * x

fun main() {
    val func = operation()                                          
    println(func(7))                                                
}

Operator overloading

Operator overloading in Kotlin allows you to define and use custom operators for your own classes and types.

data class Point(val x: Int, val y: Int) {
    operator fun plus(other: Point): Point {
        return Point(x + other.x, y + other.y)
    }
}

fun main() {
    val p1 = Point(1, 2)
    val p2 = Point(3, 4)
    val p3 = p1 + p2 // using the overloaded '+' operator
    println(p3) // Output: Point(x=4, y=6)
}

Variable number of arguments (varargs)

Varargs is a feature that allows you to pass a variable number of arguments of the same type to a function

fun printNumbers(vararg numbers: Int) {
    for (number in numbers) {
        println(number)
    }
}

fun main() {
    printNumbers(1, 2, 3) // prints 1, 2, 3
    printNumbers(4, 5, 6, 7, 8) // prints 4, 5, 6, 7, 8
}

Infix notation

Infix in Kotlin allows you to define functions that can be called using infix notation (i.e., without using parentheses and the dot notation).

infix fun Int.times(str: String) = str.repeat(this)

fun main() {
    val str = 5 times "Hello "
    println(str) // Output: "Hello Hello Hello Hello Hello "
}

Scope Functions

let can be used for scoping and null-checks. When called on an object, let executes the given block of code and returns the result of its last expression. The object is accessible inside the block by the reference it (by default) or a custom name.

val message: String? = "Hello"
message?.let {
    print(it.toUpperCase()) // Output: "HELLO"
}

Like let, run is another scoping function from the standard library. Basically, it does the same: executes a code block and returns its result. The difference is that inside run the object is accessed by this. This is useful when you want to call the object’s methods rather than pass it as an argument.

val message: String? = "Hello"
message?.run {
    print(this.toUpperCase()) // Output: "HELLO"
}

with

with is a non-extension function that can access members of its argument concisely: you can omit the instance name when referring to its members.

val person = Person("Ali", 24)
val message = with(person) {
    "My name is $name and I'm $age years old."
}

apply

apply executes a block of code on an object and returns the object itself. Inside the block, the object is referenced by this. This function is handy for initializing objects.

val person = Person("Ali", 24)
person.apply {
    name = "Ali"
    age = 24
}

also

also works like apply: it executes a given block and returns the object called. Inside the block, the object is referenced by it, so it’s easier to pass it as an argument. This function is handy for embedding additional actions, such as logging in call chains.

val message: String? = "Hello"
message?.also {
    print(it.toUpperCase()) // Output: "HELLO"
}

Collections

Array

An array is a fixed-size collection of elements of the same data type.

Declaring and Initializing Arrays


// Declare an array of integers
val numbers = arrayOf(1, 2, 3, 4, 5)

// Declare an array of strings
val names = arrayOf("Alice", "Bob", "Charlie", "Dave")

// Declare an array of a specific size
val array = arrayOfNulls<Int>(10)

// Declare an array of integers with a specified size and initial value
val array = Array<Int>(7) { i -> i*i }
val filledArray = IntArray(5) { index -> index * 2 } // Other type: BooleanArray, ShortArray, DoubleArray and etc.

Accessing Array Elements

// Access an element at a specific index
val firstNumber = numbers[0]

// Access the last element of an array
val lastNumber = numbers[numbers.size - 1]

Modifying Array Elements

// Modify an element at a specific index
numbers[0] = 10

// Fill an array with a specific value
Arrays.fill(numbers, 0)

Iterating over Arrays


// Iterate over an array using a for loop
for (number in numbers) {
    println(number)
}

// Iterate over an array using a for loop with an index
for (i in names.indices) {
    println("${i}: ${names[i]}")
}

// Iterate over an array using a forEach loop
names.forEach { name ->
    println(name)
}

Basic methods

val index = numbers.indexOf(3)

numbers.sort()

names.reverse()

List

A collection of elements in a specified order
Can have duplicates
Immutable: listOf(), or mutable: mutableListOf()
List: This is the basic interface for a read-only list of elements.
MutableList: This is a subinterface of List that allows for mutable operations such as adding or removing elements.
ArrayList: This is an implementation of MutableList that uses an array to store elements.
LinkedList: This is an implementation of MutableList that uses a linked list to store elements.

val list = listOf(1, 2, 3, 4, 5)
val list2=mutableListOf(1, 2, 3, 4, 5)

Basic methods:

    val numbers = mutableListOf(1, 2, 3)
    numbers.add(4) // Adds the specified element to the end of the list
    numbers.remove(3) // Removes the first occurrence of the specified element from the list
    numbers[1] // Returns the element at the specified index in the list

Map

A collection of key-value pairs
Keys must be unique
Immutable: mapOf(), or mutable: mutableMapOf()
Map: This is the basic interface for a read-only map of key-value pairs.
MutableMap: This is a subinterface of Map that allows for mutable operations such as adding or removing key-value pairs.
HashMap: This is an implementation of MutableMap that uses a hash table to store key-value pairs.
LinkedHashMap: This is an implementation of MutableMap that maintains the insertion order of key-value pairs.
SortedMap: This is an interface for a map that maintains its key-value pairs in sorted order.
TreeMap: This is an implementation of SortedMap.

val map = mapOf(1 to "one", 2 to "two", 3 to "three")
val map2= mutableListOf(1 to "one", 2 to "two", 3 to "three")

Basic methods:

    val numbers =  mutableMapOf("one" to 1, "two" to 2, "three" to 3)
    numbers.put("four", 4) // Associates the specified value with the specified key in the map
    numbers.remove("two") // Removes the mapping for the specified key from the map if it is present
    numbers.containsKey("two") // Returns true if the map contains the specified key

Set

A collection of elements with no duplicates
Elements are not in a specific order
Immutable: setOf(), or mutable: mutableSetOf
Set: This is the basic interface for a read-only set of elements.
MutableSet: This is a subinterface of Set that allows for mutable operations such as adding or removing elements.
HashSet: This is an implementation of MutableSet that uses a hash table to store elements.
LinkedHashSet: This is an implementation of MutableSet that maintains the insertion order of elements.
SortedSet: This is an interface for a set that maintains its elements in sorted order.
TreeSet: This is an implementation of SortedSet.

val set = setOf(1, 2, 3, 4, 5)
val set2=mutableSetOf(1, 2, 3, 4, 5)

Basic methods:

    val numbers =  mutableSetOf(1, 2, 3)
    numbers.add(4) // Adds the specified element to the set if it is not already present
    numbers.remove(3) // Removes the specified element from the set if it is present
    numbers.contains(1) //  Returns true if the set contains the specified element

Please for more collections and detaile read doc.

Class and Object

Classes

A class is a blueprint for creating objects.
An object is an instance of a class.

class Person(val name: String, var age: Int) // class

val person = Person("Ali", 24) // object

Property and methods

Properties are variables that are part of a class/object.
Methods are functions that are part of a class/object.

class Person(val name: String) {
   var age = 0 // property

   fun sayHello() { // method
      println("Hello, my name is $name")
   }
}

val person = Person("Ali")
person.age = 24
person.sayHello()

Getters and setters

Getter and setter in Kotlin are accessors used to retrieve and modify the value of a variable, respectively. The initializer, getter, and setter are optional.

class Person {
    var name: String = ""
        get() = field.uppercase(Locale.getDefault())
        set(value) {
            field = "Name: $value"
        }

    var age = 24 // has default getter and setter

    val username="Ali" // has default getter

}

For more details about properties, getter/setter, backing fields, backing properties and etc read this link.

Visibility modifiers

private: restricts visibility to the same class.
protected: restricts visibility to the same class and its subclasses.
internal: restricts visibility to the same module.
public: allows visibility from anywhere.

Late-initialized properties and variables

A lateinit variable is used when you know that a variable will be initialized before it is used, but you don’t want to assign an initial value at the time of declaration.

lateinit var myLateInitVar: String

// The variable is not initialized yet, so trying to access it will throw an exception
// println(myLateInitVar) // This line would throw a "lateinit property has not been initialized" exception

// Sometime later, the variable is initialized
myLateInitVar = "Hello World"

// Now we can access the variable without an exception
println(myLateInitVar) // Prints "Hello World"

Inheritance

Inheritance is the process by which one class acquires the properties and methods of another class.

open class Animal(val name: String) {
   open fun makeSound() {
      println("Animal sound")
   }
}

class Dog(name: String): Animal(name) {
   override fun makeSound() {
      println("Woof!")
   }
}

Interface and Abstract Class

Both interface and abstract class provide a way to define contracts or blueprints for classes to follow. They are used for abstraction.

interface Vehicle {
    fun start()
    fun stop()
    val name: String
}

abstract class Animal {
    abstract fun makeSound()
    open fun move() {
        println("Moving...")
    }
}

Abstraction

Abstraction is a mechanism for hiding the implementation details of an object and exposing only the necessary details to the user. In Kotlin, abstraction is achieved through interfaces and abstract classes.

Polymorphism

Polymorphism is the ability of an object to take many forms.

class Dog : Animal() {
    override fun makeSound() {
        println("Woof!")
    }
}

class Cat : Animal() {
    override fun makeSound() {
        println("Meow!")
    }
}

In this example, both Dog and Cat classes inherit from the Animal abstract class and provide their own implementation of the makeSound() method, which demonstrates polymorphism.

Object Expression and Declaration

An object expression creates an instance of an anonymous class, while an object declaration creates a singleton instance of a class.

val person = object {
    val name = "Ali"
    fun sayHello() {
        println("Hello, my name is $name")
    }
}

object Singleton {
    fun doSomething() {
        println("Doing something...")
    }
}

Companion objects An object declaration inside a class can be marked with the companion keyword.

class MyClass {
    companion object { }
}

Data class

A data class is a special class that is designed to hold data.

data class Person(val name: String, var age: Int)

val person = Person("Ali", 24)

Nested and Inner class

A nested class is a class that is defined inside another class.
An inner class is a nested class that has access to the members of the outer class.

class Outer {
   private val outerProperty = "Outer property"

   class Nested {
      fun foo() {
         // can't access outerProperty
      }
   }

   inner class Inner {
      fun bar() {
         println(outerProperty) // can access outerProperty
      }
   }
}

Type aliases

Type aliases provide alternative names for existing types. If the type name is too long you can introduce a different shorter name and use the new one instead.

Before using a type alias

val numbers = listOf(1, 2, 3, 4, 5)
numbers.filter { number: Int -> number % 2 == 0 }.map { number: Int -> "Number is $number" }

After using a type alias

typealias NumberPredicate = (Int) -> Boolean
typealias NumberMapper = (Int) -> String

val numbers = listOf(1, 2, 3, 4, 5)
val even: NumberPredicate = { number -> number % 2 == 0 }
val mapper: NumberMapper = { number -> "Number is $number" }
numbers.filter(even).map(mapper)

Enum

An enum is a type that represents a fixed set of values.

enum class Color {
   RED, GREEN, BLUE
}

Sealed class and interface

A sealed class/interface restricts the inheritance of its subclasses/interfaces to only within the same file.

sealed class Shape

class Circle: Shape()

// Can't subclass Shape outside of this file

Generics

A generic concept in Kotlin allows for type-safe programming by creating reusable classes, functions, and interfaces that can work with any data type.

class Box<T>(t: T) {
    var value = t
}

Delegation Pattern

Kotlin supports easy implementation of the delegation pattern on the native level without any boilerplate code.

interface Base {
    fun print()
}

class BaseImpl(val x: Int) : Base {
    override fun print() { print(x) }
}

class Derived(b: Base) : Base by b

fun main() {
    val b = BaseImpl(10)
    Derived(b).print()
}

Delegated properties

Delegated properties in Kotlin allow the definition of custom getters and setters for a property that can be delegated to another object, such as the lazy initialization of a property.

A lazy variable is initialized only when it is first accessed.

val myLazyVar: String by lazy {
    // Perform some expensive operation to initialize the variable
    "Hello World"
}
// The variable is not initialized until it is first accessed
println(myLazyVar) // Prints "Hello World"

The Signal and the Noise (Nate Silver)

The Signal and the Noise — Nate Silver

1. Executive Summary

This is a book about why predictions fail and how to make them fail less often. Silver’s core claim: more data does not automatically mean better forecasts. As information grows exponentially, noise grows faster than signal, and we increasingly mistake one for the other. The book surveys fields where prediction has succeeded (weather, baseball) and failed (finance, earthquakes, economics, politics, terrorism), looking for what separates good forecasters from bad ones. The answer converges on Bayesian reasoning: think probabilistically, hold multiple hypotheses at once, state a prior belief honestly, and update it incrementally as evidence arrives, rather than searching for a single deterministic “right answer.” Good forecasters (Silver calls them “foxes”) are humble, adaptive, and comfortable with uncertainty; bad ones (“hedgehogs”) are ideological, overconfident, and cling to one big theory. The recurring villain is overfitting — building models so tightly tailored to past data that they mistake historical noise for a durable pattern, then failing catastrophically out of sample. Technology and computing power help only when paired with strong theory and honest accounting of uncertainty; alone, they just let us find false patterns faster. The book closes on national security and climate, arguing that our worst failures come not from bad data but from failures of imagination — an unwillingness to assign any probability at all to the unfamiliar.

2. Main Points (ranked by importance)

The central thesis: distinguish signal from noise, and know the difference between what you know and what you think you know. Silver argues the “big data” era is dangerous precisely because information is multiplying exponentially while the amount of objective truth is not. Most of the new data is noise, not signal, and the number of hypotheses we can test now vastly outstrips the number that are actually true. This creates more opportunities for false positives, not fewer. The book repeatedly shows forecasters in different fields mistaking a coincidental correlation for a causal relationship. The fix is not less data but more self-awareness about our own biases when interpreting it. Prediction should be treated as a “shared enterprise,” not a specialist function, because everyone makes forecasts constantly, whether or not they realize it. The book’s stated goal is modest: not perfect prediction, but being “less wrong” over time.
Bayesian reasoning is offered as the practical solution. Bayes’s theorem updates a prior belief in light of new evidence to produce a posterior probability, and it requires you to state your starting assumptions explicitly rather than pretend you have none. Silver contrasts this against the “frequentist” statistics developed by R. A. Fisher, which tries to strip out human judgment entirely and treats a hypothesis as either “significant” or not, with no room for context or plausibility. He argues frequentism’s false neutrality lets nonsense correlations (toads predicting earthquakes) compete on equal footing with well-grounded theories (smoking causing cancer), and that Fisher himself, a paid tobacco consultant, used this weakness to deny the cancer link for decades. Under Bayesian logic, confident but wrong predictions do far more damage to a theory’s credibility than cautious, hedged ones. Beliefs converge toward truth as evidence accumulates, provided everyone is reasoning probabilistically rather than dogmatically. Silver predicts, only half-jokingly, that statistics as a discipline is gradually shifting Bayesian.
The 2008 financial crisis is presented as history’s most complete failure of prediction. Credit-rating agencies rated mortgage-backed securities as almost risk-free, when the actual default rate for “safe” AAA-rated CDOs was 200 times higher than predicted. The core error was conflating risk (quantifiable) with uncertainty (not readily quantifiable), and assuming individual mortgage defaults were statistically independent of one another when a housing bubble made them highly correlated. This was compounded by extreme leverage — roughly $50 in side bets for every $1 of actual home value — so a modest error in assumptions produced a systemic collapse. The ratings agencies’ claim that “nobody saw it coming” was false; many economists flagged the bubble years in advance, but their warnings were an inconvenient signal ignored amid the reassuring noise. The deeper lesson is about “out of sample” thinking: models built only on decades of rising home prices had no way to anticipate a nationwide decline, because that scenario had simply never appeared in the training data. Precision was mistaken for accuracy throughout — decimal-point default probabilities gave false confidence despite being disconnected from reality.
Political pundits are worse forecasters than they appear, and Philip Tetlock’s “hedgehogs vs. foxes” framework explains why. Silver’s own analysis found television pundits’ predictions were right about as often as a coin flip. Tetlock’s decades-long study of expert political forecasts found the same: experts did barely better than chance, and were often worse than simple statistical models, especially the ones most frequently quoted in media. “Hedgehogs,” who filter all evidence through one grand ideology, make bold, memorable, and usually wrong predictions; “foxes,” who are eclectic, self-critical, and comfortable with uncertainty, quietly outperform them. Counterintuitively, hedgehogs get worse with more credentials and information, because extra facts just give them more material to rationalize existing biases. Silver’s own FiveThirtyEight model succeeded by adopting fox-like principles: thinking probabilistically, updating forecasts daily as new data arrived rather than defending old predictions out of pride, and weighting the “wisdom of crowds” over any single data point.
Overfitting — mistaking noise for signal — is the single most important recurring statistical error in the book, illustrated through earthquake prediction’s near-total failure. Every major attempt at earthquake prediction (Lima, Parkfield, the Mojave Desert, Keilis-Borok’s Russian models) has failed, often after receiving serious government and media attention. Overfit models chase every wiggle in noisy historical data, producing high explanatory power on paper but poor real-world accuracy, exactly the opposite of what’s useful. The one durable finding is the Gutenberg-Richter law: a power-law relationship where each one-point increase in magnitude makes an earthquake roughly ten times rarer, which lets us forecast long-run frequencies without ever predicting a specific date. Japan’s 2011 Fukushima disaster partly resulted from an “overfit” assumption that the regional seafloor made magnitude-9 earthquakes essentially impossible, based on too little historical data. Silver’s broader warning: when data is noisy and theory is weak, added model complexity almost always makes forecasts worse, not better.
Weather forecasting is the book’s clearest success story, showing what real predictive progress looks like. Hurricane-track forecasts are roughly three times more accurate than they were 25 years ago, thanks to a genuine partnership between supercomputer simulation and human visual judgment; forecasters still add 25% accuracy on top of computer models alone. Chaos theory (the “butterfly effect”) means small errors in initial measurements compound exponentially, so weather is fundamentally probabilistic beyond about a week, no matter how powerful the computer. Crucially, the National Weather Service is well-calibrated — when it says 40% chance of rain, it rains about 40% of the time — while commercial forecasters introduce a deliberate “wet bias” because the public punishes missed rain more than false alarms. Hurricane Katrina shows the limits of even a good forecast: the Hurricane Center predicted the strike days in advance, but political and communication failures in issuing a mandatory evacuation order cost lives regardless. The chapter’s moral: honest, well-calibrated uncertainty communicated clearly saves lives; false confidence or “security theater” precision does not.
Baseball demonstrates that combining statistics with human judgment beats either one alone. Silver’s own PECOTA system used a “nearest neighbor” approach, comparing a young player statistically to historical comparables, to project performance, but professional scout rankings still beat pure statistical projections by about 15% in results. The stathead-versus-scout rivalry chronicled in Moneyball has since resolved into a hybrid approach, as scouts provide information statistics can’t capture (makeup, work ethic, plate discipline in person) while statistics correct for scouts’ biases (undervaluing short or “unconventional-looking” players like Dustin Pedroia). Aging curves are real on average but highly individual, and models that force players into rigid categories (Huckabay’s 26 aging types) do no better than simple ones. Baseball is unusually forecastable because it has enormous clean data and simple, non-nonlinear causality compared to team sports like football; that advantage shrinks the further you get from the majors, since college and high school stats have little predictive power.
Economic forecasting is shown to be persistently overconfident and largely unreliable more than a few months out. GDP forecasts fall outside their own stated 90% confidence intervals roughly a third of the time, meaning economists are far more certain than their track record justifies; you’d have to widen their real margin of error to roughly ±3.2% GDP to make the claim honest. Economists almost never publish that uncertainty, partly, in Silver’s view, out of embarrassment. A key structural problem is that the economy is a dynamic, ever-changing system (Goodhart’s Law: once you target a variable, it stops behaving reliably), so historical relationships like Okun’s Law between GDP and job growth can quietly break down. Data itself is unreliable in the short run — GDP estimates are frequently revised by several percentage points months or years later. Aggregating many forecasters’ predictions modestly improves accuracy over any single expert, but this is a low bar; the aggregate is still bad in any absolute sense.
Disease forecasting (the 1976 and 2009 swine flu scares) shows the danger of naive extrapolation and the strange self-referential nature of prediction about human behavior. Simple extrapolation of early, small-sample outbreak data (as with early AIDS case counts or 1970s population projections) reliably fails because real-world processes are not exponential forever. Disease forecasts can be self-fulfilling (a scary poll changes voter or investor behavior) or self-canceling (an effective flu warning causes people to get vaccinated, making the warning look “wrong” in hindsight). Simple compartmental models (SIR) assume random mixing between all people in a population, an assumption that breaks down badly for diseases spread through specific subgroups or neighborhoods, as Chicago’s 1980s measles outbreaks and the HIV/syphilis paradox in San Francisco showed. Newer “agent-based” models that simulate whole cities individual-by-individual are promising but data-starved and largely useful only for generating insight, not firm predictions. Epidemiologists, bound by “first, do no harm,” are commendably honest about the limits of their models compared to forecasters in other fields.
Chess and Deep Blue illustrate the real division of labor between computers and humans. Computers excel at fast, error-free, emotionless calculation across a huge number of possibilities; humans excel at abstraction, creativity, and recognizing when a rule of thumb (heuristic) should be broken. Kasparov’s 1997 loss to Deep Blue partly turned on his own psychological reaction to what was, in fact, a program bug that made a nonsensical move — he assumed it reflected superhuman insight rather than randomness, a case of over-crediting a machine’s “intelligence.” Google’s search algorithm operates on a similar logic of massive trial-and-error experimentation (roughly 10,000 tests a year) rather than any single grand theory, refining itself continuously rather than claiming to be finished. The broader lesson: technology reliably helps forecasting in fields with well-understood physical laws (chess, weather) but has not meaningfully improved forecasting in fields with weak theory and noisy data (economics, earthquakes), no matter how much faster computers get.
Poker is presented as one of the purest real-world applications of Bayesian hand-reading and probabilistic thinking. Skilled players continuously update a probability distribution over an opponent’s possible hands based on betting patterns, rather than trying to guess the exact two cards. Because poker mixes substantial skill with substantial luck, even a genuinely winning player can lose money over tens of thousands of hands purely from variance, making it very hard for players to know their true skill level. Most players are “delusional” about their own edge, and a psychological state called “tilt” — playing worse after a perceived injustice — erodes even skilled players’ edge. The chapter’s larger point is about “results-oriented thinking”: society tends to judge decisions by outcomes rather than by the soundness of the decision process, when in a noisy world the two frequently diverge; better judgment comes from evaluating process, not just results.
Efficient-market hypothesis is neither fully true nor fully false, and financial bubbles are a real, structural feature of markets rather than a myth. Eugene Fama’s research found that past mutual-fund performance doesn’t predict future performance, and that consistently “beating the market” is extremely rare. But the “price is always right” component of the theory is contradicted by clear cases (like Palm/3Com’s mispriced spinoff) where two claims on the same asset traded at wildly different prices simultaneously. Bubbles form because traders respond rationally to short-term career incentives (a 90-day performance window) even when they privately suspect a stock is overvalued, producing herding rather than correction. Shorting an overvalued asset is far riskier and more expensive than going long one, which is why bubbles are much easier to detect in real time than to profitably pop; “the market can stay irrational longer than you can stay solvent.” Robert Shiller’s P/E-ratio-based method has meaningfully predicted long-run (10–20 year) stock returns, even though it says almost nothing about short-term timing.
Climate science gets a “healthy skepticism” treatment: the greenhouse mechanism is solid, but climate models carry real uncertainty that both sides of the debate misrepresent. The IPCC’s 1990 temperature forecast overshot actual 1990–2011 warming (predicting roughly 3°C/century versus an actual ~1.5°C/century), partly because it assumed no action would be taken to curb emissions, and it was later revised down. A simple, low-tech linear regression using only CO2 and past temperatures actually predicted the real trend more accurately than the complex IPCC models did, which supports critics who warn against needless model complexity — but the same simple model still confirms the greenhouse-effect hypothesis, undercutting those who use it to dismiss warming altogether. Climate forecasting is hardest to test empirically because feedback (unlike daily weather) arrives only over decades, and short “flat” decades (like 2001–2011) are statistically unsurprising noise, not evidence against the underlying trend, a point often misused by both skeptics and activists. Silver’s sharpest point: science, ideally, converges toward truth through Bayesian updating, while politics increasingly does not, and climate science has been damaged by scientists and activists crossing from one arena into the other.
Terrorism prediction hinges on “unknown unknowns” and the danger of mistaking the unfamiliar for the impossible. Both Pearl Harbor and 9/11 had abundant warning signals in hindsight, but institutions had built mental models (fear of sabotage, assumption hijackers wanted a standoff not a suicide mission) that made the actual attack literally unthinkable rather than merely improbable. Rumsfeld’s “unknown unknown” concept describes contingencies never even considered, as opposed to “known unknowns,” which at least get a probability estimate. Aaron Clauset’s research shows terror attack severities follow the same power-law distribution as earthquakes, meaning 9/11-scale attacks were not true statistical outliers but a predictable (if infrequent) part of the same pattern as smaller attacks like Oklahoma City or Lockerbie. Analysts disagree sharply on the odds of a future nuclear terror attack (Graham Allison sees “more likely than not”; Michael Levi far more skeptical, citing operational failure rates for terror groups). Israel’s experience shows the risk of terrorism can be somewhat “bent” by policy choices (rapid normalization after small attacks, hard limits on large-scale ones), meaning it isn’t a purely random natural process like an earthquake.
“Foxes” (adaptive, humble, probabilistic thinkers) systematically outperform “hedgehogs” (rigid, ideological, overconfident ones) across nearly every field studied. This isn’t confined to punditry — it recurs in the ratings agencies, in economic forecasters, and in overconfident traders. The trait most correlated with good forecasting is not intelligence or credentials but a willingness to change one’s mind quickly and completely when new evidence demands it, without treating that change as embarrassing. Silver frames this as the book’s practical takeaway for readers who aren’t professional forecasters at all: check whether your predictions actually improve when you get more information, because if they don’t, you may be a hedgehog without realizing it.
The book repeatedly distinguishes “risk” (quantifiable, insurable) from “uncertainty” (not reliably quantifiable), a distinction from economist Frank Knight that recurs across finance, terrorism, and pandemics. Treating true uncertainty as if it were measurable risk — as the ratings agencies did with novel mortgage securities — is identified as one of the most dangerous and common errors forecasters make. Genuine humility requires admitting when a problem is closer to the uncertainty end of that spectrum, even though that’s professionally and psychologically uncomfortable.
Aggregating independent forecasts (“wisdom of crowds”) reliably beats relying on any single forecaster, across fields from economics to sports betting to elections. This gain is typically modest (about 15–20%) but consistent, and it holds even against the very best individual forecaster over a long enough time horizon. The caveat: this only works when forecasts are made independently before being combined; once forecasters start reacting to each other’s public predictions (as in a betting market), herding can undermine the benefit.
Big Data optimism — the idea that enough data eventually makes theory unnecessary — is directly rejected as naïve and dangerous. Silver singles out the “end of theory” claim (that sheer data volume obviates the scientific method) as exactly backward: without a plausible causal theory to constrain which correlations we take seriously, exponentially more data just produces exponentially more false positives, as shown by Ioannidis’s finding that most published research findings don’t replicate.
Good forecasting requires a genuine, personal commitment to accuracy over self-interest, status, or ideology, and the book treats this almost as a moral stance rather than just a technical one. Silver repeatedly praises forecasters (Jan Hatzius, Nate Silver’s own election model, the National Weather Service, epidemiologists bound by “do no harm”) who prioritize being right over sounding confident, and criticizes those (ratings agencies, cable pundits, some climate advocates) who let incentives distort their forecasts. This is presented as the throughline connecting every chapter: honesty about uncertainty is not a weakness in a forecast, it’s the whole point of one.

3. Critique — Points Readers Might Push Back On

The Bayesian framing can feel like a hammer looking for nails. Silver treats Bayesian reasoning as close to a universal fix, but critics of Bayesian statistics note that subjective priors can just as easily encode bias as remove it — “garbage prior in, garbage posterior out.” The book acknowledges this in passing but doesn’t fully wrestle with cases where reasonable people would pick very different, equally defensible priors.
The weather-vs-economics contrast may be less about attitude and more about structure. Silver frames meteorologists as simply more honest and disciplined than economists, but economics faces a fundamentally harder problem: human behavior changes in response to predictions and policy (the Lucas critique, Goodhart’s Law) in a way weather never does. Some readers will feel the book underweights this structural difference in favor of a narrative about professional culture and incentives.
The climate chapter’s “healthy skepticism” has aged awkwardly in places. Writing in 2012, Silver treats the 2001–2011 warming “hiatus” as a serious data point worth extensive Bayesian analysis; global temperatures rose sharply in the years immediately after publication, which is a reminder that drawing strong lessons from a short, cherry-pickable window is exactly the mistake the book warns against — arguably including its own analysis.
The efficient-market-hypothesis chapter tries to have it both ways. It endorses Fama’s “no free lunch” (you can’t reliably beat the market) while rejecting his “price is always right,” landing on “bubbles are real but almost impossible to profit from popping.” Hardline EMH defenders would say this waters the theory down until it’s nearly unfalsifiable; hardline behavioral economists would say Silver is still too deferential to market rationality.
Tetlock’s fox/hedgehog framework, while compelling, is partly self-validating by design. Foxes are defined by hedging and expressing uncertainty; it’s almost tautological that vaguer, hedged predictions will be graded as “less wrong” than bold, falsifiable ones. Some readers may find the dichotomy less a discovery about forecasting skill and more a restatement of “confident predictions are risky, cautious ones are safe.”
The terrorism chapter’s power-law framing, while mathematically elegant, reduces mass-casualty violence to a statistical curve. Some readers will find this actuarial treatment of Pearl Harbor, 9/11, and hypothetical future attacks intellectually useful but uncomfortably clinical given the human stakes involved.
Silver’s own track record is used throughout as a credibility anchor (FiveThirtyEight’s 2008/2010/2012 election calls, PECOTA), which risks survivorship bias — a book by someone whose big public predictions had gone badly would read very differently, and the framework doesn’t fully grapple with how much of his own success involved luck versus process, the very distinction the book insists readers apply to everyone else.

4. Representative Quotes

“The signal is the truth. The noise is what distracts us from the truth. This is a book about the signal and the noise.”
“Precise forecasts masquerade as accurate ones, and some of us get fooled and double-down our bets.”
“Foxes, Tetlock found, are considerably better at forecasting than hedgehogs… the fox knows many little things, but the hedgehog knows one big thing.”
“You know what? I’m a guy who doesn’t care about numbers and stats. All I care about is W’s and L’s. I care about wins and losses.”
“When catastrophe strikes, we look for a signal in the noise—anything that might explain the chaos that we see all around us and bring order to the world again.”
“Nobody has a clue. It’s hugely difficult to forecast the business cycle. Understanding an organism as complex as the economy is very hard.”
“We can never achieve perfect objectivity, rationality, or accuracy in our beliefs. Instead, we can strive to be less subjective, less irrational, and less wrong.”
“There is no other game that I know of where humans are so smug, and think that they just play like wizards, and then play so badly.”
“As John Maynard Keynes said, ‘The market can stay irrational longer than you can stay solvent.’”
“When we are making predictions, we need a balance between curiosity and skepticism… By knowing more about what we don’t know, we may get a few more predictions right.”

The Staff Engineer's Path

The Staff Engineer’s Path — Tanya Reilly (Structured Summary)

Three pillars of the staff+ role, used as the book’s structure: big-picture thinking, execution, leveling up others.

Introduction: Two Paths / The Pillars of Staff Engineering

Two career tracks: management and “technical”/IC track. Staff+ = the technical-leadership levels above senior.
“Staff+” (Will Larson’s term) covers staff, senior staff, principal, distinguished, etc. Senior is the “anchor”/tenure level; staff+ is a further, different kind of growth (impact/scope), not “more senior senior.”

PART I — THE BIG PICTURE

Chapter 1: What Would You Say You Do Here?

What is a staff engineer

Titles matter even in “flat” cultures: they vest authority, signal competency, and counter implicit bias (e.g., women/POC assumed more junior). Title also anchors your next job offer.
Senior = “tenure” level (can stay there whole career). Staff+ = “technical leadership” levels, roughly equivalent in seniority to manager/director counterparts.

Why organizations need staff+ engineers

Big-picture thinking: avoids “local maximum” decisions (best for one team, worse for the org). Needs someone with time/context to see across teams; can’t just be the manager or CTO because management is already a full-time job and management authority can overshadow technical judgment.
Cross-team project leadership: real projects don’t map cleanly onto team boundaries (unlike the idealized “Inverse Conway Maneuver”); someone needs to own the whole outcome, maintain engineering standards, and unblock things that fall in the cracks. Different from a TPM: TPMs own delivery, staff engineers own design/quality.
Good influence: software has real consequences (safety, business); junior engineers learn norms from the most respected engineers, not policy documents; someone must model high standards. This leadership work must be a formal part of the job, not an add-on to full-time coding.

Axioms of the role

You’re not a manager, but you are a leader — leadership without direct reports, exercised via design review, technical direction, teaching, reputation. Introverts can lead; jerks cannot.
You’re in a “technical” role — needs real technical judgment and credibility, but doesn’t necessarily mean heavy day-to-day coding.
You aim to be autonomous — you help create your own high-impact backlog; you own your time; autonomy requires speaking up if asked to do something harmful.
You set technical direction — ensuring decisions get made, made well, and documented (not necessarily made by you personally).
You communicate often and well — most of the job is transferring understanding between brains.

Understanding your role’s shape

Reporting chain: reporting “high” (director/VP) = broad perspective, less 1:1 attention, learn from watching senior leaders; reporting “low” (line manager) = more focused attention/advocacy, but less influence/context, possible experience mismatch with manager. Use skip-levels to compensate either way.
Scope: too broad → lack of impact/no narrative, becoming a bottleneck, decision fatigue, missing relationships/mentorship gaps. Too narrow → wasted expertise, opportunity cost, overshadowing juniors, overengineering out of boredom.
Shape of the role:
- Depth-first vs. breadth-first work style.
- Yonatan Zunger’s “four disciplines”: core technical skills, product management, project management, people management — every project needs all four; know which you enjoy/avoid.
- “Hyperspecialist”/“true IC” path — rare, still needs communication skills, influence wanes without it.
- How much you want/need to code.
- Tolerance for delayed gratification (long strategy/culture work has slow feedback vs. coding’s fast feedback).
- Tech lead manager (TLM) hybrid role — difficult, or “pendulum” between IC and management over time.
- Will Larson’s “Staff Archetypes”: Tech Lead (partners with managers on execution), Architect (technical direction/quality for an area), Solver (deep dives on one hard problem at a time), Right Hand (extra leadership bandwidth for an org).
Primary focus: choose work that is genuinely important (“what’s important?”) and that actually needs a senior person (“what needs you?”) — avoid duplicating work junior/mid engineers could do; avoid crowding out others.

Aligning on scope/shape/focus

Write out your own understanding of your role/goals and share it with your manager to surface mismatched expectations early — better before performance-review time than during it.
Ultimately “your job” = whatever makes the organization successful, even work with no title match (glue work, physical emergencies, whatever’s needed).

Chapter 2: Three Maps

Three complementary mental maps, all initially obscured (“fog of war”) and uncovered through deliberate attention:

1. Locator Map — “You are here” (perspective)

Purpose: see your place/scope relative to the wider organization; counteract the natural bias to overweight your local group’s concerns.
Risks of losing perspective: prioritizing badly (local maximum feels important), losing empathy for other teams’ work, tuning out background problems (“boiling frog”), forgetting the ultimate purpose of the work (and its ethics).
Techniques for seeing bigger:
- Take an outsider’s view — deliberately look at your own team as a stranger would; “respect what came before” (Amazon principal tenet) — humility, not license to be dismissive.
- Escape the echo chamber — build relationships with staff+ peers in other groups/orgs and beyond engineering (product, support, admin); treat other staff engineers as your “virtual team.”
- Know what’s actually important — company priorities shift over time; know the implicit “objectives that are always true” (survive, pay people, maintain reputation) alongside stated goals.
- Know what customers care about — measure success from the user’s point of view, not just internal SLOs (“nines don’t matter when users aren’t happy”).
- Check whether the problem’s been solved before — look for prior art inside and outside the org before inventing something new.
- Maintain industry-wide perspective via conferences, newsletters, communities.

2. Topographical Map — navigating the terrain

Purpose: understand organizational culture and structure well enough to move efficiently through it.
Symptoms of not having this map: good ideas don’t get traction, hidden showstoppers appear late, everything takes longer than expected.
Culture dimensions (sliders, not right/wrong): secret vs. open information flow; oral vs. written decision culture; top-down vs. bottom-up initiative; fast vs. deliberate change; back-channel vs. front-door communication; allocated (busy) vs. available (slack) teams; liquid vs. crystallized hierarchy/promotion structure.
Westrum typology of organizational cultures: Pathological (power-oriented, low cooperation), Bureaucratic (rule-oriented, modest cooperation), Generative (mission-oriented, high cooperation/information flow) — generative correlates with better delivery performance (DORA research).
Points of interest/hazards: chasms (gaps between team cultures, e.g., infra vs. product), fortresses (well-intentioned gatekeepers protecting quality — need sponsorship/tokens to pass), disputed territory (unclear ownership causing power struggles), uncrossable deserts (historically unwinnable fights), paved roads/shortcuts/long ways around (official vs. actually-used paths).
Decision-making: find “the room where it happens” (formal venue for decisions in your scope); to join, argue org-level impact (not personal career benefit) and reduce the cost of your presence; accept some rooms aren’t for you (comp/perf decisions if you’re IC-track).
The “shadow org chart” (Fitzpatrick & Collins-Sussman) — informal influence network of “connectors” and “old-timers,” distinct from the formal chart; identify who the real influencers are before pushing for change.
Keep the map fresh via: announcement channels, “walking the floor”/gemba, lurking (skimming calendars, channel lists, agendas), reading design docs, checking in with leadership, informal conversations across functions (support, admin, etc.).
If terrain is genuinely broken: be a bridge — connect groups with information gaps, make informal introductions, summarize cross-team status nobody else is sending.

3. Treasure Map — the destination

Purpose: know where you’re collectively going and why, not just the next milestone.
Costs of only thinking short-term: hard to keep everyone aligned, big multi-step problems never get finished, accumulate cruft (over- or under-engineering to hedge), competing grassroots initiatives, engineers stop building ownership/growth muscles.
Use a “technology tree” mental model (Civilization-style): current work is often an intermediate step toward a bigger real goal — keep tracing “why” until you reach the actual objective.
Sharing the map: story should be comprehensible, relatable (show how it benefits them, not just you), and comfortable (within the org’s current Overton window); tell where you came from as well as where you’re going.
If no shared treasure map exists (multiple/no destinations), that’s a trigger for the next chapter: creating one.

Your personal journey — foreshadows Chapter 9’s “trail map”: have a narrative of what you’re trying to achieve over time, not just task-by-task.

Chapter 3: Creating the Big Picture

Vision vs. strategy

Technical vision: describes the desired future state once problems are solved — a “north star”; can be written at any scope; doesn’t need to specify implementation.
Technical strategy: a plan of action to get there. Rumelt’s “kernel of a strategy”: diagnosis (simplified honest picture of what’s going on), guiding policy (short, clear direction for bypassing obstacles), coherent actions (concrete commitments — implying explicit non-commitments elsewhere).
Only create these documents if genuinely needed — a simpler goals section or design doc may suffice; adapt scope/format to what the org actually needs.

The Approach (before writing)

Expect the answer to be “boring”/synthesis, not a flash of genius — most of the work is alignment, not invention.
If someone’s already working on it: share the lead, follow their lead, or step away — avoid competing “ape games”/politicking.
Get an executive sponsor (staff+ engineers can’t self-sponsor) — align with their goals, have a tight elevator pitch, and keep checking that sponsorship hasn’t quietly lapsed.
Choose a small core group (2–4 people) with real time commitment, plus a wider circle of allies/interviewees; be explicit about lead vs. first-among-equals roles.
Set scope realistically — align with your actual sphere of influence and fixed constraints; avoid “magical thinking” about things outside your control.
Sanity-check achievability: talk to people who’ve tried similar efforts before investing heavily; if not achievable, options are: proceed blindly, recruit missing skills, shrink scope, accept no strategy is coming (and it’s fine), or accept no strategy is coming (and it’s not fine — reconsider your fit).
“Make it official” checklist before starting: is it needed, is the answer likely boring, no competing effort (or joined it), org support exists, agreement on the deliverable, problem is solvable by you, and honest about all of the above.

The Writing

Iterative writing loop (not linear): initial ideas → writing → interviews → thinking time → decisions → alignment, revisited many times; timebox it to avoid endless dragging.
Initial framing questions: what documents/constraints already exist (inherit from broader scope), what needs to change, what’s already great (don’t lose it), what’s actually important, “what will Future You wish Present You had done” (“sending a cookie into the future”).
Writing approaches for groups: single leader drafts first (consistent voice, but biased/needs explicit “weakly held” framing) vs. aggregate multiple independent first drafts (unbiased, but risk of ownership/ego fights over whose draft wins — need a clear aggregator).
Interviewing: cast a wide net beyond your usual circle; ask open questions; always ask “what else should I have asked?”
Thinking time: differs by person (write, talk, sleep on it, prototype); watch for describing the problem in terms of a pre-chosen solution — keep asking “yes, but why?” until it traces back to the real goal.
Decision-making:
- Use “even over” statements to make trade-offs explicit.
- Seek “rough consensus” (IETF model) rather than full agreement — “can anyone not live with this?” not “does everyone love this?”
- Not deciding is itself a (usually bad) decision — the status quo; if postponing, decide to postpone and set a deadline/trigger.
- Document trade-offs and reasoning (“show your work”) so decisions aren’t relitigated.
Staying aligned: keep sponsor updated at major checkpoints; be realistic (Overton window) about how far you can push; practice “nemawashi” — build consensus quietly before the “vote” so no one is surprised; alignment is bidirectional — be ready to change your plan based on feedback.
Crafting the story: make it comprehensible (short, coherent), relatable (show benefit to each audience), comfortable (meets people where they are); use bumper-sticker slogans/personas/concrete scenarios; prepare people for the “difficult middle” of the journey, not just the destination.
Final draft: make it skimmable (images, bullets, white space, personas, concrete scenarios), avoid jargon, prepare a short elevator-pitch version alongside the full doc.

The Launch

“Official” = endorsed by the relevant top-of-chain authority (email, name on doc, all-hands mention); host it prominently; close open comments; ensure resourcing (headcount/budget) actually follows the plan.
Keep it fresh — revisit periodically or when context changes; don’t be afraid to iterate publicly if the direction turns out wrong.

PART II — EXECUTION

Chapter 4: Finite Time

Core constraint: 168 hours/week, always; everything taken on has an opportunity cost.
Put non-meeting work directly into your calendar as concrete blocks (not vague “focus time”) to make trade-offs visible and to see how much you’re actually deferring recurring tasks (a signal the task may not matter).
Build a “time graph” for a longer horizon (month/quarter) showing fixed overhead vs. available capacity.
Know your personal volatility tolerance — leave buffer for unplanned spikes (crises, opportunities) rather than running at 100% capacity.
Reject the idea of a single global priority queue — importance to the org isn’t the only factor; personal fit matters too.

Five personal resources to track (a “dashboard”)

Energy: type of work costs differently per person (meetings vs. reading vs. writing); affected by life outside work; watch for “snacking” (low-effort/low-impact busywork when tired) vs. genuine rest; assess whether an “unwinnable fight” is worth the energy.
Quality of life: enjoyment of the work and colleagues; alignment with personal values; money’s effect on life circumstances.
Credibility: whether others believe you’re capable; built by solving hard problems, staying technically grounded, being calm/clear; lost through absolutism, chaos, disconnection from “the trenches.”
Social capital: whether others want to help you; a mutual “bank account” built through reciprocity and delivered results; spend deliberately, don’t squander it on causes you don’t truly care about, be careful lending/borrowing others’ capital (sponsorship risk).
Skills: constantly decaying as the industry moves; built via deliberate study, working with highly skilled people, or learning-by-doing on relevant projects.
Weighing a project = a multidimensional “bin-packing” problem across all five resources plus organizational importance — no single formula; some projects are worth taking despite being bad on one axis for other reasons.

Where projects come from (different shapes/costs)

Invited to join (momentum built-in, but maybe not growth); asking to join (don’t wait to be invited); your own idea (more selling required, more ownership); crisis/“fire alarm” (satisfying but abrupt context switch, hard to build growth narrative if overused); claiming an unowned problem/side quest (momentum builder, but distracts from bigger work); grassroots working groups (can be high-impact or a total time sink — needs buy-in, time commitment, exit criteria, decision process); unowned “someone needs to” work (sometimes worth over-indexing on as the senior person, to shield juniors); “meddling” (unsolicited involvement — avoid “lobbing a water balloon” and disengaging before consequences land).
Before committing, clarify shape: will it ramp up later, what’s the true time cost (including prep/follow-up), what are the exit criteria, are you joining short- or long-term.

Evaluation questions per resource

Energy: how many things can you actively care about at once (a rough personal limit); does this type of work energize or drain you; are you using it to procrastinate on something harder (“snacking” quadrant of low-effort/low-impact); is this particular fight worth the energy.
Quality of life: do you enjoy the actual day-to-day tasks involved (technical/PM/project/people mix); does it align with your values.
Credibility: does it exercise real technical skill (avoid “ivory tower” perception); does it demonstrate leadership.
Social capital: does it match what your org/manager expects of your level; will peers respect it; are you spending capital you’ve built without replenishing it.
Skills: will it teach something you want to learn; will your collaborators raise your game.

If a project is the wrong fit

Options: do it anyway (only sustainable short-term, and only with a clear exit plan — flag it to your manager if chronic); compensate (add a side project for what’s missing, or “torch the back burner” on lower-priority obligations to make room); let someone else lead (aggressive delegation — a “B” result from someone stretching is a great outcome); resize/reshape the engagement (join partially, for a limited time, as an advisor); or just say no (a skill to practice deliberately — “no” protects future you).
Defending your time is a core, learnable senior-level skill — demand on it will only increase.

Chapter 5: Leading Big Projects

Starting a project

Overwhelm at the start is normal and even useful (“discomfort is learning”); ambiguity/difficulty is why it needs a staff+ lead.
Coping techniques: keep a personal “anchor” document (external brain: uncertainties, leads, to-dos); align early and explicitly with your project sponsor on goals/success criteria/your role; choose who receives your uncertainty (a peer/mentor sounding board, never your junior reports); give yourself a small early win; lean into your natural strengths (code, relationships, docs) as an entry point.

Building context (mapping again, at project scale)

Goals — the underlying “why,” not just the task; question the project if it won’t actually achieve the goal.
Customer needs — identify real users (even internal ones) and their actual needs, not assumptions; budget real time for this even without a dedicated PM.
Success metrics — must be genuinely measurable and agreed with sponsor/stakeholders up front; existence of code ≠ success.
Sponsors/stakeholders/customers — know who wants this and who’s paying.
Fixed constraints — deadlines, budget, dependent teams, difficult people; describe reality plainly rather than resenting it.
Risks — predict what could derail the timeline; mitigate via prototyping, incremental releases, learning from prior similar efforts.
History — understand why past attempts succeeded/failed and any legacy components/users you must respect (“respect what came before”).
Team — map the other leaders involved (subleads, PM/EM/TPM counterparts) and build strong working relationships to avoid power struggles.

Giving the project structure

Define roles explicitly early, e.g. via a responsibility table or RACI matrix (Responsible/Accountable/Consulted/Informed) — prevents both paralysis (no decider) and endless relitigating.
As lead, you implicitly own any role nobody else is filling.
Recruit intentionally — look for complementary skills/attitudes (optimism, conflict resolution, communication), not just technical fit.
Agree on scope using the “fast/cheap/good — pick two” trade-off; break work into milestones/workstreams/phases that each deliver something demonstrable (“beta tests”), enabling course correction.
Estimate time by experience, not guesswork — small tasks estimate better; involve dependent teams’ planning cycles early; update estimates as you deliver slices.
Agree on logistics: meeting cadence, informal communication channels, status-sharing format, documentation home, development practices (languages, review standards, testing, deploy process).
Hold a kickoff meeting for shared momentum even if everything’s already written down.

Driving the project

Exploring: resist implementation details before the goal/approach is genuinely agreed; align on vocabulary and mental models across teams before designing; build a crisp “elevator pitch” describing what’s in and out of scope; stay open to existing solutions rather than a preconceived one.
Clarifying complexity for others: build shared mental models via analogies connected to what people already know; build a “ubiquitous language” (Eric Evans) so key terms mean the same thing to everyone; use pictures/diagrams/graphs to reduce cognitive load.
Designing / RFCs: written designs are cheap iteration; use a template. Minimum sections: Context (title/author/dates/status), Goals (the problem, not the implementation), Design (enough detail for readers to evaluate feasibility — use active voice, name the actor for every verb, avoid ambiguous “this/that”), Security/privacy/compliance, Alternatives considered/prior art (forces engaging with the real problem, not just a favored solution). Optional but valuable: Background, Trade-offs, Risks, Dependencies, Operations.
- “Wrong is better than vague” — commit to a specific, falsifiable design rather than hedging.
Common technical-design pitfalls to watch for: assuming the problem is brand-new; underestimating “this looks easy” domains; building only for the present (not future scale/growth) or only for a speculative distant future (overengineering); assuming every user will behave/comply; deferring the truly hard part; solving a small problem in a way that entrenches the bigger one; calling a rewrite something smaller than it is; neglecting operability (monitoring, on-call, debuggability); bikeshedding (spending disproportionate time on trivial, easily-grasped decisions — Parkinson’s Law of Triviality).
Coding: leads often review more than they write; contributing code deepens understanding and keeps you honest about your own design’s cost, but avoid using coding as a “snack” to dodge harder leadership work; avoid becoming a bottleneck — write in ways that empower others (e.g. set a reusable pattern once, then let the team extend it); pair rather than always doing it yourself, to transfer skill and ownership; hold high personal standards since your work sets the implicit team standard; avoid being a single point of failure in reviews.
Communicating: build psychological safety for cross-team questions; when sharing status, lead with impact/user-visible facts, not raw detail; be honest — don’t run a “watermelon project” (green outside, red inside); make the “so that we can…” implication explicit.
Navigating obstacles: assume something will go wrong; as the driver you’re accountable for rerouting/escalating, not just reporting “we’re blocked”; ask for help — struggling silently is the real failure.

Chapter 6: Why Have We Stopped?

Recurring toolkit for any type of blockage: (1) understand and explain, (2) make the work easier, (3) get organizational support, (4) make alternative plans. You can apply this to your own project or to unblock someone else’s (small effort, big leverage) — but still guard your own time/priorities when helping.

Blocked (temporary stalls)

Blocked by another team — root causes are usually misunderstanding, misadventure (life/staffing problems), or misalignment of relative priority; navigate via direct synchronous conversation, shrinking the ask, offering to help unblock their blocker, escalating respectfully if truly higher priority, or replanning around the gap.
Blocked by an undecided decision — the decision is often genuinely hard for the other side too; clarify what info they need, reframe the question with examples/pictures, mediate between conflicting stakeholders, or proceed on a documented best-guess with a plan to revisit.
Blocked by a single approval/button click — the “quick” task competes with many others’ asks; make requests as small/easy/self-contained as possible, be gracious, escalate only as last resort (costs goodwill), or accept the wait.
Blocked by a single person not delivering — the stated excuse is rarely the real cause (intimidation, overload, unclear ask, competing priorities); dig gently, clarify why the work matters, break work into smaller steps, pair to get them unstuck, escalate to their manager only as a last resort (a real people-management issue).
Blocked by unassigned/unowned work — a “plate tectonics” gap nobody owns; write a clear “rollup” synthesizing scattered facts into an explicit conclusion; advocate for organizational sponsorship/ownership; treat repeated “next quarter” staffing promises as a signal the work isn’t truly prioritized.
Blocked by mass adoption (a migration needing many teams) — reduce work required from adopters, automate everything possible, make the new way the default/easiest path, show visible progress metrics, escalate priority organizationally, and as a last resort add friction to the old path or force remaining holdouts to own it themselves.

Lost (no clear path, even without external blockers)

Don’t know where you’re all going — big ambiguous group efforts get stuck in analysis paralysis; fix by clarifying decision-making roles/authority, choosing (or delegating) a strategy process, picking any concrete problem to start on, or reorienting around a single stakeholder/vertical slice.
Don’t know how to get there — the problem is just hard; articulate it precisely, question your assumptions (are you fixed on one solution?), give it time (sleep/vacation), carve out real deep-focus time, look for prior art inside/outside the industry, ask others, try a different problem angle, start smaller, ask for help.
Don’t know where you stand — org/leadership changes create uncertainty about whether your project still matters; clarify organizational support directly, formalize your role/authority (RACI, role doc), ask explicitly for visible backing, and refuel team energy (new milestones, kickoff-style reset) if morale is low.

Arrived somewhere — but not really done

“Code complete” isn’t the same as usable — “nobody wants to use software, they want to catch a Pokémon”; counter with an agreed definition of done, dogfooding your own work, and celebrating landings (real usage) not launches (internal completion).
Built but undiscovered (“Beware of the Leopard” problem) — internal tools die from lack of marketing; actively “sell” the solution (repeated communication, discoverability, testimonials, road shows), don’t just document once and stop.
Built on a shaky foundation — shipped-fast solutions accumulate technical debt that never gets revisited; counter by modeling a quality culture, framing cleanup as a user story, and negotiating dedicated engineer-led cleanup time.

Deliberately ending a project

“This is a better place to stop” — declare success and move on once further investment isn’t worth it (watch for the local-maximum trap of over-polishing).
“Not the right journey” — recognize the sunk-cost fallacy; cutting losses on a genuinely doomed direction is a success, not a failure, if done honestly with a retrospective.
Canceled by outside forces — acknowledge the team’s feelings, deliver the news yourself (not via gossip/all-hands), protect people’s career narratives/promotion cases, clean up remnants, retrospective if useful.
True completion — verify metrics/usability/foundation actually hold before celebrating; mark the occasion, retrospective on what went right too, highlight desired cultural behaviors that showed up.

PART III — LEVELING UP

Chapter 7: You’re a Role Model Now (Sorry)

Passive influence: whatever you actually do (not stated values) becomes the implicit standard others emulate — promotions, reviews rewarded, and behaviors tolerated define real culture.
Being a role model doesn’t require being loud/extroverted — quiet, consistent competence and collaboration count; it’s a learnable, buildable skill, not an identity.

Be competent

Know things: technical skill comes from sustained deliberate practice/experience, not innate talent; avoid rushing out of hands-on technical work too early in your career (management or staff+ role) — you may cheat yourself of prime skill-building years.
Build domain knowledge quickly when moving into a new area — use broad pattern-matching from past experience as “hooks,” study core literature, learn the players/jargon, then get hands-on.
Stay up to date — keep your instincts current even if you’re not writing much code; avoid learning only “how your company works” rather than the underlying tech.
Model visible learning — explain your reasoning/sources so it’s safe for others to admit gaps too.
Be self-aware: know and state confidently what you do know (without needing to be “best in the industry”); openly admit what you don’t know (ask for “ELI5”s); understand that your own perspective/context isn’t universal — this is what lets you translate across audiences.
Have high standards: actively seek constructive criticism (request reviews, don’t resent them); own mistakes fully (admit, fix, protect innocent colleagues from misplaced blame, consider a retrospective) rather than deflecting; be reliable — the highest compliment is “I don’t need to be there because X will handle it,” and reliability includes seeing things through to completion.

Be responsible

Take ownership: own the whole problem including the messy unglamorous parts; avoid “Cover Your Ass Engineering” (CYAE — hiding behind narrow specs); “radiate intent” (signal what you’re about to do) rather than either asking permission or acting in secret — it keeps you accountable while allowing intervention.
Make decisions and own being wrong; ask the “obvious” questions nobody else will risk asking; avoid “delegating through neglect” — recognize invisible “glue work” (coordination, onboarding, unblocking) and don’t let it silently fall on junior people who need technical growth time instead.
Take charge: explicitly claim coordination during emergencies (Incident Command System model) — silent coordination doesn’t work; ask “dumb” clarifying questions on others’ behalf during confusion; drive meetings (agendas, notes — note-taking is high-status glue work, not administrative drudgery); speak up publicly when something disrespectful/harmful is said (support the target publicly; it doesn’t have to be perfectly worded, just said) and separately flag patterns to the person’s manager.
Create calm: defuse rather than amplify problems; stay curious and blame-free when investigating mistakes (what info was missing, where did mental models diverge); be consistent/predictable so colleagues know what to expect from you, which requires managing your own sustainability (rest, boundaries).

Remember the goal

Remember there’s a business: standards (speed vs. stability) must adapt to context (hackathon vs. life-critical system, outage vs. normal operations); be aware there’s a finite budget/headcount and that spending it is a real trade-off (Dan McKinley’s “innovation tokens”); know when “good enough” is actually done.
Remember there’s a user: build for real, observed users and requirements, not “perfectly spherical” imagined ones; share mockups/APIs early; avoid CYAE — meeting the spec doesn’t matter if the user’s need isn’t met.
Remember there’s a team: don’t become a single point of failure by grabbing every hard problem; measure your impact by what wouldn’t have happened without you, including what you enabled others to do.

Look ahead

Anticipate what Future You/the team will wish you’d done: telegraph upcoming changes (e.g., announce future deprecations early even before ready) so others can plan; tidy up your working environment for whoever comes next; continually invest in tooling/velocity (build speed = shorter every future outage); create institutional/written memory (decision records, system histories, comments with real context) since staff turnover is inevitable.
Expect failure: assume unpredictable failures will happen (even from unrelated systems); build tested error paths, practiced incident response conventions, chaos/game-day drills, and verified backups.
Optimize for maintenance, not creation: software is “programming integrated over time” — spend real effort making systems understandable (short docs, tracing/observability, one big picture diagram) and simple (a first solution is “just the first” — invest in a simpler second pass; contain unavoidable complexity in one well-chosen place rather than scattering it); design components to be easy to decommission later (clean interfaces, visibility into remaining clients).
Create future leaders: give juniors room to do the hard/interesting work themselves rather than doing it all yourself. Ultimate metric of success (John Allspaw): whether other people want to work with you.

Chapter 8: Good Influence at Scale

Why scale your influence: better colleagues make your own work easier; the industry keeps changing and adoption of new practices needs teaching; and it’s simply the right thing to do — standards you instill propagate for generations of engineers.

Three tiers of influence (individual → group → catalyst) across four mechanisms (advice, teaching, guardrails, opportunity) — a matrix of options, not a checklist; don’t neglect small-scale (individual) influence in favor of chasing “catalyst”-level programs.

Advice

Distinguish solicited vs. unsolicited advice; ask permission before giving unsolicited advice unless there’s a safety/critical-information reason; in mentoring conversations, first check whether the person wants advice or just wants to vent/think aloud.
Individual: mentoring (share your own experience, but be aware your specific tactics may not transfer across identity/context/seniority gaps); answering questions generously (don’t withhold adjacent useful info); giving both praise and honest critical feedback on drafts/talks; peer/performance reviews — write for both the recipient’s growth and the calibration audience, and watch for biased language patterns (e.g., “abrasive” vs. “assertive”).
Group: scale advice via writing (docs, FAQs, blog posts), and via talks/presentations — look for a “microphone and an audience” moment to deliver a message.
Catalyst: build structures so people advise each other without you — encourage written documentation culture, or set up recurring tech talks/mentorship programs (note: heavier admin overhead than expected).

Teaching (deeper than advice — for internalized understanding, not just information transfer)

Individual: define a clear goal for what the learner should be able to do afterward; use hands-on/active learning; use the shadowing → pairing → reverse-shadowing spectrum depending on skill transfer needs.
Code/design review as teaching: understand what stage/purpose the review serves; explain “why” not just “what”; give concrete examples of a better alternative; explicitly flag severity (blocking vs. nitpick vs. preference); review in passes (high-level first); explicitly say “yes”/approve when you mean it, especially so juniors aren’t left waiting on ambiguous silence.
Coaching (distinct from mentoring): teaches people to solve problems themselves rather than sharing your own experience. Core skills: asking open questions, active listening (reflecting back), making space (tolerating silence) — resist jumping in with your own answer.
Group: build reusable teaching materials (classes, codelabs) with the same clear-outcome, hands-on principles — high upfront cost, amortized over repeated use.
Catalyst: teach other people to teach (hand off ownership of the class/curriculum); fold materials into official onboarding so influence continues without you.

Guardrails (let people move autonomously and safely)

Individual: rigorous code/design/change review — check whether the work should exist at all, whether it actually solves the problem, how it fails, whether it’s maintainable/observable, whether it sets a bad precedent, and whether the right people are informed. Never rubber-stamp.
Being a “project guardrail” for a colleague stretching into a harder project — ask pointed but supportive questions, and be explicit about how/when they should ask you for help.
Group: written processes/checklists for recurring risky situations (launches, incidents, tech adoption) — keep them lightweight or people will route around them; written decisions once-and-for-all (style guides, “paved road”/tech-radar lists, policies, technical vision/strategy) reduce repeated debate; make the right way easy via automation (“robots and reminders”: automated reminders, linters, discoverable search results, templates, config checkers/presubmits).
Catalyst: true culture change — the most durable but hardest guardrail; requires solving a real problem (not aspirational), choosing your battles, offering real support/tooling, and finding allies (including via the shadow org chart).

Opportunity

Individual: delegation — hand off real, messy ownership (not pre-solved “gift-wrapped” tasks) matched to a stretch-but-achievable level; redirect follow-up questions to the new owner rather than staying the de facto point of contact.
Sponsorship (Rosalind Chow’s “ABCDs”): Amplifying (publicizing good work), Boosting (recommending/endorsing), Connecting (introducing to networks), Defending (countering unfair criticism) — watch for in-group/“mirrortocracy” bias in who you sponsor.
Connecting people to opportunities just by knowing information exists (a role opening, a CFP, a training program).
Group: share the spotlight deliberately — hand off the floor in meetings, bring juniors into review/decision conversations, let others’ work (not just yours) be visible; avoid the opposite failure mode of delegating so much that your own contribution becomes invisible to your management chain.
Catalyst: build durable structures for opportunity/sponsorship (inclusive interviewing, open internal job boards) so growth continues without your direct involvement — ultimately “growing the people who will grow the next people.”
Reframe: being promoted past you (or people entering your level with less polish than you now have) isn’t lowered standards — they only need to be as good as you were when you were first promoted.

Chapter 9: What’s Next?

The trail map (4th map): your own career

Don’t just follow well-marked local trails (obvious next promotions/roles) — deliberately choose destinations, even unconventional ones, based on your own priorities.

Clarify what’s important to you (illustrative, non-exhaustive list): financial security, supporting family, schedule flexibility, deep learning/mastery, visibility/industry recognition, doing exciting work, self-challenge, wealth building, working independently, making a broader difference, enabling an outside vocation. Priorities shift over a career and there’s no universally “right” list.

Invest deliberately in

Skills — treat gaps as “not yet leveled up,” not permanent limitations; be honest that not everything is worth the time investment; watch for imposter syndrome (extremely common even at staff+ level) and choose to build skills that align with what genuinely energizes you (sustainable long-term learning).
Network — most opportunities come through relationships, not postings; a strong network means access to advice, expertise, and unlisted opportunities; networking is a learnable mechanical skill, not an innate trait.
Visibility — let people see your work (internally and, optionally, externally via talks/writing/open source) so they think of you for opportunities; treat any visibility opportunity you accept seriously (don’t waste it).
Deliberate role/project choice — you get typecast by what you spend time on; choose roles for the specific experience/skills/reputation they’ll build toward your goals, not just convenience.

Evaluate your current role

Cate Huston’s five job-health metrics to track over time (not just a single bad week): are you learning; are the skills transferable (vs. only coping with local dysfunction); how do you feel recommending friends join; how’s your confidence trending; how’s your stress/health. Employers “rent” your market-value “brand” — a bad job can quietly erode future employability.
Explicitly compare your role against your priority list — no role is optimal on every axis; identify what’s genuinely missing versus what’s a reasonable trade-off.

Reasons to stay put vs. reasons to move

Stay: feedback loops from seeing your own decisions play out, deep domain expertise, built relationships/trust, learned organizational context, life/schedule fit.
Move: risk of learning only “how this org works” rather than transferable skills, limited remaining experiences/mentors at one place, sometimes easier to gain scope/level or salary by moving, mismatch between your goals and what your org needs.

Paths onward (a non-exhaustive menu)

Stay and keep doing the same thing (fine if it’s still meeting your needs — but keep skills minimally current).
Work toward promotion — clarify what specifically you want from it (money, prestige, scope, respect) since the title itself may not deliver everything you’re hoping for; understand your org’s actual promotion mechanics.
Work fewer hours (reduced schedule) — be deliberate about which responsibilities shrink, and align expectations explicitly with your manager/team.
Change teams internally — retain relationships/context/credibility while getting a fresh problem; brings valuable cross-team perspective to the new team.
Build a new specialty/adjacent skill, potentially crossing into another track (e.g., product).
Explore via rotations/short-term embeds before committing.
Move into management — Charity Majors’s “engineer/manager pendulum” (don’t try to grow both skill sets at once; commit a genuine ~2-year tour if trying management, since switching too often is disruptive to reports); taking your first reports may mean starting as a line manager even after operating at higher IC scope.
Find or invent a bespoke niche role shaped around your specific strengths (only viable with real trust/standing, and the org’s genuine need); watch out for a role that’s flattering/prestigious but not actually enjoyable.
Change employers for the same role (best done deliberately, not as a reactive “rebound” from a bad situation); ask precisely what “staff+” means at the new org since titles vary widely.
Change employers to go up a level — easier when your domain expertise already transfers.
Change employers to go down a level deliberately — can rebuild technical grounding, offer better fit, without being a failure.
Start your own company, or go independent (consulting/contracting) — both benefit from a pre-built network and a financial cushion; independence trades security for control/variety and requires being your own generalist support structure.
Change careers entirely, applying technical experience to a different field.
Whenever you do move: expect to reset and rebuild all three organizational maps (locator, topographical, treasure) from scratch, and adapt your leadership style to the new org’s actual needs rather than replaying your last job’s playbook.

Closing message

Software has real, sometimes life-critical consequences; take the responsibility seriously without losing the fun of the craft; senior engineers set the tone for the whole industry’s future — “build good software, build a good software career, build a good software industry.”

Picking…

Kotlin

Kotlin Cheatsheet

Table of Contents

Introduction

First Kotlin program

Get input from user

Comments

KDoc

Variables

Data types

Type Inference

Type Conversion

String templates

Character escape

Operators

Control flow

If-else

When

Conditional Expression

For loop

Ranges

While

Do While

Break and Continue

Exceptions

Functions

Function Declaration

Default arguments and named arguments

Function Return Types

Local functions

Member functions

Generic functions

Lambda Expressions

Extension Functions and Properties

Higher-Order Functions

Operator overloading

Variable number of arguments (varargs)

Infix notation

Scope Functions

Collections

Array

List

Map

Set

Class and Object

Classes

Property and methods

Getters and setters

Visibility modifiers

Late-initialized properties and variables

Inheritance

Interface and Abstract Class

Abstraction

Polymorphism

Object Expression and Declaration

Data class

Nested and Inner class

Type aliases

Enum

Sealed class and interface

Generics

Delegation Pattern

Delegated properties

Other Topics

Destructuring declarations

Reflection

Annotations

Packages and imports

Null safety

Equality

Comparable

Regex

The Signal and the Noise (Nate Silver)

The Signal and the Noise — Nate Silver

1. Executive Summary

2. Main Points (ranked by importance)

3. Critique — Points Readers Might Push Back On

4. Representative Quotes

The Staff Engineer's Path

The Staff Engineer’s Path — Tanya Reilly (Structured Summary)