tl;dr:“Here’s what I consider to be the basics. I call them that not because they’re easy, but because they’re fundamental. The foundation on which your advanced skills and expertise rest. Multipliers and nullifiers, makers and breakers of everything you do.” These include: (1) Keep your change free of unrelated changes. (2) Make sure that your PR is up-to-date against latest on your main branch. (3) Before you comment on something, read the whole thing.
tl;dr:“Too many flaky tests. Too much time spent getting the tests to pass after making a tiny change that I knew was correct but the tests didn’t. Too many integration tests that made people wait 20, 30, 40 minutes until they could merge their change, only to reveal — months later — that they never tested anything. Too many times have I fixed a bug and knew it was fixed because I tested it manually, thoroughly, and was 100% sure that I know how the code works and that this can’t happen again, but then spent hours — 10 times longer than it took me to fix the bug — to write a test only to prove what I knew all along, that the bug is fixed.”
tl;dr:“Too many flaky tests. Too much time spent getting the tests to pass after making a tiny change that I knew was correct but the tests didn’t. Too many integration tests that made people wait 20, 30, 40 minutes until they could merge their change, only to reveal — months later — that they never tested anything. Too many times have I fixed a bug and knew it was fixed because I tested it manually, thoroughly, and was 100% sure that I know how the code works and that this can’t happen again, but then spent hours — 10 times longer than it took me to fix the bug — to write a test only to prove what I knew all along, that the bug is fixed.”
tl;dr:“A few weeks ago I was hacking on language server support in Zed, trying to get Zed to detect when a given language server binary, such as gopls, is already present in $PATH.” Thorsten shares how a seemingly harmless shell command led to catastrophic consequences.
tl;dr:“Think about it this way: which program do you execute more often than your shell? How many shells do you spawn every day? How many other programs do you run every day that spawn your shell? If you’re anything like me, it’s a lot of shells per day. I’m a heavy terminal and tmux user. I spawn shells like I open new tabs in a browser. Do you want one of your most-used programs to start slow because you didn’t care?” Thorsten shares how to measure and optimize the shell’s speed.
tl;dr:Thorsten believes programmers may be tolerating longer-than-necessary wait times due to a lack of understanding about what computers are capable of, what is a reasonable time for a given task, and how internet-based work might be skewing their perceptions of acceptable speeds. The author encourages developers to question and understand the cause of long wait times instead of passively accepting them, as many of these delays can be optimized or eliminated.
tl;dr:Writing down a plan helps developers think through the tasks, identify potential challenges, and construct a clear mental model of the work involved. Plans serve as checklists, aid in delegation, and improve overall performance. By starting to create plans and refining them through iterations, developers become better at planning and gain a deeper understanding of their work. Making plans enhances productivity and allows developers to confidently answer questions about their progress.
tl;dr:“Here's something I've been kicking around in my head for a few weeks… there are two types of engineers. Type 1, when presented with a problem, thinks: "easy, people can just do X.” Type 2, when presented with the same problem, thinks: "very hard, because it requires people to do X." Thorsten explains the importance of the subtle difference.
tl;dr:"The following is a loose, unordered collection of thoughts that come up when I look back on the past 10 years:" (1) Fearlessness is undervalued. (2) You can’t predict the future; try and you might end up in trouble. (3) Nothing really matters, except bringing value to the customer (4) Perfection is unachievable. And more.
tl;dr:"After a while, more and more, you’ll find yourself in moments of awe," stunned by the size of the " the mountains of work and talent and creativity and foresight and intelligence and luck that went into it." It's hard not to be romantic about programming.