The DevOps engineer's handbook

DevOps reading list

Books can help expand your understanding of a topic in your field. With so many books and topics, the choice can be overwhelming. Even if you narrow your choices, time is precious, and you want to make the most of it by reading books that matter. In the ever-changing IT landscape, certain books rise to the top as foundational reading that will stand the test of time.

We created a tool to find the right book for you. The tool considers your role and subject you’re interested in before providing a recommendation. The recommendations are for people in IT. From development to operations to management, we curated a list of books that should satisfy most interests.

To give you a recommendation, we ask two questions:

  1. What role do you work in?
  2. What topic are you interested in reading about?

Based on your selection, we recommend a book to help you expand your knowledge in that area. The recommendation tool isn’t exhaustive, but it can point you in the right direction.

Let’s get started!

What role do you work in?

What role do you work in?Description
Software DeliveryYou work within the software delivery life cycle (SDLC). You may be a developer or tester delivering code or a software delivery manager that oversees the SDLC process. You’re interested in improving the SDLC and following best practices.
Infrastructure and OperationsYou manage IT infrastructure to support IT operations. You administer and manage technology in the cloud and on-premises. You want to find better ways to improve processes and remove operation bottlenecks.
Running or coordinating a teamYou’re a people manager that coordinates a team to achieve outcomes. You want to improve the culture within your team and find ways to reduce team dysfunction. You look to lead by example and want to learn new ways to improve your people management skills.
Managing a product or projectYou’re a product or project manager. You engage stakeholders ranging from management, SMEs, developers, and customers. You communicate with these stakeholders to gather requirements and feedback to deliver outcomes. You want to find ways to optimize your product delivery methods.

What do you want to read about?

I want to read about…Description
DevOpsYou’ve heard about ‘DevOps’ and have some idea about what it is. Maybe it’s a culture. Perhaps it’s a set of best practices. You want a firmer understanding of DevOps and how you can use it in practice.
Theory of ConstraintsYou’ve seen how bottlenecks can slow an entire system down. You want to identify and remove the most significant bottleneck to improve your systems.
Lean and AgileYou’re interested in process improvement. How can your processes be more efficient and how can you remove unnecessary waste?
ManagementYou’re interested in management theory. You want to read a management book that will help you create better teams leading to better outcomes.
ProductYou’re interested in turning a good idea into reality. You want to know the ways to deliver a better product.
StatisticsYou want to understand statistics so you can make sense of the wealth of data in the world today.
OperationsYou’re interested in the best ways to improve IT operations. You want to learn about monitoring and observability.
Software DeliveryYou’re interested in the process of writing code and shipping it to production. You’re interested in the SDLC and want to understand best practices.

DevOps book recommendations

The Phoenix Project

The Phoenix Project book cover features servers stacked into the shape of a volcano

Gene Kim, Kevin Behr and George Spafford

The Phoenix Project is a tale about a fictitious company called Parts Unlimited and their newly minted VP of IT, Bill Palmer. With the stock price plummeting and the IT department in disarray, Bill has to navigate the ups and downs of a company looking to bring order to its IT processes.

Throughout the book, Bill interacts with other characters that will remind readers in IT of themselves or colleagues. Many characters represent familiar archetypes of IT organizations. You might recognize the grumpy DBA, the lone engineer who understands critical systems, or senior management that doesn’t understand technology.

This book puts readers in the shoes of various roles in an IT organization to help them understand perspectives, motivations, and what blocks them. Throughout the narrative, the characters learn to embrace new ways of working or fall victim to their old thinking patterns.

Many ideas presented in the Phoenix Project support DevOps principles because it’s by some of the original thought leaders of the movement. Central to the book is the concept of the Three Ways: Flow, Feedback, and Continual Experimentation and Learning.

The Phoenix Project’s follow-up, The Unicorn Project, tells the same story but from a developer’s perspective.

The Unicorn Project

The Unicorn Project book cover features an office with many workers trying to connect blue cables

Gene Kim

The Unicorn Project, a companion to the Phoenix Project, is a novel based on a company called Parts Unlimited. The story follows the company’s journey towards modern IT practices.

The story is a retelling of the Phoenix Project from the perspective of a developer named Maxine. Maxine is a skilled senior developer who, through no fault of her own, gets blamed for a disaster and gets banished to the Phoenix Project.

