tl;dr:"I taught myself how to breathe slower. How to slow things down. How to not answer somebody instantaneously… You can always move slower. The world will basically wait for you if you’re deciding something consequential. And you can always say, ‘I’d like to think about that a little bit.’ So the only reason to feel panicked is if you’re panicking yourself, and that’s your fault. You don’t have to do that. You can take your time, you can weigh things. It’s very infrequently that the timing has to be instantaneous."
tl;dr:From Jensen Huang, the co-founder of NVIDIA: "You want to position yourself near opportunities. You don’t have to be that perfect. You want to position yourself near the tree. Even if you don’t catch the apple before it hits the ground, so long as you’re the first one to pick it up. You want to position yourself close to the opportunities." Matt argues that this is true on a personal level.
tl;dr:(1) Reproduce with the smallest example. In the simplest environment. (2) Read and re-read the error statement. Read the stack trace. Add more logging if you don’t know where the error is thrown. (3) Change one thing at a time. (4) Divide and conquer. Sometimes that means binary search on good/bad commits. Other times isolating the problem. (5) Be open to debugging in different environments. (6) State your assumptions. (7) Get a second set of eyes on it. (8) If you're debugging some stateful code, think about \_how\_ you ended up at that state. A recipe that (reproducibly) gets you to that state is often the path to fixing it. (9) Look at the logs, all the logs. (10) When in doubt, start with the most recent changes, especially dependencies changes.
tl;dr:“Why do ambitious things sometimes come together so fast?” Matt argues the following: (1) Right time, right place: “Sometimes, groundwork from many disparate threads comes together, making the previously impossible possible.“ (2) A sense of urgency is one of the best motivators. (3) Constraints foster creativity. (4) Fast favors prototypes. A focusing mechanism for pruning unnecessary details.
tl;dr:The article presents 45 laws by David Akin, Professor of Aerospace Engineering, including: (1) Engineering is done with numbers. Analysis without numbers is only an opinion. (2). To design a spacecraft right takes an infinite amount of effort. This is why it's a good idea to design them to operate when some things are wrong. (3). Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time. (4). Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment. (5). Three points determine a curve.
tl;dr:“Software trends towards higher abstractions. You can do more with less. Not only do developers never need to touch hardware anymore, but they might not even need to interface with public cloud providers and might opt to use developer-friendly middlemen. That means less code to write. Less code to write means a narrower range of skills needed to get started. This lowers the barrier to entry.”
tl;dr:"AWS S3 pricing hasn't decreased as fast as the underlying storage costs. This doesn't include the additional fees like egress. Of course, prices vary by storage tier and region, but this seems to be a general trend." Matt graphs the changes in pricing over time.
tl;dr:Instead, SQLite uses Fossil as a version control system, which is also developed by the same primary author as SQLite. Both Git and SQLite share some similar design philosophies, which Matt discusses at a high level.
tl;dr:"A computer scientist was writing a column about Literate Programming – one of Knuth's ideas on how documentation and code should live side-by-side. So he asked both Knuth and McIlroy to write a program: "Given a text file and integer k, print the k most common words in the file - and the number of their occurrences - in decreasing frequency."
tl;dr:"When version controlling your code with git, there are generally three choices when merging feature branches into main. Each has its quirks, so which one should you use?" Matt runs through when to use each, and his preference.