tl;dr:“13 bits of advice for early-career programmers. Some of it is contradictory”: (1) Behind every best practice is a horror story. If you don't understand a best practice, look for the horror story that inspired it. It might make the best practice make sense. (2) Carefully think about any advice and evaluate how it applies to your situation. There is very little about software that's been scientifically studied, and most of the research is inconclusive. (3) Every tool has some form of hidden depth, from your programming language to git to JIRA. You don’t have to become an expert in every single one, but consider spending 5-10 minutes learning a bit more about what it can do.
tl;dr:Hillel critiques the 4doc model for user documentation, highlighting that it's not universal or comprehensive. While effective for tools, it may not suit frameworks and languages. The key takeaway is that relying solely on the 4doc model can limit documentation effectiveness, and a more flexible approach that considers the specific subject being documented is encouraged.
tl;dr:Hillel argues why a well-documented "Defense of Design" is an invaluable resource for understanding a project's history, design decisions, and constraints that shaped it. It provides insights into the thought process of the creators, developers, and maintainers, thus fostering a greater level of understanding and appreciation for the software.
tl;dr:“While people like coming up with grand theories of complexity, there’s very little info out there on the nitty-gritty specific sources of complexity… I think a lot about the different sources of complexity. This article is about one particular source.”
tl;dr:“Most of the time we ask narrow questions which are helpful when confirmed and not-helpful when rejected. If you make a lot of wrong predictions, then debugging boils down to guess-and-check. If you instead ask broad questions, you learn less when they’re true but more when they’re not. Then you iteratively close in on the actual source of the bug.”
tl;dr:"I’ve tried to write a blog post on tag systems for years now... The problem is that there’s just so much to them, so many different approaches and models and concerns that trying to be comprehensive and rigorous is an exercise in madness... So screw it. These are my non-comprehensive, poorly-researched thoughts on tag systems. This is not about implementation of tag systems, just their design."
tl;dr:"I think dynamic typing is itself really neat and potentially opens up of really powerful tooling. It’s just… I’m not actually seeing that tooling actually exist, which makes me question if it’s possible in the first place."
tl;dr:"Why do we have the term “boilerplate code”? It comes from the peculiar interplay of two industrial revolution technologies: steam engines and hot metal typesetting."
tl;dr:"Sudoku is an example of a constraint problem. Most “solving sudoku” tutorials use either backtracking or constraint propagation. These same techniques apply to all constraint problems, and since such problems are so widespread, it doesn’t make sense to custom build an algorithm for every single one. Rather, we want general-purpose constraint solvers we can apply to arbitrary problems."
tl;dr:"Mimicry is when software X reimplements at a higher level a core feature of software Y. The produced facsimile has some, but not all, of the same properties, enough to “look like” it’s the same thing but missing many of the nuances. This exists in every kind of software. One language can mimic another, a library can mimic a language, a database engine can mimic a product, etc."