The Phoenix project has a reputation as a career graveyard, and Maxine has to use her resourcefulness to escape the same fate.

Through her natural leadership and development skills, Maxine makes new friends upset with the archaic ways they deliver code at the Phoenix Project. Though unwillingly at first, Maxine becomes the leader of a rebellion against the way they work. With the help of her team, Maxine introduces agile practices like Continuous Integration, data management, and functional programming and starts shifting the Phoenix Project’s culture.

From Maxine’s perspective, readers understand developers’ challenges in shipping production code. Challenges like corporate bureaucracy, blame culture, and lengthy approval processes.

The book advocates for agile practices and streamlined processes so developers can do their job with minimal restriction.

The Unicorn Project is a follow-up book to the Phoenix Project. The Phoenix Project tells the same narrative, told from the perspective of an IT manager.

The DevOps Handbook

The DevOps Handbook cover has a circular arrow cut out of an orange background showing parts of a volcano made from servers

Gene Kim, Partick Debois, John Willis

The DevOps Handbook is a guide to adopting DevOps practices. Doing so helps increase profits, lift work culture, and improve productivity.

The handbook introduces the Three Ways, the three principles underpinning DevOps:

  • The Principles of Flow
  • The Principles of Feedback
  • The Principles of Continual Learning and Experimentation

Each principle includes practical steps to get started with DevOps.

DevOps follows Conway’s Law, which states organizations will produce systems that copy their communication structures. By optimizing communication structures, organizations can manage the constraints of Conway’s Law to achieve well-organized systems.

The DevOps Handbook is foundational reading for anyone in DevOps. It’s particularly useful for managers needing advice and steps towards its adoption.

Accelerate

The Accelerate cover features abstract blue and green horizontal bars that suggest a chart

Nicole Forsgren PhD, Jez Humble, Gene Kim

Accelerate presents a statistical case of why DevOps provides business value and competitive advantage. Accelerate is an excellent book for those wanting a convincing argument to present to senior management for adopting DevOps practices.

The authors use rigorous statistical methods to measure software delivery performance through four years of research. Readers can learn how to measure the performance of their teams and the business areas to invest in to improve performance.

Accelerate places a high priority on continuous improvement against four key metrics:

  1. Lead time
  2. Deployment Frequency
  3. Mean Time to Restore (MTTR)
  4. Deployment Failure Percentage

These four metrics reinforce each other. They create a virtuous cycle and predict business success as measured by profitability, market share, and productivity.

Accelerate highlights 24 practical capabilities, like automating deployments and supporting learning. These capabilities drive improvement against the four metrics to achieve business success.

Accelerate caters to both technical and managerial workers. The book provides extensive academic sections but also presents a statistically sound case for senior managers to understand the benefits of DevOps.

Implementing Lean Software Development

Implementing Lean Software Development has a cover with a picture of recumbent bicycles in front of a pine forest and snow-capped mountains

Mary Poppendieck, Tom Poppendieck

Lean manufacturing is a management philosophy focusing on the reduction of seven wastes:

  • Over-production
  • Waiting time
  • Transportation
  • Processing
  • Inventory
  • Motion
  • Scrap

Practiced by many innovative companies, including Toyota and 3M, lean principles revolutionized manufacturing. Now it’s doing the same for software.

Implementing Lean Software Development is a follow-up to 2003’s Lean Software Development: An Agile Toolkit. The original book showed developers could apply lean manufacturing philosophy to software development. After observing its adoption in the real world, Implementing Lean Software Development delivers the lessons learned as a hands-on implementation guide.

Implementing Lean Software Development contains case studies from companies like Google to make a case for lean practices in software development. Google applies four fundamental principles:

  1. Value — Focus on the user, and all else will follow
  2. Excellence — It’s best to do one thing really, really well
  3. Democracy — Democracy on the web works
  4. Speed — Fast is better than slow

Implementing Lean Software Development introduces several key ideas and philosophies companies should focus on when delivering software. These ideas form the basis of DevOps as we know it today. This book is helpful for those interested in the origins of modern software delivery and managers wanting to use best practices in their company.

Kanban

The famous blue cover of the Kanban book has a cartoon with a team stood in front of a Kanban board. The team is talking about making process improvements

