/Hillel Wayne

Goodhart's Law In Software Engineering tl;dr: “Goodhart's law is a warning for pointy-haired bosses who up with terrible metrics: lines added, feature points done, etc. I'm more interested in how it affects the metrics we set for ourselves that our bosses might never know about.”

featured in #551


State And Time Are The Same Thing tl;dr: “Some function programmers stay "shared mutable state is the enemy". I think it's more like "time is the enemy", and time represents itself as mutable state. If a state update is purely internal and cannot affect the observable state, then it does not advance time. I find this a good model to reason about abstract systems.”

featured in #547


Toolbox Languages tl;dr: “A toolbox language is a programming language that’s good at solving problems without requiring third party packages. My default toolbox languages are Python and shell scripts, which you probably already know about. Here are some of my more obscure ones.” Hillel guides us through several languages along with their useful features. 

featured in #533


Solving A Math Problem With Planner Programming tl;dr: “Suppose that at the beginning there is a blank document, and a letter "a" is written in it. In the following steps, only the three functions of "select all", "copy" and "paste" can be used. Find the minimum number of steps to reach at least 100,000 a's. If the target number is not specified, and I want to get the exact amount of a, is there a general formula?”

featured in #530


I've Been Thinking About Tradeoffs All Wrong tl;dr: “Normally I think of tradeoffs as framing two positive things, like saying "SQS has better control while SNS is easier to add new services". Instead the speaker framed it as two wholly negative things, and the tradeoff is which negative thing you want less of. We can do this with any tradeoff, because any positive quality about X can be turned into a negative quality of Y. Instead of "X is faster, Y uses less space", we can say "X uses more space, Y is slower.””

featured in #524


Software Friction tl;dr: Friction is everywhere in software development: bugs, security alerts, dependency upgrade breaks something, etc.. Hillel believes the way to mitigate this is (1) Smaller scopes and shorter iterations. (2) Giving teams more autonomy. (3) Building in redundancy. (4) Better upfront planning. (5) Automation (6) Experience. (7) Gaming exercises. (8) Checklists and runbooks. 

featured in #511


If Inheritance Is So Bad, Why Does Everyone Use It? tl;dr: Hillel refers to an essay that says that inheritance is harmful and if possible you should "ban inheritance completely... “A lot of these arguments argue that in practice inheritance has problems. But they don't preclude inheritance working in another context, maybe with a better language syntax. And it doesn't explain why inheritance became so popular in the first place. I want to explore what's fundamentally challenging about inheritance and why we all use it anyway.”

featured in #506


The Hunt For The Missing Data Type tl;dr: “I see graphs everywhere and use them to analyze all sorts of systems. At the same time, I dread actually using graphs in my code. There is almost no graph support in any mainstream language. None have it as a built-in type, very few have them in the standard library, and many don’t have a robust third-party library in the ecosystem. Most of the time, I have to roll graphs from scratch. There’s a gap between how often software engineers could use graphs and how little our programming ecosystems support them. Where are all the graph types?” Hillel discusses and shares a list of programming languages with graph types. 

featured in #495


Planner Programming Blows My Mind tl;dr: “Picat is a research language intended to combine logic programming, imperative programming, and constraint solving. I originally learned it to help with vacation scheduling but soon discovered its planner module, which is one of the most fascinating programming models I’ve ever seen.”

featured in #491


Strings Do Too Many Things 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.” 

featured in #488