Links - 29^th April 2024

When someone experiences something unnatural, when the world behaves in ways they’re told it does not, it freaks people out. There are traumatic elements to it and people’s lives can be upended. Some people try to rationalize it, never to acknowledge it again. But there are many people are driven by the need to validate their experience. Lone seekers often believe they are looking for proof but really what they are looking for is a way to make sense of a world that they no longer recognize. There is a sprawling effect to this, where a person’s pattern seeking facilities have the power to impose themselves on one’s reality. More than ever, its obvious that we make our own worlds that we want to live in.

The more you dig, the more you find, but what you find may distract you from what you were looking for in the first place. If there is anything to learn from this film, it’s that you can’t let your ego get in the way. It’s possible for the things you lack to consume you because mere promise of answers implies that those holes can be filled. The investigator who survives the paranormal is the one who has fun with it. Who can approach the hunt with a sense of playfulness and unpredictability.

To summarize the situation: over the years, BUG_ON() has been seen as so destructive that developers are simply told not to use it at all. The WARN_ON() macro has, instead, taken its place; but in settings where panic_on_warn is set, the end result of a WARN_ON() call is essentially the same. So, naturally, use of WARN_ON() is also now discouraged much of the time.

Today, most people who see a list of the names just see a bunch of letters on a screen or page. They don’t connect the names with the individuals. They see the Agile Manifesto as a standalone “thing”, stripped of its history and context. Stripped of its humanity, one could say. That’s not a criticism. I guess it’s normal. Maybe it’s better that way, as I will suggest in a moment.

Anyway, three of the Manifesto authors (that I know of) take the individualism dimension further than Hofstede himself may have imagined possible. They’re in the extreme category that says things like “taxation is theft” and who don’t believe they owe their fellow countrymen anything at all, or that they have benefited in any way from “the system” or “the collective”. They are self-spawned hero-gods, each a self-sufficient world in a skin-sack.

The incongruity is just this: The hero-gods of Agile don’t behave in any way consistently with the values and principles they wrote into the Agile Manifesto. They wouldn’t recognize empathy, humility, and curiosity if they drowned in a vat of the stuff. When you pair-program with them, they dominate rather than collaborate.

They assume they hold all the Magic Keys and you are an empty vessel waiting to be filled with their wisdom. At times they are so arrogant it’s hard to stay in the same room with them for more than five minutes. This observation applies only to a few of the authors, yet the contrast between what they do and what they wrote is striking, if not downright jarring.

In a sense, it’s a good thing that time, the bandwagon effect, the greed of big consultancies, the dull gray monotony of certification, and the insistent, debilitating corporate standardization of “agile” have blurred the focus on the individual authors. The message is probably clearer if you don’t know too much about them, after all. The document speaks for itself, and it has very good things to say.

Thanks for sending this along. I left my comments in the Google Doc.

You don’t see my comments? You’re looking at the old document. I copied your Google Doc and made a new Google Doc called “Proposal v2 – Comments”. Once you have my comments, put everything together in “Proposal v3 FINAL”. Then, if you don’t mind copy-pasting your new document link into the spreadsheet where we keep track of all the document links, that would be perfect. And, of course, make sure you’re in the most current spreadsheet (Copy of Spreadsheet COPY_01).

People tend to be visual: we use pictures to understand problems. Mainstream programming languages, on the other hand, operate in an almost completely different kind of abstract space, leaving a big gap between programs and pictures. This piece is about pictures drawn using a text character set and then embedded in source code.

That being said, there is an overwhelming force in the Rust community that when anyone mentions they’re having problems with Rust the language on a fundamental level, the answer is “you just don’t get it yet, I promise once you get good enough things will make sense”. This is not just with Rust, if you try using ECS you’re told the same thing. If you try to use Bevy you’ll be told the same thing. If you try to make GUIs with whichever framework you choose (be it one of the reactive solutions or immediate mode), you’ll be told the same thing. The problem you’re having is only a problem because you haven’t tried hard enough.

The most fundamental issue is that the borrow checker forces a refactor at the most inconvenient times. Rust users consider this to be a positive, because it makes them “write good code”, but the more time I spend with the language the more I doubt how much of this is true. Good code is written by iterating on an idea and trying things out, and while the borrow checker can force more iterations, that does not mean that this is a desirable way to write code. I’ve often found that being unable to just move on for now and solve my problem and fix it later was what was truly hurting my ability to write good code.

In other languages one can write code with “I can throw this away later” in mind, which I’ve found to be the most useful approach in terms of getting good code. An example being say that I’m implementing a player controller. I just want the player to move and do things, so that I can start building my level and enemies. I don’t need a good controller, I just need it to do things. I can surely delete it and make a better one later. In Rust, sometimes just doing a thing is not possible, because the thing you might need to do is not available in the place where you’re doing the thing, and you end up being made to refactor by the compiler, even if you know the code is mostly throwaway.