More on this book
Community
Kindle Notes & Highlights
by
Gene Kim
Read between
December 1 - December 9, 2019
“You can choose to build new features or you can choose to pay down complexity debt. When a fool spends all their time on features, the inevitable outcome is that even easy tasks become difficult and take longer to execute. And no matter how hard you try or how many people you have, it eventually collapses under its own weight , forcing you to start over from scratch.”
Three Ways and the Four Types of Work.”
The First Ideal—Locality and Simplicity The Second Ideal—Focus, Flow, and Joy The Third Ideal—Improvement of Daily Work The Fourth Ideal—Psychological Safety The Fifth Ideal—Customer Focus
QA is often viewed as an underclass, but at least they’re above Ops. All of which is crap,
We can’t keep being the people who test after the fact. We need to get into the game, and that means finagling our way into the development teams that are actually responsible for shipping features and the quality of their outcomes. Anything else is a waste of our time.”
race conditions are one of the toughest categories of problems in all of distributed systems and software engineering.
Someone once called these problems “heisenbugs,” referring to the quantum physics phenomena where the act of observation changes the nature of reality itself.
It is almost impossible to predict how a program will behave if any other part of the program can change data that you’re depending on at any time,
fixing the code especially for features is just a fraction of the entire job. It’s not done until that customer can use what they’ve written.
Being able to test and push code to production is more productive, makes for happier customers, creates accountability of code quality to the people who write it, and also makes the work more joyful and rewarding.
the changes that need to be made are not localized. Instead, their scattered across many, many different teams. This is not the famous Amazon ideal of the “two-pizza team,” where features can be created by individual teams that can be fed with two pizzas.
Every tech giant has nearly been killed by technical debt. You name it: Facebook, Amazon, Netflix, Google, Microsoft, eBay, LinkedIn, Twitter, and so many more.
for every survivor, there are companies like Nokia who fell from the loftiest heights, killed by technical debt.
“All the tech giants, at some point in their history, have used the feature freeze to massively rearchitect their systems.
Satya Nadella, CEO of Microsoft, still has a culture that if a developer ever has a choice between working on a feature or developer productivity, they should always choose developer productivity.
Amazon likely spent over $1 billion over six years rearchitecting all their internal services to be decoupled from each other.
they spent hundreds of millions of dollars hiring developers and investing in rolling out Agile. But they did so without realizing their real problem: technical debt in the form of an architecture where developers could not be productive.
“Business people can see features or apps, so getting funding for those is easy,” he continues. “But they don’t see the vast architectures underneath that support them, connecting systems, teams, and data to each other. And underneath that is something extraordinarily important: the systems that developers use in their daily work to be productive.
the tech giants assign their very best engineers to that bottom layer, so that every developer can benefit.
Absolutely no one can get anything done if they have to work with eight other teams all the time,
A century ago, when mass production revolutionized industry, the role of the leader was to design and decompose the work and to verify that it was performed correctly by armies of interchangeable workers, who were paid to use their hands, not their heads. Work was atomized, standardized, and optimized. And workers had little ability to improve the system they worked within.
“Innovation and learning occur at the edges, not the core. Problems must be solved on the front-lines, where daily work is performed by the world’s foremost experts who confront those problems most often.
Third Ideal is Improvement of Daily Work. It is the dynamic that allows us to change and improve how ...
This highlight has been truncated due to consecutive passage length restrictions.
Dr. Steven Spear said, ‘It is ignorance that is the mother of all problems, and the only thing that ...
This highlight has been truncated due to consecutive passage length restrictions.
“The opposite of the Third Ideal is someone who values process compliance and TWWADI,” he says with a big smile. “You know, ‘The Way We’ve Always Done It.’
W. Edwards Deming once observed, ‘a bad system will beat a good person every time.’
General Stanley McChrystal massively decentralized decision-making authority in the Joint Special Operations Task Force to finally defeat Al Qaeda in Iraq, their much smaller but nimbler adversary.
“That’s not servant leadership, it’s transformational leadership,” Erik says. “It requires understanding the vision of the organization, the intellectual stimulation to question the basic assumptions of how work is performed, inspirational communication, personal recognition, and supportive leadership.
“Some think it’s about leaders being nice,” Erik guffaws. “Nonsense. It’s about excellence, the ruthless pursuit of perfection, the urgency to achieve the mission, a constant dissatisfaction with the status quo, and a zeal for helping those the organization serves.
Fourth Ideal of Psychological Safety. No one will take risks, experiment, or innovate in a culture of fear, where people are...
This highlight has been truncated due to consecutive passage length restrictions.
Researchers at Google spent years on Project Oxygen and found that psychological safety was one of the most important factors of great teams: where there was confidence that the team would not embarrass, reject, or punish someone for speaking up.
You are in an organization where everyone is making decisions, solving important problems every day, and teaching others what they’ve learned,” Erik says. “Your adversary is an organization where only the top leaders make decisions. Who will win? Your victory is inevitable.
“He gave out his home phone number to all plant workers, telling them to call him if they ever saw plant managers not acting quickly enough or not taking safety seriously.
“I’ve always wondered where our work goes after we’re done with it. It’s always felt like flushing the toilet—you put your code in the toilet bowl, press the lever, and it disappears from sight …”
The last thing a QA person wants to hear from a developer they just met is their ideas on how to automate their job away.
everyone merges their changes frequently to the ‘master branch,’ such as once per day. That way, the size of the changes being merged are never allowed to get too large.
Small batch sizes, like in manufacturing, create a smooth flow of work, with no jarring disruptions or catastrophes.
what’s the plural of ‘developer’?” says Maxine. “A ‘merge conflict.’”
Those reasons don’t make sense at all. I think I know the real reason we aren’t allowed to push our changes … they don’t trust us. Doesn’t that bother you?! How can Jared know more about making changes than the developers who wrote them?”
We don’t even need guards anymore. We love being prisoners so much, we just think the bars are there to keep us safe.
Learned Helpless
developers will eventually be responsible for testing their own code, with QA taking a more strategic role, coaching and consulting.
This is one of the great things about using Docker containers, Maxine thinks. Containers are immutable, unable to be changed after they’re created, so if it works in Dev, it will almost certainly work in Test.
we should really have some of the QA team permanently co-located with us.
This fast and frequent feedback is such a big part of achieving the Second Ideal of Focus, Flow, and Joy. And all of this was enabled by properly elevating the improvement of daily work over daily work itself, as dictated by the Third Ideal.
“But we are ‘the business!’ And those ‘customers’ you’re talking about aren’t our customers—they’re our colleagues! Our customers are the ones who actually pay us money!”
engineers should be writing code, not filling out forms.
The goal is clear: enable fast and safe deployments into production, and for the first time in years, do it using the same environments across Dev, Test, and Production.
Jeffrey Snover, the inventor of PowerShell. He once said, “Bash is the disease you die with, but don’t die of.”
some of the best engineers in the company are working on making everyone else more productive. That’s the way it should be, she thinks.
Early in her career, the ratio of UX and designers to developers was 1:70. These days, great teams doing consumer-oriented products have ratios of 1:6 because it’s that important to create products that people love.
