tl;dr:“How I use git is based on the last 12 years of working in companies with smallish (less than 50) engineering teams. In every team, we used git and GitHub exclusively; changes were made in branches, proposed as pull requests, and then merged into the main branch. In the last few years, after GitHub introduced squash-merging, we used that.”
tl;dr:“Time for me to pass on something I've been practicing for years but haven't found written down somewhere. It's a simple thing. A practical thing. Forged in the trenches. It won't win any contests in which the audience gasps and says "oh, now that is clever." But it’s easy. Simple even. And it can save a lot of time and tears and, at the end of the day, isn't that some of the best stuff? When debugging or testing your program, do not use data that looks like a variable or type name.”
tl;dr:“Shredding, on the other hand, means to embrace destruction. To go on a shred is to delete five load-bearing functions all at once and recreating them. Deleting a type and its definitions, rebuilding it from the compiler errors. Creating an empty file and building from scratch a better version of what already exists in another file. Shredding is ripping out a page and redoing it.”
tl;dr:“Always leave your code unfinished the day before. That way I always know I can come back to a small problem that may only require three minutes to fix a test, or write a new method, or whatever the case is. Once I've been doing code for five or ten minutes, I tend to quickly become sucked into the problem and it's much easier to jump into the harder code at that point. Same rationale for stretching before doing exercise, basically.”
tl;dr:“Sometimes, I think that this is what it’s all about: stories. And that, maybe, leadership is the act of producing the right stories, the anecdotes that are repeated by those around you, that carry the message you want out there.” Thorsten shares some examples.
tl;dr:“For the longest time, I thought Instruments on macOS wasn’t for me. Whenever I saw its icon show up in the /Applications folder or pop up in a launcher, I assumed it’s part of Xcode and Xcode is an IDE for Objective-C and Swift programmers and that’s not what I do and that’s why Instruments isn’t for me. I was wrong.” Thorsten discusses how he uses Instruments as a productivity tool with anything.
tl;dr:“He taught us that you can summarize anything, in whatever length you want. He could summarize the Cold War in two sentences. A new law around unemployment benefits and social security? Four sentences. Bismarck’s forced resignation and all the political maneuvering that proceeded it? Three. Whenever someone would fail to summarize something, he’d say: “you’re not thinking clearly.” Summarizing is thinking clearly.”
tl;dr:“Last week I got a new monitor, after my old one has shown worse and worse signs of what looked like burn-ins. The new monitor allowed me to get rid of two cables in my setup, which pleased me quite a bit. And since there are people reading this whose eyebrows went up at the “two cables”, I thought I’d use this as an occasion to write about my desk and computer setup a little bit.”
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.”