by Guru Madhavan.
As a product manager, I’m always interested in learning new mental models, improve my thinking process, and be better at problem-solving skills.
Therefore, I bought the book Think like an Engineer: by Guru Madhavan, my expectations were high because one the best books I’ve read around the subject is Algorithms to Live By: The Computer Science of Human Decisions by Brian Christian & Tom Griffin.
The purpose of the post is to give you the main key points, summarized them, and help you decide if you should buy the book.
The key points around the book are:
- Modular Thinking: How do engineers manage big problems and convert them into small and simple solutions.
- Constraints: In launching a product is there a big gap between the reality and the idea? How can you foresee the restrictions and challenges?;
- Trade-Offs: Now that you understand the constraints, what are going to be the trade-offs? Design vs utility? Practical vs aesthetics.
- Prototyping & Feedback: There’s no value in the product if it doesn’t solve any user need. How would you prototype something fast enough to get customer feedback, and then iterate gain? The writer gives some stories on this subject.
The writer gives some stories on the above subject.
General Review of the Book
If you set the correct expectation for the book, book is good. The author writes with excellent pacing, direct to the point, the engineer’s stories around the history of engineering are pretty impressive as general culture.
The caveat is that the book is not about how to think like an engineer, but engineering concepts co-related with stories of engineers, history of engineering, and how engineering has made drastic changes in our society.
Guru writes exceptionally well and with excellent clarity, but it doesn't fulfill the promise of the title.
Therefore, here you have my book notes.
2 Invisible Brides & Mixing and Matching.
Nothing is stationary and everything is linked.
According to the book author, the engineering mind has three properties, all based on modular thinking. First, let’s talk about modular reasoning.
As a note, the author uses Modular Systems Thinking as the whole framework, but I believe it should be split, let me elaborate. Modular Systems Thinking is a useful framework that pushes you from systematic thinking to modular thinking.
Thinking in systems means that you can deconstruct a problem into modules, and then reconstruct, in other words putting everything back together.
This will allow you to understand the challenges “per module” and making it easier to solve the bigger problem.
I believe thinking in systems is more of a linear, top-down approach, or bottom-up approach, but Modular thinking is the next step after the systematic thinking; now that you have the modules, how are they link to the real world? In other words with the actual user.
How can you recycle such “modules” for optimizing any other side of the business or product?
Is there any cannibalization around the problem, product, or feature you are trying to tackle?
To illustrate this I'll use two analogies:
For Product Managers: Epics to user stories to acceptance criteria are the equal of systematic thinking.
From an architecture perspective, an excellent visual example here would be a monolithic architecture(An application that all the components are combined in a single program and platform) as the systemic thinking, to modular thinking which would be more of a microservices architecture.
Three Properties of Thinking as an Engineer
1. The ability to see structure where there's nothing apparent.
To have a structure involves considering all the elements of the systems that are linked in logic, time, sequence and function .
The author offers great questions to establish a structure for a solving a problem.
- What are you trying to do? Articulate your objectives using absolutely no jargon.
- How is it done today, and what are the limits of current practice?
- What's new in your approach and why do you think it will be successful?
- Who cares? If you're successful, what difference will it make?
- What are the risks and the payoffs?
- How much will it cost? How long will it take?
- What are the midterm and final “exams” to check for success?
2. Designing under constraints
Just as chefs can taste the flavors, combine them, and knowing what, when and how to mix them with even a bite of food.
That’s how an engineer works with constraints, she understands that :
Any real-world scenario has constraints that make or break our performance potential.
An interesting statement by Guru was the following:
i) engineers are expected to produce the best possible results under the given conditions, and ii) time constraints, a deadline for example on engineers will fuel creativity and resourcefulness, just as financial constraints.
I love both statements, but I believe that is a human nature, a great designer, or a great architect would be expected to produce the best possible results under the given conditions, being time, or financial constraints.
This is a by-product of the constraints, a great engineer should understand the quid pro quos in relation to the solution and it's alternatives.
The design priorities and resource allocation will depend on the modular thinking + constraints to understand what will be sacrificed on solving the problem.
Examples could be: Technical debt aesthetics vs utility, reducing costs for weight or dimensions, money, deadline, etc.
My last notes & quotes are the following:
Science, philosophy, and religion may well be in the business of pursuing truth as it looks to them but engineering is at the center of producing utility under constraints.
If the core of science is discovery, then the essence of engineering is creation.
Knowledge for the sake of knowledge has its role but practical reality shapes social progress.
A technology is effective only if it enhances the user’s value and experience.
It’s really about shadowing the people because ultimately for anything to be successful, it has to be user-centered.”
Hopefully, this will give you an insight of the book, I think there's a lot to learn, and if you go with the expectation of understanding different engineering anecdotes, and engineering concepts this book is great.
You can get it here.