David Anderson

Kanban is a way of structuring work in software development. According to the book:

A Kanban system is a system were a number of cards equivalent to the agreed capacity of a system are placed in circulation. One card is the equivalent of one piece of work. Each card acts as a signaling mechanism. A new piece of work can be started only when a card is available. This free card is attached to a piece of work and follows it as it flows through the system. When there are no more free cards, no additional work can be started. Any new work must wait in a queue until a card becomes available. When some work is completed, its card is detached and recycled. With a card now free, a new piece of work in the queuing can be started.

The value of Kanban is to focus efforts on the tasks in progress. Kanban practitioners can’t start more work without completing an existing card. The key properties of a Kanban system are:

  • Visualize the workflow (using a Kanban board)
  • Limit work in progress
  • Measure and manage flow
  • Make progress policies explicit
  • Use models to recognize improvement opportunities

The central concept in Kanban is continuous improvement. Due to the transparency of the work philosophy, challenging interactions will happen, promoting continuous improvement.

The last part of the book provides a practical implementation guide on Kanban in your company. Kanban touches on many aspects of software delivery, product, and management.

Personal Kanban

Personal Kanban cover features an industrial-era water wheel

Jim Benson, Tonianne DeMaria Barry

Building on the principles of Kanban, Personal Kanban is about applying Kanban from an individual perspective. Kanban is about understanding our work in progress. By visualizing our work in progress, we can understand what to:

  • Prioritize
  • Take on
  • Say no to

Personal Kanban has two essential rules:

  • Make your task list visual
  • Limit your work in progress

The use of Kanban can help us manage our work in progress to complete what we started. By limiting tasks that are works in progress, we can minimize the fatigue that comes from managing too many tasks at once.

Personal Kanban provides an actionable framework to understand our work and its context. This book can help individuals structure their tasks, but it can also apply to a team practicing Personal Kanban.

The Pragmatic Programmer

The Pragmatic Programmer book cover has an old wooden surface with hand tools and wood cuttings

David Thomas, Andrew Hunt

The Pragmatic Programmer is an essential book for developing code well. The book calls software developers to care about their craft.

Why spend your life developing software unless you care about doing it well?

The Pragmatic Programmer teaches software developers to take a requirement and produce working, maintainable code that delights its users. The book has self-contained sections covering many software development aspects. Each presents best practices and pitfalls to avoid. This book applies to new coders, experienced coders, or software managers.

Throughout the book, several tips provide a philosophical idea that guides readers in how to think about software development. For example:

  • Don’t live with broken windows: Fix bad designs, wrong decisions, and poor code when you see them.
  • Prototype to learn: Prototyping is a learning experience. Its value lies not in the code you produce but in the lessons you learn.
  • Always use source code control: Source code control is a time machine for your work – you can go back.

The Pragmatic Programmer is a tool developers can use to hone their craft through proven mastery methods. The book has a 20th Anniversary edition to include best practice modern development principles.

Bridging the Communication Gap

Bridging the Communication Gap cover features a double-leaf bascule lifting bridge

Gojko Adzic

Bridging the Communication gap is about improving communication between customers, business analysts, developers, and testers on software projects. The method uses specification by example and agile acceptance testing.

When delivering a project, all stakeholders must be on the same page and speak the same language. Cross-functional teams need a shared understanding of the project and its problems. By having a shared context, teams can make better specifications and reduce miscommunication issues throughout the project.

Improved team communication leads to better software outcomes that meet customer requirements.

This book helps you:

  • Learn how to improve communication between business people and software implementation teams
  • Find out how to build a shared and consistent understanding of the domain in your team
  • Learn how to apply agile acceptance testing to produce software genuinely fit for purpose
  • Discover how agile acceptance testing affects your work whether you are a programmer, business analyst, or a tester
  • Learn how to build quality into software projects from the start rather than control it later

This book is for product owners and stakeholders wanting to improve team communication.

Peopleware

Peopleware cover features a abstract watercolor leafy plants that hint at the form of a person

Tom DeMarco, Tim Lister

With talk about how excellent technological skills, tools, and methodologies can produce great software, the authors of Peopleware suggest the most crucial part of software development is human, not technical.

