Output is Small Steps
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
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.
Marvel Dice Throne
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
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
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
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
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
Interpreted or Compiled?
What would you say: is Java an interpreted or a compiled language? What about C, C++, Python, Smalltalk, JavaScript, APL?
Laurie Tratt has written two (1, 2) absolutely wonderful (read: scientifically and technically nerdy) blog posts about the matter. He uses the Brainfuck programming language (it is less NSFW than the name suggests, but I will continue to use its name in abbreviated form, i.e., “bf”) and a series of implementations thereof that increasingly blur the boundary between interpreted and compiled.
The blog posts resonate with me especially because I use bf myself whenever I want to learn a new programming language: I just write an interpreter (or compiler?) for bf in that language.
These are two rather entertaining reads, and they will leave the reader in a better shape for the next inevitable discussion of whether this or that language is interpreted or compiled.
Tags: hacking, the-nerdy-bit