-
- Tesla beat the county, they gave the greenlight to reopen (post-reopen). Threat to bring business to another state was too much.
- Read the following two books on the plane.
- The Mythical Man Month.
- Effort != progress. This one is great. Hard to remember. Filling your time and closing tickets does not mean success.
- A man-month is not a good measure of time, because doubling the men does not halve the months. Many steps are sequential. Communication is not trivial. I don’t disagree with this, but I think it’s a fairly immaterial and obvious claim. Of course there’s overhead by adding more developers. Of course you can’t just throw people at a problem and hope it gets done faster. But of course you should estimate projects in people+time. That’s the best way. Just be congnizant when adjustments occur.
- The gap in productivity between good and bad ICs isn’t a percentage, it’s usually a factor of 5-10.
- Plan to throw one admit. Admit mistakes, adjust, improve. Your first try is never your last. Build changeability into the system.
- Milestones should be SHARP. It is much easier for devs to stay on track, and much easier for managers to follow, if the goals aren’t fuzzy.
- I actually don’t love this cult book. There’s some good stuff. It’s mostly obvious info. It also tries to take technical stands on a very philosophical stage, which misses my mark.
- Secure and Reliable Systems.
- Reliability usually means adding redundancy. Redundancy means more surface area for mistake, failure, exposure, which is less security.
- Disaster recovery. Prep for natural disasters, hardware failures, emergencies, security breaches, anything catastrophic that might hit.
- Think about attack vectors. What might malicious actors want from you? Data, money, silence?
- No human access to production machines. All through proxies or automated systems. No arbitrary bash commands over ssh. Google has a tool-proxy-cli through which all commands are run over rpc, which audits and records everything.
- Principle of least privilege. Only give access to the systems necessary for the job.
- Throttling service, either by request or by user or something else.
- Auth systems should fail closed. None-critical systems might be able to fail open.
- DoS. Cache. Throttle specific IPs. Buy more hardware. Monitoring. CAPTCHA.
- Do not mix refactors and functional changes into the same commit.
- Consider privacy and access when mirroring prod data for tests. You might not want to give testers the ability to see prod.
- Dynamic analysis: coverage and performance profilers (instrumentation). Static analysis: AST and style.
- When you hear hoofbeats, do you think of horses or zebras? Failures that look the same can have common or rare causes. Don’t assume.
- Blue Teams = Defense. Red Teams = Offense.
- Canary. Make sure your rollouts are incremental, and you know about a failure before the user.
