Recent content on Logic Fault
Reversibility is the most important quality of good software decisionmaking. This is not a new idea. Reversibility is more important than knowing “will this work at all?”. If you make a wrong decision but can reverse it, you’re fine. If you make decisions you can’t reverse and your strategy is “hope it’s the right call”, you’re building systems on…
Here’s a cute Python trick I just discovered. I’m probably not the first one to find it. Let’s say I want an @lru_cache that can contain bound methods. I am not talking about a cache that decorates bound methods, like this: class Leaky : @lru_cache def mymethod (self): return whatever It’s (hopefully) well-known that this pattern can leak references to self . When people…
Your data lake probably looks like this and your data lakehouse will probably look like this . Realism # When building out data lake infrastructure, know the rate at which you currently need to access that data, as a ratio of “people who ask important questions that require icky and difficult queries/multi-data-source wrangling in order to answer” per unit time. Do not confuse that…
This post is a lengthy narration of some debugging/resolution I did involving MacOS, dtrace , Rust, and cross-architecture binary execution. It has deliberately not been edited for brevity by removing red herrings (threads I pulled on that turned out to be unrelated), both because those other threads might be useful to some readers, and because I think it is important to explain your mistakes as…
Ownership # “If it has multiple owners, it has no owner” indicates a failure of accountability, not a failure in the ownership model. Fortunately, failures of accountability are so common in software engineering that nobody needs to care about that distinction. Monolith # Nobody can agree on what a monolith is other than “a system where things break when we don’t want them…
An overengineer once said : There are only two kinds of languages: the ones people complain about and the ones nobody uses. This is not quite right, or is at least incomplete. More accurately: There are only two kinds of software tools: unpopular ones and misused ones. A software tool will either be unpopular, or mis-used in 99% of cases. Unpopularity is not so bad. Unpopularity does not mean…
Things to do proactively in advance of anticipated need: Pee Save money Be kind Things not to do proactively in advance of anticipated need: Stockpile nuclear weapons Purchase cryptocurrency Extract code into a microservice
So. You are in a hurry and want to compromise your users’ data publish an app in a hurry. Your head’s on straight: you don’t want to worry about the hard parts; you definitely don’t want to worry about scale/best-practices until you feel a pulse. You’re a beginner–either to software engineering in general or to standing something up _from scratch_ (1) (1) That…
A hypothetical intern or very junior/first-time programmer comes up a lot in discussion of design patterns. “Sure,” pattern advocates say. “Deciding what to do on a case-by-case basis informed by pragmatism and experience is swell, but what about someone who is too early in their career to have either of those things? We need to give the masses opiates come up with a set of…
Code is read more than it is written. Code is read by low context people in high urgency situations more than it is read by anyone else. If your design patterns impose multiple “hops” in the call stack chain to a given business operation A invoked from another place B, a user who wants to modify/add to the set of side effects of A is more likely to make the change in the wrong place…
Writing the most valuable code for your team and customers is a lot less fun than most people think it is. So we find ways to make it more fun. The human brain really likes doing this and hates doing this , so one of the ways we make coding more fun is devising ways to give ourselves an “I’m objectively correct” dopamine hit, or a “I made everything uniform and uniformity…
Let’s talk about modularity/swappability, sometimes called “abstraction” ( v. ). This is the practice of writing the ability to “change one part without touching other parts” into your codebase. This is sometimes equated this with the “L” or “D” in SOLID, but the practice extends farther than that. Examples include: Let’s make all of our…
Many teams who “successfully” apply design patterns to a codebase feel that they were successful because changes are now much easier for them to make. Consider that this may be because of the patterns used, or it may simply be because the introduction of patterns caused the engineers to touch, rework, develop muscle memory of, and otherwise get familiar with the whole codebase. The…
Class hierarchy is inferior to if/else as a way of modelling conditional behaviour. This statement probably doesn’t mean what you want it to mean, though. Prefer shorter hierarchies with functionality-containing abstract classes over interfaces. It is better to add a small amount of functionality to the “wrong” class in a hierarchy (i.e. adding specific functionality to an…
If you have to choose between tortured, hard-to-read production code and tortured, hard-to-read tests for that code, it is better to have bad tests than bad prod code. This is rarely a mutually exclusive choice. That is not a contentious claim, but the corollary is: if you have to choose between no tests at all and tortured, hard-to-read production code, it is often better to have no tests. Perfer…
It is easier to feel good about reading SOLID -factored code, but it is easier to read and understand under-abstracted code quickly. Default to putting related code as close together as possible. The more lines of indirection you add to service2.insert(service1.select(...)) the harder it is for people to maintain the code. If primitive data (say a string of “customer ID”) is…
Lots of the things on this blog talk in terms of “it is better to do good-thing- X than good-thing- Y ”. Just like there’s an implicit “too” after “Black Lives Matter” , there’s an implicit “ if X and Y are in conflict ” after these statements. Often, they aren’t in conflict. In many cases, in fact, good prior engineering practices…
Refactoring/Abstracting Code Reactively # A lot of the content under “design patterns” here has a punchline of “do so-and-so-practice reactively”. That’s a surprisingly nuanced statement to unpack, even without knowing what the practice is. It turns into something like: “I know it’s painful to suddenly context switch into unpredictable-duration refactoring…
What is this place? # This is one of Zac Bentley’s websites. Zac (he/him) thinks programming is pretty neat. Programmers are another story. Contact # I can also be found elsewhere: LinkedIn GitHub Hacker News For direct outreach, message me on LinkedIn. If you ignore that recommendation and try to reach me some other way, the bar for “why shouldn’t I block/mark-as-junk you”…