If software engineering managers think they work in ‘software development’, they’re wrong. They work in the field of ‘human communication.’

Peopleware has tips on how to address the human element of software engineering, such as:

  • Loosen up formal methodologies
  • Fight corporate entropy
  • Make it acceptable to be uninterruptible

Peopleware advocates for a shift in management thinking from a technical to human focus. This shift allows managers to understand their purpose towards their team and their role in a software company. Peopleware talks about ‘management style’ as the main reason software projects fail. By managing for the long term, focusing on quality, and improving productivity through worker happiness, managers can set their teams up for ongoing success.

The Five Dysfunctions of a Team

The Five Dysfunctions of a Team cover has a bold red background and a small picture of business people standing and sitting around a table

Patrick Lencioni

The Five Dysfunctions of a Team is a leadership fable that teaches why teams struggle.

Kathryn Peterson, Decision Tech’s CEO, must unite the senior leadership team, but they’re a dysfunctional mess. Throughout the book, the five dysfunctions of a team are:

  • Absence of trust
  • Fear of conflict
  • Lack of commitment
  • Avoidance of accountability
  • Inattention to results

The book’s final section includes a framework Kathryn uses to create an effective team. This section includes practical steps you can use to identify and cut the five dysfunctions of a team.

The Five Dysfunctions of a Team applies to any team, not just a software engineering team. Team members and managers can read this to reflect on their teams and involvement.

Team Topologies

Team Topologies has a cover arranged like parts of a flow chart in many colors

Matthew Skelton, Manuel Pais

Team Topologies provides a practical, step-by-step organizational design and team interaction model. The book introduces Conway’s Law to say that the communication pathways in an organization restrict the solutions it can come up with.

The book introduces four fundamental team types:

  • Stream-aligned
  • Enabling
  • Complicated-subsystem
  • Platform

And three team interaction patterns:

  • Collaboration
  • X-as-a-service
  • Facilitation

You can build a map of how teams interact based on the team type and interaction modes. Based on the results, reteaming may be necessary to improve team functions.

The book suggests that for any team structure change, existing software will push back against new team structures. Managing the changing topology of teams in software organizations is crucial to organizational maturity.

Web Operations

Web Operations cover features a battery of barracuda in a deep turquoise and blue ocean

John Allspaw, Jesse Robbins

If you manage a web application, you need web operations to ensure it runs smoothly throughout its lifetime.

Web operations is a book that teaches the skills you need to operate your application. The book covers topics like:

  • Observability, metrics, and monitoring
  • Common database architectures
  • Dealing with scalability
  • Managing the human component of web operations
  • Handling spikes in volume
  • Disaster recovery
  • Learning from mistakes

Web operations focus on gaining skills through real-life experience. The book communicates these topics through essays and interviews involving some of the largest websites on the internet.

Practical Monitoring

Practical Monitoring cover with a block-cut illustration of a lizard

Mike Julian

Monitoring is an essential part of fitting your system with observability. Observability is the ability to assess the internal health of the system with external metrics.

Practical Monitoring gives you an approach to designing and implementing a monitoring strategy. The book is vendor-neutral. Rather than teach you how to implement tools, the book covers principles and techniques that apply to any monitoring tool.

Topics include:

  • Fix noisy alerts
  • Using statistics to improve your monitoring
  • Building a better on-call experience
  • Tie business metrics to system metrics
  • Common metrics to monitor
  • Monitoring as a culture

Practical Monitoring is ideal for operations or site reliability engineers wanting proven methods to improve monitoring.

Site Reliability Engineering

Site Reliability Engineering cover with a block-cut illustration of a lizard

Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy

Site reliability engineering (SRE) is what you get when you apply a software engineering approach to IT operations. Tasks typically done by operations teams go to engineers who use software and automation to manage production systems.

Site Reliability Engineering is a book about how Google implements SRE in production. The application of SRE allows Google to deliver high performance and reliability while maintaining rapid growth.

There are eight tenets to SRE:

  • Availability
  • Latency
  • Performance
  • Efficiency
  • Change management
  • Monitoring
  • Emergency response
  • Capacity planning

Site Reliability Engineering discusses how you can organize SRE teams to execute workloads in line with these tenets.

