Engineering Reads
Sep 27, 2019 · 1020 words · 5 minutes read
A list of good reads I believe every Engineer should read through in striving to be a better Engineer. Will likely organize these better down the line.
Image courtesy of Patrick Tomasso
Books
Apollo
How to do a bunch of “ambitious” things with lots of talented folks and quickly at that! Here’s a fantastic video presentation on the Apollo Guidance Computer(AGC). Some fun facts:
- AGC didn’t have room for code to enforce invariants
- AGC first human interactive interface
- AGC first priority scheduler
My favourite titbits: Engineers reported to engineers, metrics deck/project deck used to coordinate decentralized organization.
Failure is not an Option
How to hold all of those talented folks accountable while keeping an especially daring few of them “safe.”
“Mission Controllers” were not chosen and then made meticulous; they were chosen because they were already meticulous. So the controller job role takes the “Bias for Action” principle and draws out its timeline from the near-term, get something – anything – done and turns that timeline into an anticipation and measurement of possible outcomes of action. The incredible volume of anticipation and procedures for dealing with problems is its own bias for action, but one we are usually too near-term focused to see.
Kranz famously said that if you don’t know what you’re doing, you shouldn’t do anything. The reason is simple: the law of unintended consequences coupled with Mr. Murphy’s law means you’re more likely to make a bad situation worse than make it better, so it’s best to do the right thing in response, not just any thing. He learned this lesson, he claimed, with a Redstone booster full of kerosene/LOX sitting on the launch pad after a four-inch flight; the correct thing to do ended up being exactly nothing (waiting for the batteries to run down and vent off the LOX when the failsafe vents opened as a result).
Complications
Why/How to guard against very talented people being temporarily or occasionally less-than-talented.
The Mission Controllers of the space program represented that authority holding everyone accountable. Namely, they used the mechanism of testing Mission Rules (error scenarios) and tracking to the goal (keeping the astronauts alive and on- mission). Then when the missions were underway, they have the “boring” job of reading up the checklists and cross-referencing the astronauts’ work.
However, it has been pointed out to me that the Mission Controllers were not chosen and then made conscientious; rather they were conscientious first and made Mission Controllers later.
Fooled by Randomness, Anti-Fragile
Stop falling into the traps of humans attempting analytical thought.
Start identifying risks and inure yourself/system to them.
Any view of reality is a simplification of some underlying system and that system is likely to be complex if it is all interesting. The underpinnings of that system are actually unknown and unknowable and are guaranteed to produce a “black swan” from time to time. Software systems undergoing constant change are create example of a system where any model is going to be somewhat wrong.
Perturbations of complex systems will produce results that were not anticipated by any models (“law” of unintended consequences); changing behaviour in such a system needs to be heavily monitored.
Mythical Man Month
Stop falling into the ubiquitous mental traps of humans attempting software development. * More people almost always make a project take longer. - Adding them at the beginning is the only safe time to add them. * The most expensive time to add people is at the end of a project. * The most expensive time to find a bug is at the end of a project milestone. - Debugging is an inherently serial task: more people never makes it go faster. * Sunk Cost Fallacy: when comparing future costs between alternatives, you cannot include the costs you have paid in the past.
Non-Books
NASA Systems Engineering Handbook
- Handbook that digs into every aspect of engineering a system from idea conception, requirements gathering, design, evaluating choices to readiness and release
The Architecture of Open Source Applications
- Architects look at thousands of buildings during their training, and study critiques of those buildings written by masters. In contrast, most software developers only ever get to know a handful of large programs well—usually programs they wrote themselves—and never study the great programs of history. As a result, they repeat one another’s mistakes rather than building on one another’s successes**
Technical debt is like Tetris
- Technical debt will always exist
- Write code until you reach zero tech debt but you may never have customers, write code that delights customers - but may have horrendous tech debt
- You will never win at software
- The best you can do is identify, track and pay off technical debt on a continuous busy so you don’t lose the game
System design primer
- Ever wanted a crash course on system design concepts? Well look no further!
Refactoring by Martin Fowler
- Can you write good code until you’ve learnt how to be good at refactoring existing code?
Uber Peloton - resource scheduler for different workloads
No hello!
- Please Don’t Say Just Hello in Chat - It’s as if you called someone on the phone and said “Hi!” and then put them on hold!
Engineering blogs - a comprehensive collection of (software) engineering blogs
Decision analysis
- NASA systems engineering handbook - technical requirements
definition
- Section 6.8 on Decision Analysis is a good read on when and how to approach decision making, use a decision-making process and finally record the results of the process
Non-tech
Simply the best
- an entertaining read on the Greatness of Roger Federer, who I consider one of the best athletes (and certainly the best tennis player) of all time