The Thinking Techniques of a Highly Effective Engineer
 |
Description
Book Introduction
This book teaches AI the fast and accurate problem-solving skills and thinking methods that allow human developers and engineers to maximize their abilities, something that is difficult to replicate easily!
"Engineering thinking skills" to quickly and accurately solve immediate problems by closely observing the "essence of the problem" and improving and optimizing the "performance" of systems and solutions.
--
If your system slows down, serious problems arise.
Because it wastes time and money.
It could even lead to project halts or career jeopardy.
But if you understand what's going on, it's surprisingly easy to make consistently good decisions about performance.
This book provides a clear and thoughtful explanation of why the system behaves the way it does.
With over 30 years of experience in the field, author Carey Millsap uses engaging storytelling techniques to teach you optimization skills that can improve the performance of (literally) any system, whether it's computer software or everyday tasks, through 111 anecdotes.
It also provides an entertaining look at what kind of thinking and mindset engineers and developers should have, and how they can perform more consistent and confident optimizations.
This book is for anyone who wants to understand how computer programs and processes are using their time and what they can do to improve it.
"Engineering thinking skills" to quickly and accurately solve immediate problems by closely observing the "essence of the problem" and improving and optimizing the "performance" of systems and solutions.
--
If your system slows down, serious problems arise.
Because it wastes time and money.
It could even lead to project halts or career jeopardy.
But if you understand what's going on, it's surprisingly easy to make consistently good decisions about performance.
This book provides a clear and thoughtful explanation of why the system behaves the way it does.
With over 30 years of experience in the field, author Carey Millsap uses engaging storytelling techniques to teach you optimization skills that can improve the performance of (literally) any system, whether it's computer software or everyday tasks, through 111 anecdotes.
It also provides an entertaining look at what kind of thinking and mindset engineers and developers should have, and how they can perform more consistent and confident optimizations.
This book is for anyone who wants to understand how computer programs and processes are using their time and what they can do to improve it.
- You can preview some of the book's contents.
Preview
index
Chapter 1: Observation
#001 Team Leader Bob
#002 Phillies' Test
#003 Real Goal
#004 Nancy's Narrow Cubicle Desk
#005 Observing the right point
#006 If the situation cannot be observed
Chapter 2 Methodology
#007 49 Grievances
#008 Shipping invoice printing problem
#009 More Troubles
#010 Priority
#011 The whole system is just slow
#012 Side Benefits
#013 Expectations for Silver Bullets
#014 List of symptoms
#015 R Methodology
Chapter 3 Profiling
#016 Payslip
#017 Sequence Diagram
#018 Gantt Chart
#019 Tracking application behavior
#020 Profile
#021 Creating a profile
Chapter 4: Measuring Performance
#022 Performance is also a function
#023 Reproducible test cases
#024 Intermittent problem
#025 How much data should you track?
#026 Confirmation of Experience
#027 Measurement Intrusion
Chapter 5 Optimization
#028 Riddle
#029 Game
#030 Event Count
#031 Event execution time
#032 Filtering as quickly as possible
#033 Look to the left
#034 Toe-Millsap's Law
#035 Bottleneck
#036 Understanding 'System Bottlenecks'
#037 The Problem of Subsystem Optimization
#038 All problems are distortion problems.
#039 Main execution path
Chapter 6 Delay
#040 Kevin
#041 Waiting delay
#042 Queue Theory
#043 Hyperbola
#044 Traffic intensity
#045 Market share
#046 Hyperbolic effect
#047 Consistency Delay
#048 Delay and Throughput
Chapter 7 Waste
#049 Consultant Debra
#050 Lamp problem
#051 Accounting Expert Martha
#052 Efficiency
#053 Fix the problem or add resources?
#054 The legendary Yeti
#055 Speed vs. Efficiency
#056 Scalability
Chapter 8 Problem Solving
#057 Four Simple Questions
#058 Look through the data to the end
#059 Executive Feedback Loop
#060 Collateral Damage
#061 Too much of something is as bad as too little
#062 IT Head Doug
#063 What is completion?
Chapter 9 Prediction
#064 Enterprise Architect Richard
#065 Why Forecasting Is Necessary
#066 Prediction through profile
#067 Prediction on whether to do it or not
#068 Linear motion
#069 Distortion
#070 Interdependence between events
#071 Nonlinear behavior
Chapter 10 Hide Wait Time
#072 Mom's Super-Short Cooking Tips
#073 Dominic
#074 Parallelization
#075 System Melting Game
#076 Multitasking
#077 Human Multitasking
Chapter 11 Logical Fallacies
#078 Evil Lamp Genie
#079 Leather Jacket
#080 Buried Outliers
#081 Be careful when making requests
#082 Percentile Specification
#083 Hit rate problem
#084 Fuel economy issue
#085 The problem of proportions
#086 What about throughput and response time?
#087 Are ratios useless?
#088 If you can trust the ratio
#089 Explaining improved performance
#090 The myth of 'n times faster'
Chapter 12 Testing
#091 Why Testing Is Necessary
#092 Danger
#093 Destructive Testing
#094 Testing is not just a step
#095 Automated Testing
#096 Preventing Problems
Chapter 13 Plan
#097 Teacher Yutley
#098 Capacity Planning
#099 Usage Goal
#100 When is a hardware upgrade necessary?
Chapter 14 Political Views
#101 Proof
#102 The Problem with Promising Less
#103 7 Ways to Identify Project Risks
#104 Fail Fast
#105 Face
#106 Jeweler's Sales Strategy
#107 Change Management
#108 Leave a record
#109 Failure
#110 Be nervous, but don't worry.
Chapter 15 For fun
#111 Optimizing the Little Ones
#001 Team Leader Bob
#002 Phillies' Test
#003 Real Goal
#004 Nancy's Narrow Cubicle Desk
#005 Observing the right point
#006 If the situation cannot be observed
Chapter 2 Methodology
#007 49 Grievances
#008 Shipping invoice printing problem
#009 More Troubles
#010 Priority
#011 The whole system is just slow
#012 Side Benefits
#013 Expectations for Silver Bullets
#014 List of symptoms
#015 R Methodology
Chapter 3 Profiling
#016 Payslip
#017 Sequence Diagram
#018 Gantt Chart
#019 Tracking application behavior
#020 Profile
#021 Creating a profile
Chapter 4: Measuring Performance
#022 Performance is also a function
#023 Reproducible test cases
#024 Intermittent problem
#025 How much data should you track?
#026 Confirmation of Experience
#027 Measurement Intrusion
Chapter 5 Optimization
#028 Riddle
#029 Game
#030 Event Count
#031 Event execution time
#032 Filtering as quickly as possible
#033 Look to the left
#034 Toe-Millsap's Law
#035 Bottleneck
#036 Understanding 'System Bottlenecks'
#037 The Problem of Subsystem Optimization
#038 All problems are distortion problems.
#039 Main execution path
Chapter 6 Delay
#040 Kevin
#041 Waiting delay
#042 Queue Theory
#043 Hyperbola
#044 Traffic intensity
#045 Market share
#046 Hyperbolic effect
#047 Consistency Delay
#048 Delay and Throughput
Chapter 7 Waste
#049 Consultant Debra
#050 Lamp problem
#051 Accounting Expert Martha
#052 Efficiency
#053 Fix the problem or add resources?
#054 The legendary Yeti
#055 Speed vs. Efficiency
#056 Scalability
Chapter 8 Problem Solving
#057 Four Simple Questions
#058 Look through the data to the end
#059 Executive Feedback Loop
#060 Collateral Damage
#061 Too much of something is as bad as too little
#062 IT Head Doug
#063 What is completion?
Chapter 9 Prediction
#064 Enterprise Architect Richard
#065 Why Forecasting Is Necessary
#066 Prediction through profile
#067 Prediction on whether to do it or not
#068 Linear motion
#069 Distortion
#070 Interdependence between events
#071 Nonlinear behavior
Chapter 10 Hide Wait Time
#072 Mom's Super-Short Cooking Tips
#073 Dominic
#074 Parallelization
#075 System Melting Game
#076 Multitasking
#077 Human Multitasking
Chapter 11 Logical Fallacies
#078 Evil Lamp Genie
#079 Leather Jacket
#080 Buried Outliers
#081 Be careful when making requests
#082 Percentile Specification
#083 Hit rate problem
#084 Fuel economy issue
#085 The problem of proportions
#086 What about throughput and response time?
#087 Are ratios useless?
#088 If you can trust the ratio
#089 Explaining improved performance
#090 The myth of 'n times faster'
Chapter 12 Testing
#091 Why Testing Is Necessary
#092 Danger
#093 Destructive Testing
#094 Testing is not just a step
#095 Automated Testing
#096 Preventing Problems
Chapter 13 Plan
#097 Teacher Yutley
#098 Capacity Planning
#099 Usage Goal
#100 When is a hardware upgrade necessary?
Chapter 14 Political Views
#101 Proof
#102 The Problem with Promising Less
#103 7 Ways to Identify Project Risks
#104 Fail Fast
#105 Face
#106 Jeweler's Sales Strategy
#107 Change Management
#108 Leave a record
#109 Failure
#110 Be nervous, but don't worry.
Chapter 15 For fun
#111 Optimizing the Little Ones
Detailed image
Into the book
“Optimization is often more political than technical.
So, one wonders why books on optimization almost always deal only with the technical aspects.”
--- p.29
““I don’t know.
But let's say, "I can help you solve the problem."
That's when leadership comes into play."
--- p.48
“But the real performance problem wasn’t in the server room or the network cables.
The answer lay on Nancy's desk in her cramped cubicle, just three kilometers away.
“We were looking at the problem in the server room, but we were looking at the wrong part of the problem.”
--- p.49
“What is the moral of this story? Go to where the symptoms are manifesting and observe them.
“We need to observe actual symptoms, not secondary phenomena, and actual events, not easily measurable surrogate indicators.”
--- p.59
“We need to look at the problem from the perspective of the actual individuals who are suffering because their work is not being done, not through system administration tools.”
--- p.62
“If you need information to determine your advantage, let’s analyze the superficial symptoms first before delving deeper into symptoms that have the same priority.
“This will help us figure out which symptoms can be relieved most quickly.”
--- p.64
“One of the main reasons you’re suited to this job is your curiosity.”
--- p.70
“Performance-related metrics are easy to measure and improve, so observability is paramount to maintaining good performance.”
--- p.99
“When you discover a problem, the best way to get help from others is to provide a reproducible test case that includes the following information:
--- p.102
“The trade-offs of tracking are rarely as bad as people fear.
“Well-designed tracking features are rich yet lightweight.”
--- p.113
“It's easier, cheaper, and much more efficient to have programs return less data than to have them return data people don't want more quickly.”
--- p.137
You may have heard that improving performance ultimately comes down to removing bottlenecks.
In fact, the word bottleneck itself is a metaphor.
“The amount of liquid that can be drawn from a bottle in a given time depends not on the size or capacity of the bottle, but on the size of the small hole at the end of the bottle.”
--- p.138
“The largest portion of response time is the bottleneck in program execution.”
--- p.138
“Thanks to my explanation, I was able to successfully complete the most difficult part of this project: listening, calming, and persuading.”
--- p.187
“Progress in problem solving comes from learning more about what is happening.
That means we need to read, ask questions, collect more data, and experiment with various things.” --- p.210
“Doug left after thanking us for our hard work.
When the decision maker was in the room, the decision was actually easy, and Doug had the authority to make it.
"Why didn't you contact Doug earlier, at 5 o'clock, instead of 7 o'clock? Let's get the feedback loop going as quickly as possible."
--- pp.219-220
“It is the system administrator's responsibility to manage the system so that people do not misuse parallelism.
As the saying goes, “too much of a good thing is as bad as too little.”
--- p.261
“In other words, if a person tries to do more than one thing at a time, he or she may end up becoming a fool, not to mention physically exhausted.
If you want to achieve high performance on your own, stop multitasking.
“That’s the computer’s job.”
--- p.266
“When optimizing, think carefully about what you really want.
Let's list the attributes of experiences that really interest you.
And let's find the trade-off point that produces the best results.”
--- p.293
Why do we need testing? It allows us to see how quickly each function of an application executes on a busy, large-scale system.
While actually writing the function, you can find out where the system's weaknesses are through testing.
“Planning cannot replace testing.”
--- p.303
“Fixing defects late in a project costs much more than fixing them early on.”
--- p.310
“There’s no way you’ll find a key you dropped in the drain in a flower pot.”
--- p.330
“Decentralized authority models can also make progress more easily if you can get the power you need.
The important thing is to get the necessary authority.”
--- p.338
“So when I say that I hope you fail quickly, I mean it as a blessing, not a curse.”
--- p.342
“My colleague Anjo Kolk said that 90% of performance problems are political and only 10% are technical.
You have to realize that fixing something can create the impression that someone else has messed it up.”
--- p.344
“Honesty requires responsibility.
Effective honesty is not simply spewing out every thought that comes to mind, but speaking the truth after carefully assessing what the facts are.”
--- p.345
“Most failures are cases where our team knew exactly what to do, but ultimately failed to convince the client.
“Convincing people to do what needs to be done is the hardest part of any project.”
--- p.355
“Don’t be afraid of stressful situations.
Let's accept that our bodies are giving us more strength and focus to face meaningful moments.”
So, one wonders why books on optimization almost always deal only with the technical aspects.”
--- p.29
““I don’t know.
But let's say, "I can help you solve the problem."
That's when leadership comes into play."
--- p.48
“But the real performance problem wasn’t in the server room or the network cables.
The answer lay on Nancy's desk in her cramped cubicle, just three kilometers away.
“We were looking at the problem in the server room, but we were looking at the wrong part of the problem.”
--- p.49
“What is the moral of this story? Go to where the symptoms are manifesting and observe them.
“We need to observe actual symptoms, not secondary phenomena, and actual events, not easily measurable surrogate indicators.”
--- p.59
“We need to look at the problem from the perspective of the actual individuals who are suffering because their work is not being done, not through system administration tools.”
--- p.62
“If you need information to determine your advantage, let’s analyze the superficial symptoms first before delving deeper into symptoms that have the same priority.
“This will help us figure out which symptoms can be relieved most quickly.”
--- p.64
“One of the main reasons you’re suited to this job is your curiosity.”
--- p.70
“Performance-related metrics are easy to measure and improve, so observability is paramount to maintaining good performance.”
--- p.99
“When you discover a problem, the best way to get help from others is to provide a reproducible test case that includes the following information:
--- p.102
“The trade-offs of tracking are rarely as bad as people fear.
“Well-designed tracking features are rich yet lightweight.”
--- p.113
“It's easier, cheaper, and much more efficient to have programs return less data than to have them return data people don't want more quickly.”
--- p.137
You may have heard that improving performance ultimately comes down to removing bottlenecks.
In fact, the word bottleneck itself is a metaphor.
“The amount of liquid that can be drawn from a bottle in a given time depends not on the size or capacity of the bottle, but on the size of the small hole at the end of the bottle.”
--- p.138
“The largest portion of response time is the bottleneck in program execution.”
--- p.138
“Thanks to my explanation, I was able to successfully complete the most difficult part of this project: listening, calming, and persuading.”
--- p.187
“Progress in problem solving comes from learning more about what is happening.
That means we need to read, ask questions, collect more data, and experiment with various things.” --- p.210
“Doug left after thanking us for our hard work.
When the decision maker was in the room, the decision was actually easy, and Doug had the authority to make it.
"Why didn't you contact Doug earlier, at 5 o'clock, instead of 7 o'clock? Let's get the feedback loop going as quickly as possible."
--- pp.219-220
“It is the system administrator's responsibility to manage the system so that people do not misuse parallelism.
As the saying goes, “too much of a good thing is as bad as too little.”
--- p.261
“In other words, if a person tries to do more than one thing at a time, he or she may end up becoming a fool, not to mention physically exhausted.
If you want to achieve high performance on your own, stop multitasking.
“That’s the computer’s job.”
--- p.266
“When optimizing, think carefully about what you really want.
Let's list the attributes of experiences that really interest you.
And let's find the trade-off point that produces the best results.”
--- p.293
Why do we need testing? It allows us to see how quickly each function of an application executes on a busy, large-scale system.
While actually writing the function, you can find out where the system's weaknesses are through testing.
“Planning cannot replace testing.”
--- p.303
“Fixing defects late in a project costs much more than fixing them early on.”
--- p.310
“There’s no way you’ll find a key you dropped in the drain in a flower pot.”
--- p.330
“Decentralized authority models can also make progress more easily if you can get the power you need.
The important thing is to get the necessary authority.”
--- p.338
“So when I say that I hope you fail quickly, I mean it as a blessing, not a curse.”
--- p.342
“My colleague Anjo Kolk said that 90% of performance problems are political and only 10% are technical.
You have to realize that fixing something can create the impression that someone else has messed it up.”
--- p.344
“Honesty requires responsibility.
Effective honesty is not simply spewing out every thought that comes to mind, but speaking the truth after carefully assessing what the facts are.”
--- p.345
“Most failures are cases where our team knew exactly what to do, but ultimately failed to convince the client.
“Convincing people to do what needs to be done is the hardest part of any project.”
--- p.355
“Don’t be afraid of stressful situations.
Let's accept that our bodies are giving us more strength and focus to face meaningful moments.”
--- p.359
Publisher's Review
[Opening remarks]
The book was published at a very opportune time.
Author Carey has been teaching and practicing the topics covered in this book for a full quarter of a century.
I've read this book several times already, and I'm sure you'll enjoy it too.
This is a book that might change your life.
Because my life has also been changed by the principles explained in this book.
I already benefited from Carrie 18 years ago.
This is because the essence of this book is the same as that of Optimizing Oracle Performance, which Carey co-authored with Jeff Hold in 2003.
Its essence is 'R Method R'.
R methodology changed my life and became the foundation of my career.
Before I learned the R methodology, I just studied and applied the 'universal' tips, tricks, tools, and techniques that a database administrator should know.
Of course, there were times when it was successful, but the results were generally inconsistent, and everything felt complicated and difficult.
The R methodology has almost completely changed the way I think about optimization.
Then everything became clear and simple.
It wasn't just about the oracle.
Learning the R methodology gave me a clearer picture of what information I needed to collect about everything I needed to improve.
I was able to figure out where to find the root cause of performance issues and how to fix them.
But what I especially enjoyed was being able to explain to others my approach and why I do it that way.
The sense of accomplishment was especially great.
This was possible because the cause of the problem and the method of improvement could be clearly identified through the R methodology rather than simply estimated.
Indeed, while many have glimpsed the potential for applying R methodology beyond Oracle, Carey's 2003 book was simply about Oracle.
But this book is different.
This book is about 'people' who have to make decisions.
This book is not simply for Oracle professionals or IT professionals who run long-running batch jobs.
This book is for anyone who has to prepare meals or take the kids to exercise class.
In other words, this book is for anyone who wants to make something faster, better, and more elegant.
This principle applies equally to everything.
When I first started using R methodology, I thought, “Can it really be this simple?”
The answer is clearly “yes!”
This book is also easy to read.
Carrie is a brilliant technical expert and a brilliant storyteller.
Carrie is one of the best presenters you'll ever meet (whether technical or not), and that talent is evident in this book.
Watching Carrie tackle a difficult topic that has held many back in a relaxed tone is both satisfying and refreshing.
The anecdotes Carrie shares are relatable to almost everyone, whether in IT or not.
As you read this book, I believe you will encounter anecdotes that will make you think, “Yes, I have faced this situation too.”
The anecdotes Carrie shares in this book are not only entertaining, but the insights you gain from them will transform you.
In this book, you will discover that the simple act of observing a situation correctly can make a world-changing difference.
You will learn how to confidently and consistently identify, verify, scope, analyze, and resolve performance issues.
You will also learn how to transform your colleagues' emotions into positive energy.
Better testing will also help you learn how to 'work around' problems rather than encountering them.
You will also learn how to find solid evidence to determine whether further improvement is possible, and ultimately understand it.
If you want, you can think of this book as a textbook.
It is also a book that you can take out and read whenever you need to.
I firmly believe that this book will help countless people like you make a positive impact on the world.
- Gudmundur Josefsson / Performance expert and director at Inaris
[Author's Note]
Making something faster means making it better.
Life gets better too.
This book is about how to make something better.
This book will help you live a better life.
The faster your tools work, the more time you have to do what you want.
If you use tools to process information, the faster you can make those tools work, the better your decisions will be.
Optimization (whether it's a computer, a plow, or anything else) requires two skills:
First, ask the right questions, and second, of course, find answers to those questions.
Most people who think about optimization have a good understanding of the second skill.
But it seems that fewer people understand the first skill.
This first skill? Asking the right questions? This is the skill you need to develop first.
This is especially true if you are a leader.
You might be surprised at how quickly you can learn this skill.
There is one problem here.
Teaching how to ask questions properly is a simple process in itself.
But for anyone who hasn't raised a young child who constantly asks such simple questions, answering the question might not be easy.
For example, the people who manage all the computers in a company might know exactly what the system's CPU utilization was at 2 p.m. on a Friday, but they wouldn't be able to answer questions about how long it would take an employee to enter an order.
There is a gap between the answers they want to give and the questions you want to ask.
Because of this gap, we don't see opportunities to do something quickly.
I want to teach you how to find these opportunities.
Optimization is often more political than technical.
So, one wonders why books on optimization almost always cover only the technical aspects.
This is because technical professionals often consider non-technical elements of a project to be unnecessary or absurd distractions.
But the truth is, the non-technical aspects of optimization require just as much understanding and effort as the technical aspects.
Optimizing something requires not only being technically productive, but sometimes also facing the monsters created by anxiety and fear.
Having enough success stories would help win the debate about what to do next, but you'll never create those without some political savvy.
Through this book, I hope to help you improve both your political and technical questioning and answering skills.
The potential rewards are enormous.
If you understand both the technical aspects of performance and how to observe the needs and emotions of people who care about performance, you can optimize anything.
[Translator's Note]
I remember when the publisher first asked me to review the original book, How to Make Things Faster, I started reading it, thinking it would be a boring technical book on performance tuning at best, but I ended up reading through Chapter 3 in one sitting.
This book isn't simply about "how to make something work faster," but rather how to figure out what the problem is, where to look, and what data might provide real clues to solving it.
The author demonstrates the essence of problem solving through a whopping 111 real-life examples.
In the process, we encounter the common mistake that engineers make: focusing only on the symptom of “slowness” and looking for the cause in the wrong place.
What struck me most while translating this book was how the story of performance improvement led to a shift in thinking and training in observation.
'Solving a problem correctly' ultimately comes down to deciding what to observe and what to ignore.
And only after reading this book did I understand how so many engineers make bad decisions along the way, and how to think differently to make good decisions.
I hope this book will be of great help to engineers in their daily problem-solving process.
I would like to take this opportunity to express my gratitude to Bookman Publishing and my loving family for always giving me the opportunity to translate such great books.
- Jang Hyun-hee
The book was published at a very opportune time.
Author Carey has been teaching and practicing the topics covered in this book for a full quarter of a century.
I've read this book several times already, and I'm sure you'll enjoy it too.
This is a book that might change your life.
Because my life has also been changed by the principles explained in this book.
I already benefited from Carrie 18 years ago.
This is because the essence of this book is the same as that of Optimizing Oracle Performance, which Carey co-authored with Jeff Hold in 2003.
Its essence is 'R Method R'.
R methodology changed my life and became the foundation of my career.
Before I learned the R methodology, I just studied and applied the 'universal' tips, tricks, tools, and techniques that a database administrator should know.
Of course, there were times when it was successful, but the results were generally inconsistent, and everything felt complicated and difficult.
The R methodology has almost completely changed the way I think about optimization.
Then everything became clear and simple.
It wasn't just about the oracle.
Learning the R methodology gave me a clearer picture of what information I needed to collect about everything I needed to improve.
I was able to figure out where to find the root cause of performance issues and how to fix them.
But what I especially enjoyed was being able to explain to others my approach and why I do it that way.
The sense of accomplishment was especially great.
This was possible because the cause of the problem and the method of improvement could be clearly identified through the R methodology rather than simply estimated.
Indeed, while many have glimpsed the potential for applying R methodology beyond Oracle, Carey's 2003 book was simply about Oracle.
But this book is different.
This book is about 'people' who have to make decisions.
This book is not simply for Oracle professionals or IT professionals who run long-running batch jobs.
This book is for anyone who has to prepare meals or take the kids to exercise class.
In other words, this book is for anyone who wants to make something faster, better, and more elegant.
This principle applies equally to everything.
When I first started using R methodology, I thought, “Can it really be this simple?”
The answer is clearly “yes!”
This book is also easy to read.
Carrie is a brilliant technical expert and a brilliant storyteller.
Carrie is one of the best presenters you'll ever meet (whether technical or not), and that talent is evident in this book.
Watching Carrie tackle a difficult topic that has held many back in a relaxed tone is both satisfying and refreshing.
The anecdotes Carrie shares are relatable to almost everyone, whether in IT or not.
As you read this book, I believe you will encounter anecdotes that will make you think, “Yes, I have faced this situation too.”
The anecdotes Carrie shares in this book are not only entertaining, but the insights you gain from them will transform you.
In this book, you will discover that the simple act of observing a situation correctly can make a world-changing difference.
You will learn how to confidently and consistently identify, verify, scope, analyze, and resolve performance issues.
You will also learn how to transform your colleagues' emotions into positive energy.
Better testing will also help you learn how to 'work around' problems rather than encountering them.
You will also learn how to find solid evidence to determine whether further improvement is possible, and ultimately understand it.
If you want, you can think of this book as a textbook.
It is also a book that you can take out and read whenever you need to.
I firmly believe that this book will help countless people like you make a positive impact on the world.
- Gudmundur Josefsson / Performance expert and director at Inaris
[Author's Note]
Making something faster means making it better.
Life gets better too.
This book is about how to make something better.
This book will help you live a better life.
The faster your tools work, the more time you have to do what you want.
If you use tools to process information, the faster you can make those tools work, the better your decisions will be.
Optimization (whether it's a computer, a plow, or anything else) requires two skills:
First, ask the right questions, and second, of course, find answers to those questions.
Most people who think about optimization have a good understanding of the second skill.
But it seems that fewer people understand the first skill.
This first skill? Asking the right questions? This is the skill you need to develop first.
This is especially true if you are a leader.
You might be surprised at how quickly you can learn this skill.
There is one problem here.
Teaching how to ask questions properly is a simple process in itself.
But for anyone who hasn't raised a young child who constantly asks such simple questions, answering the question might not be easy.
For example, the people who manage all the computers in a company might know exactly what the system's CPU utilization was at 2 p.m. on a Friday, but they wouldn't be able to answer questions about how long it would take an employee to enter an order.
There is a gap between the answers they want to give and the questions you want to ask.
Because of this gap, we don't see opportunities to do something quickly.
I want to teach you how to find these opportunities.
Optimization is often more political than technical.
So, one wonders why books on optimization almost always cover only the technical aspects.
This is because technical professionals often consider non-technical elements of a project to be unnecessary or absurd distractions.
But the truth is, the non-technical aspects of optimization require just as much understanding and effort as the technical aspects.
Optimizing something requires not only being technically productive, but sometimes also facing the monsters created by anxiety and fear.
Having enough success stories would help win the debate about what to do next, but you'll never create those without some political savvy.
Through this book, I hope to help you improve both your political and technical questioning and answering skills.
The potential rewards are enormous.
If you understand both the technical aspects of performance and how to observe the needs and emotions of people who care about performance, you can optimize anything.
[Translator's Note]
I remember when the publisher first asked me to review the original book, How to Make Things Faster, I started reading it, thinking it would be a boring technical book on performance tuning at best, but I ended up reading through Chapter 3 in one sitting.
This book isn't simply about "how to make something work faster," but rather how to figure out what the problem is, where to look, and what data might provide real clues to solving it.
The author demonstrates the essence of problem solving through a whopping 111 real-life examples.
In the process, we encounter the common mistake that engineers make: focusing only on the symptom of “slowness” and looking for the cause in the wrong place.
What struck me most while translating this book was how the story of performance improvement led to a shift in thinking and training in observation.
'Solving a problem correctly' ultimately comes down to deciding what to observe and what to ignore.
And only after reading this book did I understand how so many engineers make bad decisions along the way, and how to think differently to make good decisions.
I hope this book will be of great help to engineers in their daily problem-solving process.
I would like to take this opportunity to express my gratitude to Bookman Publishing and my loving family for always giving me the opportunity to translate such great books.
- Jang Hyun-hee
GOODS SPECIFICS
- Date of issue: November 28, 2025
- Page count, weight, size: 384 pages | 560g | 152*224*20mm
- ISBN13: 9791189909970
- ISBN10: 1189909979
You may also like
카테고리
korean
korean
![ELLE 엘르 스페셜 에디션 A형 : 12월 [2025]](http://librairie.coreenne.fr/cdn/shop/files/b8e27a3de6c9538896439686c6b0e8fb.jpg?v=1766436872&width=3840)