The book is a collection of essays and articles, with key members of Google’s SRE team explaining their commitment to the entire lifecycle. SRE enabled the success of the largest software systems in the world.

The book applies to operations or site reliability engineers responsible for the entire lifecycle of systems. You can learn from the best practices of Google’s engineers to make systems more scalable, reliable, and efficient.

The Principles of Product Development Flow

The Principles of Product Development Flow cover features a waterfall

Don Reinertsen

The Principles of Product Development Flow challenges the dominant model for managing product development. The author lists 12 problems with product development methods:

  1. Failure to correctly quantify economics
  2. Blindness to queues
  3. Worship of efficiency
  4. Hostility to variability
  5. Worship of conformance
  6. Institutionalisation of large batch sizes
  7. Underutilization of cadence
  8. Managing timelines instead of queues
  9. Absence of WiP constraints
  10. Inflexibility
  11. Noneconomic flow control
  12. Centralized control

Eight themes address the twelve problems:

  1. Economics
  2. Queues
  3. Variability
  4. Batch Size
  5. WIP Constraints
  6. Cadence, synchronisation, and flow control
  7. Fast Feedback
  8. Decentralised Control

The author discusses these problems and solutions in the context of:

  • Successful lean manufacturing systems (Toyota Product Development System)
  • Military strategy
  • Control engineering
  • Telecommunications management practices

The author explains why invisible and unmanaged queues are the underlying cause of poor product development performance. He shows why these queues form and how they undermine product development’s speed, quality, and efficiency.

Project to Product

Project to Product cover features an illustration of an airplane

Mik Kersten

In the 20th century, mass production through manufacturing changed how organizations did business. Similarly, digital transformation changed the economic landscape of the 21st century. Software is now the new means of production.

The problem is many organizations use management frameworks and infrastructure models from past technological revolutions.

Project to Product presents the solution to this problem through the flow framework. The framework connects enterprise IT and business to create an advanced manufacturing line.

Project to Product outlines how to find the business metrics you want to track per product value stream and map your IT work to those product value streams.

By connecting IT to the value stream, you can create the advanced manufacturing line that’s catapulted cutting-edge technology companies into extreme success.

Escaping the Build Trap

Escaping the Build Trap cover has a giant bear-trap ready to spring closed

Melissa Perri

The Build trap is an anti-pattern where companies focus on the outputs of a system rather than the outcomes. Companies only concerned with meeting quotas and not satisfying customers find themselves trapped. That’s because they are building without understanding the customer’s needs.

Escaping the Build Trap is about breaking free to solve real customer problems while achieving business goals. The book gives guidelines on establishing clear communication lines within the company to meet customer and business needs.

Escaping the Build Trap has five parts:

  • Why organizations ship features rather than cultivate the value those features represent
  • How to set up a product organization that scales
  • How product strategy connects a company’s vision and economic outcomes back to the product activities
  • How to identify and pursue the right opportunities for producing value through an iterative product framework
  • How to build a culture focused on successful outcomes over outputs

Managing the Design Factory

Managing the Design Factory cover has hand controlling digital technology

Don Reinertsen

Managing the Design Factory suggests thinking about design similarly to manufacturing. In the opening chapters, the author argues that there are differences between manufacturing and design, but there are similarities like:

SimilaritiesDifferences
Optimizing for profitDesign has an expensive cost of change
Input resources to create outputsDesign has less information at the start
Both inventoriesDesign has higher variability
Tasks are expandable

The book aims to take the lessons from the manufacturing factory and apply relevant lessons to the design factory.

Managing the Design Factory theorizes on how to optimize:

  • Queues
  • Flow of information
  • Feedback loops
  • Organizational structure
  • Design process
  • Product architecture
  • Product specifications
  • Tooling
  • Metrics
  • Uncertainty and Risk

The book includes practical techniques, concrete examples, and solid principles to benefit product developers.

The Lean Startup

The Lean Startup cover features a roughly painted circle design

Eric Ries

While most startups fail, The Lean Startup argues that many failures are preventable. Startups are organizations dedicated to creating something new under conditions of extreme uncertainty. To succeed, startups need to test ideas early to ensure market viability.

Many of the requirements for a startup to test their product are in lean manufacturing principles. These include:

  • Short development cycles
  • Measurement of progress with the right metrics
  • Understanding customer needs
  • Validation through experimentation

