Haupz Blog

... still a totally disordered mix

Old Standard Textbook, Renewed

2024-10-24 — Michael Haupt

Back in university, one of my favourite courses was the one on microprocessor architecture. One of the reasons was that the lab sessions involved building logic circuits from TTL chips with lots of hand-assembled wiring (imagine debugging such a contraption). Another reason was the textbook, which explained a RISC processor architecture (MIPS) in great detail and with awesome didactics. This book was “The Patterson/Hennessy” (officially, it goes by the slightly longer and also a bit unwieldy title “Computer Organization & Design: The Hardware/Software Interface”).

This was the Nineties. Fast-forward 30 years to today, and we have a new and increasingly practical RISC architecture around: RISC-V. The good thing about this architecture is that it is an inherently open standard. No company owns the specification, anyone can (provided they have the means) produce RISC-V chips.

Guess what, that favourite book of mine got an upgrade too: there is a RISC-V edition! This means that students, when first venturing into this rather interesting territory, can learn the principles of CPU design on an open standard basis that is much less convoluted than certain architectures, and - unlike certain others - entirely royalty-free.

Makes me want to go to university again ...

Tags: the-nerdy-bit, hacking

Output is Small Steps

2024-10-16 — Michael Haupt

In the book “Atomic Habits” by James Clear, the author argues to focus on small steps to reach a big goal, instead of focusing on the big goal and getting frustrated by what seems to be slow progress, or intimidated by the sheer size of the end. This reminded me of the good old output / outcome dichotomy.

Outcome (the big end) takes time to achieve. Keeping the eyes on that can lead to losing sight of what’s important: the concrete next step. This step, like all the others, is a small change, and reaching the end goal is a journey of such small changes that will eventually have big consequences. These steps are the various instalments of output we need to generate to eventually deliver the outcome.

Next time you or your team are hit by analysis paralysis, and feel the tendency to slice those user stories in an epic way too big because the smaller ones don’t feel like making progress, take a step back, and err on the side of slicing the story smaller. It’s quicker to achieve, quicker to generate that nice bit of satisfaction when completed. And it will contribute to the epic nonetheless. What’s important is to be confident about getting there.

Tags: work

Tár

2024-10-09 — Michael Haupt

It's been a while since this was on the big screen. I still want to recommend the movie Tár. A masterpiece - I was completely captivated.

What helped make this happen was not just Cate Blanchett’s impeccable acting, but also that the story unfolds in a setting I’m at least a bit familiar with. I found the dialogues about music to be at a rather elevated level of nerdiness that I greatly enjoyed. Similarly, the depiction of how sheer power plays out in the highest spheres of cultural business struck some cords ... I’ve had my own introspections into that.

This is an absolutely fantastic movie.

Tags: movies, music

Marvel Dice Throne

2024-10-04 — Michael Haupt

Marvel Dice Throne is a game involving rolling dice a lot (one might guess that given the name), and it has a nice deck / character building aspect, too.

Each player picks one of eight Marvel characters. For each character, there’s a whole collection of character board, individual cards, status tokens, and dice. That means the game’s box is sizeable.

The point of the game is to let up to four characters engage in a battle wherein they, bluntly spoken, smack one another around the place by applying various super powers. For my test, I chose to let Captain Marvel play against Black Panther - for no particular reason.

Each of the character boxes contains, as mentioned, a selection of items and cards. These are all set out to prepare the game. In the image below, you can see the setup at the start of the game. The characters start out at full health (indicated by the oblong counter to the upper left of the character tableau). They also have a certain amount of combat points (CP, indicated by the round counter). Each character also has a starting set of four cards.

The rules are learned quickly: in each round, the acting character first does some deck building by selling and playing cards (CP are the currency). Next, the character attacks an opponent, who can deflect (some of) the damage by activating defensive skills. This is followed by another round of deck building to wind things down. Each character has special abilities, which are depicted by special cardboard tokens. These add a lot of spice to the game, and make for some surprises.

So far, so good - it’s plain and simple. The game is fast-paced and quite a lot of fun, because the combinations of cards and special abilities, together with the random element added by the many many dice rolls, make for many variations. I can wholeheartedly recommend it.

Captain Marvel won this round, by the way. Narrowly.

Tags: games

PlanckForth

2024-10-03 — Michael Haupt

I had shared some discoveries I had made in Forth territory. Since these systems of minimal abstraction really fascinate me, I took a deep dive into the PlanckForth implementation and dissected the 1 kB ELF binary down to the last byte.

This is indeed a tiny Forth interpreter that does just the most basic things in machine code. It provides the foundation for a very consequential bootstrap to be executed on top of it. The bootstrap builds the actual Forth language from first principles in several waves.

In case you’re interested, here are the binary source and bootstrap with my comments. Note that I stopped commenting in the bootstrap once it gets to the point where the minimal Forth supports line comments.

What next? Part of me wants to build a handwritten RISC-V binary for the basic interpreter ...

Tags: the-nerdy-bit, hacking

More Forth

2024-10-03 — Michael Haupt

The Forth programming language is a thing I’ve previously written about. I recently came across this little gem of a talk, wherein the author points to some interesting resources about Forth. In particular, the slides put emphasis on how minimal a Forth implementation can be.

