tl;dr:Hillel describes strings as “the most powerful and terrible of all basis types... When you see a string in code, you want to know what kind of string it is. We use these strings for different purposes and we want to do different things to them. We might want to upcase or downcase identifiers for normalization purposes, but we don't split or find substrings in them. But you can do those operations anyway because all operations are available to all strings. It's like how if you store user ids as integers, you can take the average of two ids. The burden of using strings properly is on the developer.”
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."