The Lean Startup is a scientific approach to applying lean principles for startup success. The book allows entrepreneurs to test their vision through a lean manufacturing lens and adapt before it’s too late.

Impact Mapping

Impact Mapping cover has an arrangement of people and tools around a trophy

Gojko Adzic

Many teams successfully design and deliver well-intentioned software projects that never make an impact. That could be because:

  • No one uses the application
  • It solves a problem no one has
  • It doesn’t align with customer or business needs

Even with proper software delivery methods, you can waste effort if you don’t understand the impact of the software. The most valuable software projects are the ones that have the highest impact.

Impact Mapping is about understanding how to map software to business outcomes. This mapping includes:

  • Goal-oriented requirements engineering
  • Frequent iterative delivery
  • Agile and lean software methods
  • Lean startup product development cycles
  • Design thinking

This book is a practical guide to impact mapping. It teaches readers how to adapt strategy over time to align with business needs.

Continuous Delivery

Continuous Delivery cover has a small image of the Forth Bridge (a cantilever railway bridge) at sunset

Jez Humble, David Farley

Continuous Delivery (CD) is a popular term in DevOps. CD describes the fast, incremental delivery of high-quality, valuable new functionality to users.

A mature CD system can deploy new changes to users in minutes compared to much longer deployment times for traditional systems.

This book outlines the practices to build a ‘deployment pipeline’ and how to automate and manage all changes. The book discusses the environment surrounding the pipeline to support continuous delivery.

Topics include:

  • Automating all parts of building, integrating, testing, and deploying software
  • Implementing deployment pipelines at a team and organizational levels
  • Improving collaboration between developers, testers, and operations
  • Developing features incrementally on large and distributed teams
  • Implementing an effective configuration management strategy
  • Automating acceptance testing, from analysis to implementation
  • Testing capacity and other non-functional requirements
  • Implementing continuous deployments and zero-downtime releases
  • Managing infrastructure, data, components, and dependencies
  • Navigating risk management, compliance, and auditing

Modern Software Engineering

Modern Software Engineering cover features a photograph of a complex circuit board

David Farley

Modern Software Engineering is by the pioneer of Continuous Delivery, David Farley. It helps software professionals think about and manage their work more effectively and improve their applications.

You can distill software engineering into two exercises:

  1. Learning and exploration
  2. Managing complexity

The book includes principles that will improve the way you code, from your mindset to quality.

Topics include:

  • Clarify what you’re trying to accomplish
  • Choose your tools based on sensible criteria
  • Organize work and systems to facilitate continuing incremental progress
  • Evaluate your progress toward thriving systems, not just more legacy code
  • Gain more value from experimentation and empiricism
  • Stay in control as systems grow more complex
  • Achieve rigor without too much rigidity
  • Learn from history and experience
  • Distinguish good new software development ideas from bad ones

Test-Driven Development

Test-Driven Development cover features a small photograph of a large cathedral with two spires

Kent Beck

Testing is an essential part of the DevOps lifecycle. Continuous Testing ensures downstream components are achieving their intended function.

Having a culture around testing can improve the quality of a software application. Test-Driven Development is about helping developers embrace testing through continuous feedback.

The author lays out two rules for Test-Driven Development:

  1. Only write new business code when an automated test fails
  2. Cut any duplication

These rules are further expanded on through the Red/Green/Refactor model. Through practical examples and valuable frameworks, Test-Driven Development is a helpful tool in a developer’s toolkit to improve as a software engineer.

Domain Driven Design

Domain Driven Design cover has a picture of Kandinsky's Composition 8 an abstract geometric artwork

Eric Evans

Software projects solve a particular problem. These projects are complex and need different stakeholders to offer their expertise, so collaboration is a must. Domain Driven Design aims to help the delivery of projects by:

  • Taking care to define the core domain of the project and the problem it solves
  • The collaboration of stakeholders in the project
  • Forming a shared understanding and language that stakeholders can use to communicate

Domain Driven Design offers readers a systematic approach to domain-driven design. It presents:

  • An extensive set of design best practices
  • Experience-based techniques
  • Fundamental principles that help the development of software projects facing complex domains

The book aims to help readers produce a domain model their teams can use to deliver complex software projects.