The point about Forth is that it heavily depends on threaded code. That’s a simple technique to implement an interpreter on the bare metal. In a nutshell, code to be executed by a threaded interpreter is mostly addresses of implementations of logic, that the very simple interpreter “loop” just loads and jumps to, following a “thread” of addresses through its implementation.

Indeed, Forth source code consists of just “words” that are concatenated to express semantics. These human-readable words are mere placeholders for the memory addresses where the words' implementations can be found. In other words, a Forth compiler is simplistic: it boils down to dictionary lookups.

To demonstrate the minimalism, the PlanckForth interpreter is just a 1 kB hand-written ELF binary. The syntax of the basic language this interpreter understands is a bit awkward, but sufficiently powerful to bootstrap a full-fledged Forth in just a couple hundred lines.

JonesForth is a richly documented Forth implementation. (You’ll have to go through the snapshot link to get the source code.) Reading the code is highly instructive.

Tags: the-nerdy-bit, hacking

Historical Source Code Every Developer Should See

2024-09-21 — Michael Haupt

This piece lists some historical source code that today’s engineers, in the opinion of the author, should read and know. The artifacts in question are the WWW demo source code, an early C compiler, pieces of the early Unix research code bases, the first Linux release, and Mocha, the first JavaScript engine.

While all of these (maybe, and forgive the snark, with the exception of Mocha) are relevant, I cannot help but wonder about the author’s rationale for choosing these particular specimen. The author argues these “built the foundation of today’s computer technology”. I beg to differ.

Graphical user interfaces are quite a thing in today’s computer technology, one should think. These owe a lot to BitBlt, the Xerox Alto machine, and, consequently, Smalltalk (that programming language had an IDE with a GUI back in the 1970s). So, for source code, I’d add to the list this memo from 1975 describing BitBlt, and the Computer History Museum’s page on the Xerox Alto source code.

Tags: hacking, the-nerdy-bit

Avoiding WIP Creep

2024-09-16 — Michael Haupt

Recently, I had described how I arranged my work tracking to deal with high amounts of WIP, or rather, after hitting rock bottom with WIP.

But how did that happen? I’m normally good with prioritisation. I could admittedly improve my delegation skills, but feel there’s a good balance. WIP just seemed to accumulate over time. At some point, this WIP creep became too much. What led to the accumulation, though?

I believe it’s ultimately dependencies, combined with an inability to fully cover each WIP item. Let me explain.

A pattern that I observed is this. I start looking into some matter, accepting it as a WIP item. At some point, I need input or a contribution from someone else - there’s a dependency. In some cases, I can drive the item forward by doing as much as possible of the contribution I need myself. In cases where that’s not possible (due to expertise, knowledge, authority, or whatever), I’m unable to continue. The dependency stalls for as long as it takes to obtain the required input.

If I’m disciplined and have a WIP limit, that means that, at some point, I’ll start idling because I have stalled dependencies on a majority of (or all) WIP items. So my natural tendency to get stuff done kicks in, and I accept new WIP items. Loop back to above, and there’s the downward spiral.

No one’s to blame - we’re all busy and have many things to do. Not all dependencies can be resolved immediately. So the next question is: how to avoid WIP creep, and what to do instead of idling and accepting more WIP?

Let it be clear - accepting more WIP that comes as requests is often inevitable (at least for me). The role demands paying attention to many things. (There is something to be said about how to bring down the number of things to actively pay attention to.) What seems to be more relevant is that allowing things to rest and waiting for them to move creates the false impression of more time being available. This is the “void” that new WIP eagerly fills.

So what can be done instead of waiting? Taking action, of course. That piece of input I’m expecting someone to deliver: can I get that myself by doing some research (and learn something new along the way)? The piece of work I think I need someone else to do: can I do that myself (and take some of the load off of that other person)? Possibly even more so than mentioned above - in other words, by doing more than possible?

Bottom line: if I have a task I want or need to advance, I should own the responsibility for advancing it.

There are lines that can’t be crossed. If I’m waiting for an expense approval for my latest business trip, I can’t just approve my own expenses to keep it moving. If advancing a certain task involves significant amounts of coding, I really shouldn’t do that because it’s not what I’m here for (and I wouldn’t expect an engineer to do, say, hiring manager interviews - that’s not what the engineer is here for). And so forth. But roughly speaking, if the next thing that needs to happen is well within my remit and abilities, why don’t I do it?

This idea is, essentially, the same as what's usually named internal open source (or a variation thereon). If I’m in charge of delivering some outcome, I should pretty darn well be on top of that progress, and be ready to do what’s necessary. Within boundaries, but those shouldn’t be too narrow.

The internal open source model is essentially all about collaborating to manage and resolve dependencies. Again, collaboration and dependencies: these are the two key things. The mechanisms explained in the iOSS V2MOM apply to the context of software engineering. Abstracting away from that context, the key idea is really to empower dependents to be proactive partners in a collaboration instead of increasingly impatient recipients of a service.

That’s it, that’s the thing.

(Note: The iOSS V2MOM was originally written by several folks at eBay. While I was driving that effort, the credit isn't all mine. Sadly, I do not recall the names of many individuals who contributed at the time, but hat tip to Mitch!)

Tags: work