Reading journal

  • Domain Name Sanity

    I’ve wanted a clearer understanding of DNS and TLS/SSL than the one I’ve pieced together from reading Stack Overflow posts and random blog posts, so I was delighted by Edward Loveall’s book Domain Name Sanity. In about 100 pages, Loveall describes the process of registering a new domain, the many types of DNS records, DNS command line tools, common scenarios a developer might need to solve for, and how to get a TLS certificate and configure it. It was one of the most clear and concise explanations of a technical topic I’ve read.

    My favorite chapters were “Tools of the Trade” and “Securing Your Website”. The former provides an overview of dig, nslookup, ping, and a few other tools. Loveall describes when you would want to use each tool and how they might be useful in automation. The chapter on TLS gives a very clear description about public-key infrastructure, how certificates and Certificate Authorities work, and the various levels of validation. I highly recommend the book to any developer looking to get more familiar with DNS and TLS.

  • Google on Site Reliability Engineering

    Google has made its book Site Reliability Engineering available for free online, and it’s a terrific resource. Reading it was a nice supplement to some of the lessons I learned from The DevOps Handbook and The Phoenix Project.

    The most powerful ideas in the book that I would like to apply in my own work are the concepts of error budgets and Service Level Objectives (SLOs). (What most people refer to as an SLAs—Service Level Agreements—are better defined as SLOs since agreements imply some actual contract with penalties for poor performance.) Error budgets are the rate at which SLOs can be missed. 100% availability is impossible, and increasing availability often comes at the price of slower feature development. The role of an SRE is often to manage this trade-off between reliability and new feature development. An error budget specifies what a tolerable level of errors, latency, etc. is acceptable. Going over the error budget means a team needs to slow down and make their systems more reliable. Not using enough of the error budget may mean a team is too prudent and should be more aggressive with releasing new features.

    Another portion of the book I particularly enjoyed was the chapter on eliminating toil. Some of the most common attributes of toil is that it is manual, repetitive, automatable, tactical (i.e. reactive and interrupt-driven instead of proactive and strategic), lacking in enduring value, and scales O(n) as the service grows. I can think of a few of these tasks in my own work and already have a couple of ideas for how to automate this toil away.

    This is a handy book for anyone interested more in DevOps or SRE. The section on practices is particularly useful because of its case studies for applying the SRE mindset to a variety of technical problems. Although most engineering teams will not face challenges on the same scale as Google, the principles and practices discussed in this book still apply.

  • Shoe Dog by Phil Knight

    Yesterday, I finished reading Phil Knight’s memoirs, Shoe Dog. I’m a sucker for good biographies and memoirs, and this was easily the best one I’ve read since Jeannette Walls’s The Glass Castle. If you like the How I Built This podcast, Shoe Dog is a deeper and even more satisfying tale of how a giant business was built.

    Phil Knight ran for the legendary Bill Bowerman at Oregon, an experience which sparked his interest in running shoes. Bowerman co-founded Blue Ribbon, Nike’s predecessor, with Knight, and the company spent years as the distributor of Onitsuka’s shoes in the western US. Like many of the stories on How I Built This, Knight’s journey from small-business owner to the billionaire CEO of Nike was far less linear than I expected. His experience reinforced the importance of surrounding yourself with people who believe in the same mission you do and having a bit of luck.

    I can’t recommend this book highly enough. The writing is a lot better than most memoirs, and it’s evident that Knight spent a lot of time introspecting to tell as honest a story as possible. Thinking about Shoe Dog and Knight, I’m reminded of Eliezer Yudkowsky’s post “Competent Elites”. A stereotype some people might have of powerful corporate executives is that they’re good at playing “the game”, but aren’t necessarily much smarter than the average person—just more charming. Yudkowsky’s argument is that, surprisingly, people in these positions are often much more thoughtful (and happy!) than we might expect given pop culture stereotypes. That was my impression from Knight as well. He is a deep thinker that has thought carefully about how to spend time and how someone can live a meaningful life working for a shoe company. I’ve already thought about the book a lot when I haven’t been reading it, and I’m certain I’ll remember it often throughout my career.

  • Masters of Craft

    One of my new favorite podcasts, the FT’s Alphachat, recently featured an interview with Richard Ocejo, a sociologist at the City University of New York, about his new book Masters of Craft: Old Jobs in the New Urban Economy. The interview piqued my interest, and I really enjoyed reading the book. Ocejo works in or shadows workers in four occupations—craft cocktail bartenders, distillers, barbers, and butchers— in an attempt to understand why middle-class, well-educated young people are taking jobs in these formerly lower-status fields. As a consumer of some of these products and services, I was also interested in his answer to this question.

    Ocejo points to three changes that are driving these newly elite occupations and forms of consumption. First, consumers have different understandings of taste than they used to. Previously, it was easy to say what things were “high” culture or taste, and therefore high class (for example, fine French food). Now elites are “omnivorous”. They consume low-, middle-, and highbrow products without risking their status as elites. They still maintain definitions of what “good” products are, and oftentimes, these definitions make it so that these products remain accessible in terms of taste and price to elites only.

    Second, these businesses take the place of community institutions in many urban neighborhoods. Consumers see these businesses as community oriented, even though they very rarely play the same role that preceding businesses might have played. Consumers rarely form close friendships or relationships with staff or with other customers.

    Third, these occupations reflect economic changes in a new urban economy that is less dependent upon manufacturing and is more service- and knowledge-oriented than ever before. The workers in these occupations have carved out niches of high status in what are often low-status industries. Instead of simply selling a product or service, they also sell the idea behind the product or service and an opportunity to join the taste community that they workers are a part of. Importantly, these occupations are also mostly male. They give men an opportunity to practice masculinity through manual labor, while retaining high status through the detailed knowledge they must gain to be respected by their peers and customers.

    Masters of Craft is a fun book to read, and I was consistently impressed at how keen an observer Ocejo is. Reading the book has made me look more carefully at businesses that I walk into and has made me more aware of workers in these types of businesses affect my own tastes.

  • The Goal - A Process of Ongoing Improvement

    During our discussions about The Phoenix Project at an engineering bookclub at work, one of my colleagues recommended Eliyah Goldratt and Jeff Cox’s book The Goal: A Process of Ongoing Improvement. In The Goal, the didactic novel that inspired The Phoenix Project, Goldratt and Cox explain the Theory of Constraints by telling the story of how a plant manager turns a failing plant into a successful one.

    The book’s protagonist, the plant manager Alex, learns about the Theory of Constraints from his old physics professor Jonah who he runs into while waiting at an airport. Jonah asks Alex to identify what his company’s goal is. Although it might seem like the goal is to reduce costs or increase manufacturing efficiency, these measures are not quite right. If a plant automates something, it cannot be called “more productive” unless the plant is actually making more money. Jonah introduces three metrics to monitor productivity:

    1. Throughput: “the rate at which the system generates money through sales”
    2. Inventory: “all the money the system has invested in purchasing things which it intends to sell”
    3. Operational expense: “all the money the system spends in order to turn inventory into throughput”

    These measures may differ from their traditional definitions, but they help focus on the business’s real goal—making money. Anything that improves the efficiency of a part of the system without helping the system increase throughput and decrease operational expense is not productive.

    Throughout the book, Alex realizes that his team needs to identify the bottlenecks in their production process. Goldratt and Cox define a bottleneck as “any resource whose capacity is equal to or less than the demand placed on it”.

    To improve productivity, we need to learn to focus on bottlenecks at the exclusion of non-bottlenecks. Alex and his team come up with five steps for a process that improves productivity by alleviating constraints:

    1. Identify the bottlenecks.
    2. Decide how to exploit the bottlenecks.
    3. Subordinate everything else to the decisions about how to alleviate the constraints and to maximize flow through the constraints.
    4. Evaluate the system’s constraints.
    5. If you have broken a constraint, start the process over. But don’t allow inertia to create a new constraint.

    Perhaps these steps sound obvious, but they have serious implications for improving productivity in manufacturing and many other fields. A colleague of mine and I were discussing yesterday what constraints we have in our process, which we loosely defined as taking user stories and turning them into production features. This approach definitely helps us focus on how we can improve our team’s throughput and how we can identify the constraints in the larger software delivery process.

  • Age of Ambition

    I’ve always enjoyed listening to Evan Osnos’s appearances on The New Yorker’s Political Scene podcast and have been pretty interested in China since taking a course on modern Chinese history in college. I had meant to read Osnos’s book Age of Ambition: Chasing Fortune, Truth, and Faith in the New China for a few years, but I finally got around to it the past couple of weeks.

    The book documents the transformation of Chinese society over the past ten to twenty years. Osnos, who lived in China for the better part of a decade, covers many issues in the book—China’s opening up to market reforms, widespread government corruption, massive infrastructure programs, the lack of political liberty, censorship, and more.

    Some of the aspects of the book that surprised me most were how little many people know about consequential events like the Great Leap Forward or Tiananmen Square, how satisfied—at least according to some opinion polls—many Chinese people are with the way the country is developing, and how people think about the West.

    The most interesting parts of the book were the chapters on how the government, its censors, and its 50 Cent Party (people paid a small fee to post flatteringly about the government or unflatteringly about its opponents on social media) constantly struggle to keep up with developments in the news and pop culture. As more Chinese people have become connected to the Internet and have become more tech-savvy, it has been harder for the government to curtail free speech. Even when government censors blacklist certain words or phrases, users come up with ingenious homonyms to post about sensitive topics.

    At so many points while reading this book, I thought to myself that so much of the news I read in the United States seems less significant when compared to the scale at which things happen in China. Osnos cites almost inconceivable rates at which things happen in China—the number of miners killed in accidents each week, the number of people killed in car accidents every hour, the number of people going online for the first time every day. It made me realize that it’s hard to think about any global issue without thinking about China right in the middle of it.

    I enjoyed the format of the book a lot. Osnos intersperses his own personal experiences and his news analysis with interviews he conducts with a variety of Chinese people, including a bold newspaper editor, a young aspiring entrepreneur, famous artists and bloggers, and many others. Even when writing about issues that seem hard to comprehend as an American, Osnos treats his subjects fairly and with a lot of sympathy. I would recommend this book to anyone who wants to learn more about China and how it operates.

  • Creativity, Inc.

    After hearing recommendations for Ed Catmull and Amy Wallace’s book Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Innovation in a handful of places, I decided to give the book a try. Catmull describes his journey from aspiring animator to computer scientist to co-founder and president of Pixar. He and Wallace offer lessons for how to foster creativity in an organization and how to reliably produce quality products. I enjoyed reading the book and learning more about how Pixar grew despite making movies that required tens of thousands of person-weeks to produce.

    Technical expertise promotes creativity

    Catmull’s experience shows how developing expertise in a technical subject opens the door to innovative ideas. He pioneered many important ideas in computer animation because he had the requisite technical knowledge to develop ideas no one else had been able to implement. Without his knowledge of physics, algorithms, and software, it’s unlikely he would have come up with the ideas that he did. Pushing the boundaries of knowledge within your field or combining that knowledge with insights from other disciplines can help you come up with creative ideas.

    Focus on quality and opportunities. Don’t be stubborn and stick with a failing plan or team.

    Although Catmull had dreamed of creating the first feature-length computer-animated film, Pixar started out as a hardware company. To show off some of their hardware’s capabilities, the company made short demonstrations at conferences. The hardware business ultimately faltered. But out of that failure grew a small animation department that started making shorts for other companies and eventually was able to strike a deal with Disney to make Toy Story. Rather than staying the course and trying to sell hardware, Pixar’s leadership recognized that they could pivot and possibly succeed making films.

    Throughout the book, Catmull and Wallace describe examples in which the company spent a lot of money on a project or invested a lot of time in a potential leader only to achieve disappointing results. Instead of doubling down on these decisions, Catmull and Pixar’s leadership learned to cut their losses. Through these experiences, they realized that a good team can come up with lots of good ideas. But the wrong team cannot convert on a valuable idea. By focusing on quality, avoiding the sunk-cost fallacy, and building around strong core teams, Pixar flourished.

    Notes Day

    My favorite practical idea from the book—and one I would like to try in my organization—is Notes Day. Seeking to reduce the amount of time it took to create a feature-length movie, Catmull proposed a day for employees not to work on their day-to-day work but instead propose and discuss practical ideas for how to improve efficiency. Nearly every employee participated and teams produced hundreds of ideas about how to make the company work better.

    Notes Day wasn’t an ordinary time to fill in a survey a wonder if any of your feedback would be read or incorporated. After each Notes Day session, employees wrote down which ideas were best and who would be the best person to pitch the idea to management. Immediately following Notes Day, these individuals pitched their ideas to management. Catmull and the other leaders at Pixar then worked on giving people the resources and direction to implement these changes. Notes Day is a lovely example of how a company can improve flow, get feedback, and create a learning culture à la the Three Ways of The DevOps Handbook.

    Part memoir, part business book, Creativity, Inc. is a fun read with many useful ideas for how to enable organizations to do creative work.

  • Ilya Grigorik, High Performance Browser Networking

    As a web developer at Comcast, I have to take web performance seriously. Many of our applications serve millions of people living all over the United States. Some of our customers use the latest versions of browsers and operating systems. Others may still be running old versions of Internet Explorer. So we need to understand performance, load balancing, uptime, and other concepts if we want to serve all of our customers well.

    I couldn’t have found a better book than Ilya Grigorik’s High Performance Browser Networking to explain the different layers between the applications we build as software engineers and the devices our users use. From the physical and data link layers all the way up to the application layer, Grigorik describes how clients and servers communicate over a variety of protocols, how users perceive performance, and how developers can optimize their work to deliver reliable, secure, and performant applications.

    The book, available to read for free online, is broken up into four main sections: Networking 101, Performance of Wireless Networks, HTTP, and Browser APIs and Protocols. Some of the best chapters cover:

    • How mobile providers operate networks that handle the traffic of millions of devices across many different cells
    • The performance benefits of using HTTP/2
    • Comparisons of the XMLHttpRequest, Server-Side Event, and WebSocket protocols

    The book gave me a number of performance-boosting tips I would like to implement in the projects I work on. Some of Grigorik’s suggestions include:

    • Thinking carefully about how to minimize latency through keepalives, caching, request and response multiplexing, etc.
    • Using TLS and HTTP/2 as much as possible
    • Using TCP best practices like disabling slow-start after idle, enabling window scaling, and using TCP Fast Open if available
    • Minimizing DNS lookups

    There are many more tips in the chapter on optimizing application delivery. I highly recommend the book to anyone looking to learn more about web performance.

  • What It Takes

    Before reading Richard Ben Cramer’s What It Takes: The Way to the White House, I had only a passing familiarity with the 1988 US presidential election. I knew George Bush trounced Michael Dukakis in the general election, but I didn’t know much about the primaries or the candidates. Reading this book, I felt like Cramer must have had a Rita-Skeeter-like ability to transform into a beetle and listen in on conversations. The level of access and intimacy he shared with the candidates blew me away. Over the book’s 1,000-plus pages, Cramer profiles Bush, Dukakis, Bob Dole, Dick Gephardt, Gary Hart, and Joe Biden as they battled during the primaries.

    But the book goes beyond the year preceding the election to describe each candidate’s upbringing, formative experiences, and political maturation. Chapters simply titled by year (e.g. 1945, 1972) chronicle the injuries Dole suffered during World War II, Bush’s business ventures in Texas, and Biden’s childhood antics. These chapters, as much as the ones about the campaigns, helped me understand what motivated these men and what they thought of the country.

    Perhaps I am naive, but the 1988 campaign seems much more civil than the one we have just endured. Towards the end of the book, Bush laments how dirty the campaign became. But as a reader in 2017, the controversial attack ads of 1988 seem tame when held up to the rhetoric we hear daily.

    After Cramer passed away in 2013, Biden said, “It is a powerful thing to read a book someone has written about you, and to find both the observations and criticisms so sharp and insightful that you learn something new and meaningful about yourself. That was my experience with Richard.” Sharp, insightful, meaningful—those are perfect words to describe this book. It is not only tailor-made for political junkies, but it’s also a sympathetic and nuanced inspection of six imperfect men who played major roles in our history.

  • The Phoenix Project and The Effective Executive

    As I mentioned in my review of The DevOps Handbook, a few of my colleagues and I have been reading The Phoenix Project as part of a bookclub. It’s a fun take on a technical topic—a didactic novel about transforming an IT organization to practice DevOps.

    I won’t rehash too many of the main points here since they overlap so much with those of The DevOps Handbook. But I do want to point out how much many of the lessons dovetail with an older management book I finished recently, Peter F. Drucker’s The Effective Executive.

    Drucker is a household name in the world of management and for good reason. He writes clearly and the practices he espouses are memorable. Simply being in charge of managing others or having the word “manager” in your title does not make you an executive, at least not an effective one. Instead, it is someone who takes ownership of results and focuses on the unique contribution they can make to the team regardless of seniority. You don’t have to manage people to think like an effective executive.

    His practices of effective executives remind me of “The Three Ways” discussed in the two DevOps books. Effective leaders know where their time goes, focus on outward contributions, build on strengths, concentrate on the few areas that produce the biggest gains, and make decisions using a systematic process.

    Teams that practice DevOps do the same thing. They try to improve flow by looking at their value stream map to see where work tends to idle. They make individuals knowledgeable about and responsible for development, security, and operations, rather than dividing these competencies into separate roles. Teams practicing DevOps hone in on the critical, limiting factors in their workflows. By focusing on these few constraints, they deliver more than they could by trying to improve everything at once. Both effective executives and teams work on collecting feedback and implementing processes to learn from that feedback.

    I can understand why Drucker’s writing is so popular. It has stood the test of time well. Although The Phoenix Project is not the Great American Novel, its format is particularly engaging for a technical book. Kudos to the writers for bringing DevOps to life.

  • Charles Petzold's Code

    As one of the many developers that did not study computer science in school, I have wanted to learn more about the lower levels of how computers actually work. Much of the work I do uses high-level languages like Ruby and JavaScript, but I didn’t have a great sense of how the machine code executed after my code is compiled. How does the machine code get converted into electric signals? How are logical operators like AND, OR, XOR, and NOR constructed in circuitry?

    Charles Petzold’s book Code: The Hidden Language of Computer Hardware and Software answered these questions. I really enjoyed his style of writing and sense of humor. The book guides you through the basics of code and some familiar codes that help you understand computer code. For example, he describes braille and Morse code in great detail. These foundations help make the information about telegraphs, relays, and gates more accessible.

    The latter half of the book describes how we get from electric circuits to a system that can “remember” data, i.e. memory. From there, we learn about chips, disk drives, semiconductors, and more. The last few chapters deal with text encoding, fixed and floating point numbers, programming languages, and computer graphics.

    Although the book was published in 2000, all of the material remains interesting and often applicable. I wish I had read this book a long time ago because it has given me a much better comprehension of what happens once my code is compiled and executed. If you are interested in how computers work or are a developer who wants to get “closer to the metal” this is a worthwhile read.

  • The DevOps Handbook

    A group of my colleagues and I are reading The Phoenix Project, a novel about a struggling IT organization attempting to bring together development, operations, and security. Reading it has been a fun way of remembering some DevOps techniques. Since I’ve been enjoying the book so much, I decided to pick up a copy of The DevOps Handbook. Written by some of the leaders in the DevOps and Continuous Delivery movements, it is an excellent guide to implementing DevOps techniques and improving how work gets done in a technology organization. I’ve already seen ways to apply these lessons to my team at work.

    The authors start off the book with an introduction to their “Three Ways” before describing how to start integrating development and operations. The bulk of the book covers each of the Ways in more depth. These are the core principles behind developing products customers want reliably, quickly, and securely.

    The First Way: Flow

    The First Way involves improving flow through an organization. As a technology organization, we want to increase throughput in a system so that new ideas and features are brought to market swiftly, rather than lingering for months in a backlog of user stories.

    To improve flow, we first need to understand the work flowing through our system. The time an item spends waiting in a queue is a function of the extent to which a required resource is occupied.

    Wait time grows as a function of resource business

    This is a crucial insight. If a person or a team is continually occupied near 100 percent of capacity, new work piles up and moves through the system very slowly. When a resource has some slack, however, wait times fall dramatically. To improve flow, the authors suggest limiting the amount of work in progress you have, keeping batch sizes small, and reducing handoffs between teams.

    Improving flow does not work, however, simply by making random parts of your organization more efficient. You must identify the key constraint, the limiting variable, where work piles up. This point is where you must improve efficiency to increase flow. Improving the efficiency of another part of the organization will simply allow work to pile up at the limiting variable even faster.

    Some of the other guidelines in this section include:

    • Enabling developers to create deployment pipelines for a variety of environments from dev all the way through production
    • Implementing thorough test suites
    • Practicing Continuous Integration
    • Automating deployments and making releases as low-risk as possible

    The Second Way: Feedback

    Improved flow is good, but a technology organization’s work requires feedback. To get feedback, the authors suggest creating telemetry, or metrics, that allow teams to pinpoint and solve problems. Organizations should collect a variety of data types—from low-level environment data to high-level business logic data. Different types of data will be useful for different people and will point to different problems.

    As with testing, security, and broader operations work, telemetry must be part of teams’ regular, daily work. When telemetry is widely implemented, it can not only help resolve issues, but also serve teams looking to A/B test new features.

    The Third Way: Learning and Experimentation

    With good instrumentation in place, organizations can use the feedback they get to create a learning culture that looks not to blame people when things inevitably go wrong, but rather encourages enlightened risk-taking. The authors describe how to conduct a “blameless post-mortem” when incidents occur and how to regularly practice resolving production failures. They describe Netflix’s famous Simian Army, and point out how as organizations improve, they can fine-tune their failure detectors to look for weaker failure signals, making their applications even more resilient.

    The final chapters in this section provide some actionable tactics for sharing knowledge within and organization and performing regular maintenance to avoid the accretion of technical debt.

    The book concludes with descriptions of security and change control practices that echo the lessons from earlier in the book. Namely, security should be part of everyone’s daily work, not some isolated security team that swoops in after the fact. Organizations can make change control simpler by making smaller, lower-risk changes that don’t need to go through a cumbersome change control process. Bringing the deployment and change control process closer to the developers who created the changes gives them more skin in the game and reduces the risks when an organization rigidly separates duties.

    The DevOps Handbook is an excellent book, and I am confident I will use it many times in my work. Even if you’re not a developer, there are many lessons here for how to lead an organization to do better, more reliable work that responds to customer needs.

  • Hope in the Dark

    I bought Rebecca Solnit’s book Hope in the Dark: Untold Histories, Wild Possibilities after hearing Bob Garfield interview her on On the Media. She wrote the book after George W. Bush was re-elected in 2004, attempting to show people why there might be cause for hope among people like herself who opposed the war in Iraq and other Bush administration policies. The book has been increasing in popularity lately as people distraught by the election of President Trump look for constructive ways to move forward.

    There were a lot of useful perspectives in this book that I haven’t seen eleswhere. She makes clear that having hope isn’t equivalent to being a Pollyanna. Instead, it is a reason to act and not to despair or retreat into apathy. I liked her points about how sometimes the seeds of change take a long time to grow. She notes that it was unfathomable to many people that the Berlin Wall would ever fall or that Nelson Mandela would be freed and become president of a post-apartheid South Africa. The people fighting for marriage equality twenty or twenty-five years ago may have seemed like out-of-touch idealists. Today, their dreams are an uncontroversial fact for many people. Even the battles people fighting for social change seemingly have lost might have been worse had they not struggled to make their voices heard.

    At times, I had trouble reading this book because of Solnit’s hypercritical anti-globalization messages. Those arguments struck me as shallow and one-sided, ignoring the hundreds of millions of people who have escaped extreme poverty in large part because they are more connected to the rest of the world. Although I don’t agree with all of the arguments Solnit puts forward, I find some of her book convincing. There are certainly things worth working for even if it is hard to see your impact directly and even if you might lose.

  • Mastery

    Although I don’t remember where I saw Robert Greene’s book Mastery recommended, I’m glad I read it. I found it much more useful than his book The 48 Laws of Power. You can think of the book as a sort of extension to Malcolm Gladwell’s Outliers or Cal Newport’s So Good They Can’t Ignore You. Greene tries to answer what practices make some people so much more successful than others. His answer is that many hours of practice, feedback, and reflection are more important than innate talent.

    The best parts of the book are the stories about the various masters he profiles from a variety of fields—programming, architecture, dance, and more. I liked the emphasis he placed on apprenticeships and learning from existing experts. I’ve found I’ve been able to learn more deeply by working closely with people with many years of software engineering experience. Through them, I’ve learned new design patterns, security vulnerabilities to watch out for, and other lessons I would not have learned easily building smaller projects on my own.

    My most important takeaways from the book are:

    • Work with others who have already become experts in the field you care about.
    • Practice regularly.
    • Iterate and get feedback on your work. His story about how the Wright Brothers, relative amateurs, were able to able to build a successful airplane before their wealthier and better-credentialed competitors illuminates this point.
    • Create daily habits surrounding your practice so that you have set blocks of time to work deeply.
  • The Innovator's Dilemma

    One big question motivates Clayton Christensen’s book The Innovator’s Dilemma: why do successful, innovative firms fail because of disruptive innovations? Through case studies of a handful of industries, Christensen shows that companies that fail to stay at the top aren’t necessarily poorly managed. In fact, the firms that fail are often among the ones that function best. Why? The resources, habits, and processes that make these firms successful also make them vulnerable to disruptive innovation.

    Established firms innovate, but the products they develop are “sustaining” technologies. Sustaining technologies “improve the performance of established products, along the dimensions of performance that mainstream customers in major markets have historically valued”.

    Disruptive technologies, on the other hand, often have worse performance than sustaining technologies. A disruptive technology succeeds not because it meets the needs of an existing market, but rather because new markets find its features appealing. These disruptive products might not perform as well along traditional metrics of value, but they might be more convenient, reliable, or cheaper.

    If disruptive innovations are so dangerous to established firms’ success, why aren’t they capable of coming up with the disruptive innovations themselves? In fact, they are capable of developing them. Established firms consistently create sustaining innovations that improve performance. But when they put together disruptive innovations, their processes and values prevent them from successfully marketing these innovations. Managers at established firms will not want to risk their reputations to explore new markets for small profits when they know they can continue playing in existing markets and make higher margins.

    Established firms depend on their customers and investors, and small markets can’t provide the growth these firms need. Some markets where disruptive technology could succeed don’t even exist yet, so firms can’t analyze them. Firms will thus continue to move upmarket to more advanced technologies at higher margins, putting themselves at risk that the ways they are improving their product might outpace customers’ demands for improvement.

    So what can managers at successful firms do to deal with disruptive innovation? Christensen’s solution is to spin off smaller organizations within the larger organization. These internal start-ups can explore markets through trial and error and find customers whose needs are matched by disruptive technology. They don’t simply look for a technological breakthrough to let the new organization compete in existing mainstream markets. Because these organizations are small, even low margins and a small volume of customers and revenue can be exciting.

    Crucially, these small organizations do not simply import the processes and values from the larger organization. They might take resources—employees, funds, technology, etc.—from the larger organization, but they come up with their own processes for creating value and their own principles for what matters most to them. They can thus develop different, flexible cost structures that allow them to adapt to new markets.

    I really enjoyed reading this book, which my current manager recommended to me when I first interviewed at Comcast. Since I read the book, I’ve been looking for emerging disruptive technologies and how established firms like Comcast are managing them. The analytical framework in the book is very useful, and it can be applied to thinking about sustaining and disruptive technologies outside of business as well. I’m sure I will be coming back to it frequently.

  • The Passionate Programmer

    I can’t recall who recommended Chad Fowler’s book The Passionate Programmer: Creating a Remarkable Career in Software Development to me, but I’m glad I read it. Fowler has many tips for identifying technologies worth mastering, learning more about the business domain for which your software is written, executing and exceeding your responsibilities, and marketing yourself. Although I wouldn’t characterize any of the suggestions as particularly groundbreaking, I think his format and writing style are conducive to making these lessons stick.

    I found myself thinking more critically about the technologies I know best and asking myself whether they are worth betting on in the long run. I feel pretty good about learning even more about Ruby and JavaScript. But the work I’ve done in Elixir and some of the experimentation I’ve done with Elm seems important too and I’m looking forward to practicing those some more.

    My favorite part of the book were his “Act on It!” directives at the end of many chapters. These exercises offer tactical ways of practicing the habits he suggests. I’ve already made a couple of changes to my workflow and calendar based on these suggestions.

    If you’re looking for a book in the same vein as The Pragmatic Programmer, which was published by the same company, I would recommend this book. Although the book is less technical than The Pragmatic Programmer, it is useful for thinking about how to create opportunities in your career and enjoy your work more.

  • The Personal MBA

    As I take on more people and product management at my job, I’ve wanted to learn more about business. I’ve learned a lot through the work I did on the curriculum at Compass Partners (now known as Social Impact 360) and at subsequent jobs. But I thought Josh Kaufman’s The Personal MBA would be a good overview of business concepts and a useful jumping-off point for learning more about specific topics (e.g. marketing, finance, etc.).

    Kaufman organizes the book around some fundamental principles that make businesses successful. Some of these were obvious, some less so. The most useful parts of the book were his rubrics for evaluating business ideas and personal effectiveness. For example, a list on how to evaluate a market describes ten factors to score on a scale of one to ten:

    1. Urgency
    2. Market size
    3. Pricing potential
    4. Cost of customer acquisition
    5. Cost of value delivery
    6. Uniqueness of offer
    7. Speed to market
    8. Up-front delivery
    9. Upsell potential
    10. Evergreen potential

    Ideas that score above a 75 on his scale are worth pursuing, whereas ones below that threshold will need more refinement or may not be worth it at all. Kaufman has a number of lists like this in his book, and I appreciate having these concrete frameworks to evaluate new ideas.

    Although I wish the book had gone into more depth on some of the specific principles, Kaufman does provide a recommended reading list that includes more detailed books on a wide range of topics. It looks like a good list and I will certainly be reading some of them soon.

  • The Undoing Project

    Michael Lewis’s new book about the friendship of Amos Tversky and Daniel Kahneman, The Undoing Project: A Friendship that Changed Our Minds, provides an insightful look at how productive two academics could be and how their ideas have changed so many different disciplines. I greatly enjoyed reading Kahneman’s book Thinking Fast and Slow a few years ago. It made me more appreciative for how many different ways my supposedly rational mind can fail me.

    This new book traces Tversky and Kahneman’s personal histories and how they came to work together. For the most productive years of their lives, they were remarkably dependent upon each other and they produced numerous papers that changed how economists, psychologists, and other social scientists think. Lewis catalogues a few examples from other parts of life to show how others have made use of Tversky and Kahneman’s discoveries and thought experiments. I particularly liked the chapter on how Daryl Morey, the general manager of the NBA’s Houston Rockets, used some of the duo’s decision-making lessons to improve his team’s strategy in drafts and on the court.

    For people who have read a lot about decision theory or behavioral economics, there might not be that many new insights about those fields in this book. If you are new to these fields, the book is a nice introduction. Beyond these topics, the book describes how these two brilliant people decided what to work on, what to say ‘no’ to, and how to work. It’s a lovely profile of a friendship that has affected many lives.

  • The German War

    I came across this book after reading this review of it, and it piqued my curiosity. After reading Tony Judt’s Postwar: A History of Europe Since 1945, I’ve been interested in learning more about what German citizens thought and knew during World War II. Postwar shocked me because I had no idea quite how devastated Germany was during World War II and because I hadn’t expected some political opinions to have remained popular well after the war’s close.

    The German War is half social history and half military history of Germany during World War II. The social history uses German soldiers’ and civilians diaries and correspondence with each other to show what people thought they were fighting for and against. Despite Goebbels’s public speech and the press usually referring to the Holocaust as “the Jewish question”, Stargardt makes it clear that most Germans knew what fate Jews faced under the Reich. I had not realized just how much the hatred of Jews fueled public sentiment during the war. Railing against “Jewish Bolshevism” or “world Jewry” was common, and many people blamed Allied bombing as having been carried out because of a global Jewish conspiracy. The military history is carefully explained in the book, and shows how developments in the war affected public sentiment and life in Germany.

    As a reader in the 21st century, it is hard to fathom how anyone could have believed such radical and false conspiracies. But Stargardt’s primary sources show just how widespread these beliefs were. The book describes some moments towards the end of the war when German soldiers question the treatment of Jews, the pillaging of cities and towns on the eastern front of the war, etc., but these moments are few and far between. I might have thought before reading this book that Germans perhaps were isolated from foreign news sources and only heard Nazi propaganda. But this was not the case. Many people regularly listened to the BBC and other foreign media, not just for popular jazz programs, but also to see how the news was being reported in other places. Despite this exposure, it seems that most people were far more willing to believe their own government’s propaganda uncritically, at least until the waning months of the war as the fighting entered Germany.

    The German War is an engrossing portrait of life in Germany during World War II. It explains how so many millions of people, citizens and soldiers alike, could be enlisted in a cause so hateful and destructive.

  • Rework

    I finished Jason Fried and David Heinemeier Hansson’s excellent book Rework last week. The authors, the founders of 37signals, give advice about how to work and lead in ways that produce results by way of happy customers and employees. Their suggestions come in the form of short essays, the titles of which remind me of Derek Sivers’s directives. The book’s website has a list of these titles, and they provide a nice preview of what the book is like.

    This is a short book, and something you can easily read in one sitting if you’d like. I think it’s worth reading the whole thing, but my favorite essays were:

    • Making the call is making progress
    • Interruption is the enemy of productivity
    • Make tiny decisions
    • Hire managers of one
    • Hire great writers
    • Put everyone on the front lines
    • You don’t create a culture
  • Strangers in Their Own Land

    A few weeks ago, I finished reading Arlie Russell Hochschild’s Strangers in Their Own Land: Anger and Mourning on the American Right. I read it before the election with the hope of gaining a better understanding of what supporters of Donald Trump and movements like the Tea Party believe.

    Like Hochschild, I can’t name many friends or relatives whose beliefs fall on that end of the political spectrum. But after reading about the years she spent interviewing and befriending people in Louisiana, I think I have more understanding about how this kind of political movement could take place in the United States. I don’t agree with it any more than I used to, but I think I am better equipped to pass an ideological Turing test than I used to be.

    This book has stuck with me since the election, and I’ve found myself thinking about it multiple times throughout the day. I recommend checking it out. For an introduction to the book, listen to Ezra Klein’s interview with Hochschild or read this interview on Vox.

subscribe via RSS