Topics include:

  • Getting all team members to speak the same language
  • Connecting model and implementation more deeply
  • Sharpening key distinctions in a model
  • Managing the lifecycle of a domain object
  • Writing domain code that is safe to combine in elaborate ways
  • Making complex code obvious and predictable
  • Formulating a domain vision statement
  • Distilling the core of a complex domain
  • Digging out implicit concepts needed in the model
  • Applying analysis patterns
  • Relating design patterns to the model
  • Maintaining model integrity in a large system
  • Dealing with coexisting models on the same project
  • Organizing systems with large-scale structures
  • Recognizing and responding to modeling breakthroughs

The Art of Statistics

The Art of Statistics cover has an arrangement of red and yellow dots on a blue background similar to a scatter plot chart

David Spiegelhalter

In The Art of Statistics, world-renowned statistician David Spiegelhalter explains how to get knowledge from raw data by focusing on the concepts and connections behind math.

The job of a statistician is to use and interpret data through a five-step process:

  • Problem
  • Plan
  • Data
  • Analysis
  • Conclusion

The book is a non-technical introduction to the world of statistics. It guides readers on how to manage biases and interpret data presentation.

The Art of Statistics is an excellent entry-level book for anyone who wants to interpret statistical data better.

How to Make The World Add Up

How to Make The World Add Up cover features a goldfish wearing a shark-fin disguise

Tim Harford

Numbers can make or refute an argument depending on its presentation. How can we tell the numbers to trust and those to ignore? How to Make the World Add Up is a guide on how to make sense of these numbers.

The book has ten rules for thinking differently about numbers, plus one golden rule. They are:

  1. Search your feelings
  2. Ponder your personal experience
  3. Avoid premature enumeration
  4. Step back and enjoy the view
  5. Get the backstory
  6. Ask who’s missing
  7. Demand transparency when the computer says no
  8. Don’t take statistical bedrock for granted
  9. Remember misinformation can be beautiful too
  10. Keep an open mind
  11. The golden rule: Be curious

This book allows readers to exercise correct judgment on statistics and numbers. Using case studies, the author gives historical accounts of disinformation, obfuscation, and valuable data and analysis that improved the world.

The Goal

The Goal cover features a picture of Eli Goldratt and a selection of endorsements

Eli Goldratt

The Goal is a fable about Alex Rogo, a plant manager trying to improve performance. Alex has 90 days to save his plant by improving efficiency before HQ closes it.

Alex’s initial efforts don’t go well. Fortunately, Alex bumps into Jonah, an old friend who advises him to break out of conventional thinking methods to tackle problems. Throughout the narrative, Alex learns how to improve processes in his plant through lean principles.

Lean principles helped many of the most innovative manufacturing companies make products efficiently. It’s a tale of how to apply fundamental lean principles - like value streams, flow, waste, global efficiencies, and the theory of constraints - to a real setting.

The Goal is not about software development but manufacturing, so the reader doesn’t need any IT knowledge. The Goal still has a lot of value to people in IT because many of the foundational lean principles influenced DevOps.

Theory of Constraints

Theory of Constraints cover features a picture of Eli Goldratt and bullet lists summarizing the contents

Eli Goldratt

The Theory of Constraints is the idea that every system has a limiting factor or constraint. Focusing efforts to address the constraint is usually the quickest and most effective way to improve profitability.

The Theory of Constraints introduces the stages of a continuous program:

  • The five steps of focusing
  • The process of change
  • How to prove effect-cause-effect
  • How to invent simple solutions to complex problems

The Theory of Constraints is like the weakest link chain analogy. In a chain, there will only ever be one weakest link. Strengthening any other link beside the weakest will not improve the overall strength of the chain.

This book guides readers in finding and addressing the most limiting constraints in their system and offers practical steps to get started.

Post-recommendation

We hope you enjoyed the recommendation tool and found a book you like.

Books are subjective, and our tool offers suggestions on what you might find helpful. Some are narrative-driven stories, whereas others are textbooks. Everyone has different learning styles, and some formats may suit you better than others.

The technology scene is constantly changing and evolving. Books go out of date, and new methods replace old ones. We’ll track book releases and trends to update this tool with the latest recommendations.

From here, you can:

Categories:

Next article
DevOps glossary