Markdown Links in MacVIM
Some text editors have that nice feature that if you want to turn a span of text into a link, you select it, and when you then paste a URL, the editor will create that link in place. My favourite text editor is MacVIM, and I thought it’d be nice to have that feature there as well. Since most of the text I edit in MacVIM is Markdown, selected text needs to be converted into a link following the syntax rules.
Now, MacVIM can be extended (of course). As I didn’t know the language well enough, I thought I’d vibe code it with some help from Claude Sonnet, which I use in my Langdock workspace. (To be clear, I did not use Claude Code, but plain old Claude with a canvas.)
Because I wanted to be able to understand (and assess the quality of) what would come out of this, I started by reading a nice and compact primer on the vim language. That didn’t take long, and after a brief pause to appreciate the quirkiness of the language, I got started.
Phase 1: Building the Thing
The first result looked right. However, it didn’t work at all - hitting Cmd-V on selected text with a URL in the clipboard just pasted the URL instead of the selected text, which was the normal behaviour I had intended to replace.
A few exchanges later, during which Claude gave rather helpful advice
for troubleshooting and debugging, and even added code to produce
debugging output, I realised that I had made a mistake in my first
prompt: I had mentioned I wanted a vim plugin, but had not
mentioned I was using MacVIM. That got me much closer to the goal.
Phase 2: Shrinkwrapping the Thing
I ended up with a version of the plugin that did what I wanted, however it still produced debugging output. So I instructed Claude to take away all the fluff and be minimalistic about the original requirement.
The result fell back to just replacing selected text with the pasted URL. In shrinkwrapping the plugin, Claude had also removed MacVIM specifics that were required to make it work. One instruction later, that was fixed.
However, now it didn’t get the spaces around the freshly created link right. That took one more round, after which pasting of non-URLs was broken. One instruction later, the plugin suddenly contained a syntax error. Once that was addressed, the thing worked as expected (for good).
Phase 3: Understanding the Thing
I don’t think vibe coding should be a discipline where humans delegate everything lazily to an LLM. So I started a new Claude session, fed it the code, and instructed the model to explain it to me. With my entry-level understanding of the vim language, I should be able to appreciate what was going on. That worked well.
Finally, I asked the second Claude session what could be improved about the code. Because LLMs are “eager to please”, I instructed it to avoid digging for “improvements” just for the sake of it, but to apply a fair assessment.
The result was good; there was one actual duplication that made no sense, which hadn’t met my eye and which I subsequently removed. I chose to not adopt another suggestion about removing code duplication for register saving-and-restoring and replacing it with an extra abstraction.
Show me the Code!
All right, all right, here it is. Needless to say, the Markdown source of this post contains several links, all of which were created using the help of this plugin.
Tags: hacking
An LLM in Minecraft?
Of course, Minecraft is Turing complete, and can even run itself …
… and now someone built a ChatGPT thing in Minecraft, and I honestly don’t know any more.
Tags: the-nerdy-bit
JFR, JMC - and Minecraft
JFR (Java Flight Recorder) is a tool I keep pointing to. That’s because it’s immensely useful - if it’s being used. There is a small hurdle to jump over, but then a lot of potential is unleashed.
If you need one last argument to be convinced, look at this: Minecraft itself, of all things, leverages JFR for analysis. The developers have created custom JFR events to be able to observe in-game circumstances of chunk generation and server traffic. Thanks to how JFR works, these events can be immediately visualised in accompanying tools, such as JMC (Java Mission Control).
Tags: the-nerdy-bit
Estimates in Software Development
What are estimates (as in: delivery time estimates in software engineering) good for? Those making them mean them as, well, estimates indeed, while those hearing them all too easily fall for mistaking them as guarantees, which dissonance will lead to interesting misunderstandings and consequences.
Let’s be clear: I understand them as expertly informed guesses that come with a confidence score. Implicitly, it’s clear that the confidence score is higher the closer the estimated date is. Still, it’d be good to always communicate the confidence along with the date.
It’s important to keep them updated, too. Nothing’s worse than a dearly held belief or assumption that all of a sudden is shaken up by a late change. Transparency rules: regardless of whether the confidence changes, or the estimated date - it needs to be communicated.
Tags: work
Eat This, Dunning-Kruger Fans
I learned that the Dunning-Kruger effect apparently suffers from itself. Or proves itself true. Or false. Or whatever. And that also means I, insofar as it is concerned, have myself suffered from it, in spite of its inexistence. This is all very confusing but funny.
Tags: misc
Vacation Pragmatics
(This post is written from the perspective of the German labour work legislation, but applies in spirit elsewhere.)
What’s the value of vacation?
When employers request their employees to take as many as possible of their remaining vacation days in the current year instead of carrying them over into the coming year may give raise to that question. This is because some people have a habit of scheduling vacations in small bursts (say, sprinkle their vacation day budget over a multitude of single days), or of carrying over a vast amount of days into “next year”, and risking to lose some.
The value of vacation is to give employees time to rest. Properly rest. Take their minds off of work. As much as someone may enjoy their job (as do I), it’s simply healthy to not be concerned with it for an extended amount of time every now and then. Or to at least shift the focus of a major part of waking hours from work to something else (as do I - I’ll freely admit: I’m almost never 100 % offline).
This is why we have vacation days, and this is why the German federal vacation law (yes, there is such a thing) is very strict about them: employers need a good reason to deny a vacation request, vacation is to be granted contiguously, and it must be taken in the year it accrues in.
What’s a good reason for denying a vacation request? Urgent operational needs, for example. When the person requesting vacation is really necessary to get something done that is important to get done during the requested time. Say, a software release is scheduled, and the release manager doesn’t have anyone trained as a deputy. (There’s a job for the manager to do here as well, for sure.)
Contiguous vacation? Oh yes. It’s not considered proper resting if it’s scattered over multiple single days. It better be several week-long absences. No one is going to convince me otherwise - not taking proper time off will have an impact, even if it’s maybe delayed. Resting is an important component of burnout prevention.
Take it in the year it accrues in? Yup. Vacation days may only be carried over if the company really could not grant vacation to someone, or if the employee simply could not take vacation. There are few good reasons for both of these cases. The latter one is, especially, not justifiable by the plain desire to save some days.
Vacation is important. It really is. Let’s take it seriously.
Tags: work
Ambitious Achievers
Being really good at a job does not mean it’s easy to scale to a bigger responsibility. Many excellent engineers who were “promoted” to management can confirm this. So can countless others who, given a new, bigger responsibility, start to fail very visibly and painfully.
The Peter Principle captures this, and is neatly summarised like so: everybody rises to the level of their own incompetence. Dawn Springett, in a piece on LinkedIn, covers the idea too, framing it as being about what she calls Ambitious Achievers. In her piece, she also expands on how the very skills that brought the Ambitious Achiever to this new place may easily turn into obstacles in the new context. Springett’s suggestions focus on the organisation: ensure that promotions are done for better reasons than technical skill alone, and that people skills are properly developed.
I agree with all of that, and would like to add a remark for the perspective of the Ambitious Achiever.
Those excellent skills are part of the reason that brought you to this new and much wider scope. You have developed them in a context that perhaps did not change much in nature: you’ve scaled them up. Now it’s time to build new skills. But that’s not it, the skills that brought you here don’t end here: you can scale them out. What do they look like “a level higher”? What will change if you impart some of them on people you work with?
The bigger your scope becomes, the more you need to build on relationships. Make sure you invest in those; make sure you work hard to understand the people in those relationships, and what their interests and constraints are.
Most importantly: the people who offered you this responsibility did so because they believe you can do it. So have courage.
Tags: work
Scythe
A friend of our son’s was over and brought a board game that the three of us tried: Scythe. The game is set in an alternate-1920s scenario where several empires are competing for territory and resources. It has a steampunk aspect in that large robotic devices (“mechs”) can be constructed and deployed.
Here’s how the board looks at the end of a game.
It’s instantly apparent that Scythe has a high degree of complexity. That’s to be expected: it’s a strategy game. Players have to balance different kinds of resources - money, materials, work, base and extended fighting power, and reputation - to achieve several goals. Ultimately, the player who first fulfils six goals ends the game, but without necessarily also winning it: the ensuing final evaluation takes multiple factors into account that contribute to each player’s score.
At first, each player controls a small amount of territory and has no mechs at their disposal. Four of those can be built - once the necessary resources are available. These can be obtained by establishing new settlements in territory that yields resources when the player does a production activity. Initially, players are also unable to cross water bodies (rivers and lakes). For that to be possible, a player needs to build a certain type of mech that enables wading through rivers or submerging in and crossing lakes. Players can also build tunnels, which enable them to move about the board more swiftly.
When one player’s mechs and/or leaders encounter another’s, a fight will ensue (of course). The fighting mechanics have an interesting twist in that the visible fighting power is amplified by (invisible) add-on fighting power. This makes for interesting surprises. The likelihood of such encounters increases very swiftly with the number of participating players.
One nice twist is that players cannot perform the same moves in two subsequent rounds, necessitating some careful planning ahead. This brings me to the conclusion: Scythe is a nicely strategic game with a high fun factor. The strategic aspect is way less hefty than in, say, Terra Mystica, which makes Scythe much more accessible than the former. The competitive aspect is strong in Scythe, but does not dominate: players don’t spend all the time fighting; the emphasis is more on balancing resources and one’s approach.
Warmly recommended.
Tags: games