Quick bits:

• On Tuesday, the city was filled with people dressed in orange — the Dutch, who else — and I suddenly felt very self-conscious about my orange bike and orange backpack.

• I saw adorable baby ducks the other day. So tiny and so fluffy. Quack quack.

• I went to the embassy to get a new ID card. I arrived, drenched in sweat, so I imagine the photo on my ID card will be even weirder than the one on my recently obtained passport.

---

Shower thoughts:

• Free idea: a Star Trek-themed cover band for One Direction called the Prime Direction. Make it happen, folks.

• C++ was first called OOP-C but that sounded too much like “oopsie” so they changed it. (This is not true. I made it up. But wouldn’t it be fun if it were true?)

---

I published my Solitaire game. You can download it on itch.io.

If you try to open the game on macOS, you’ll get a warning that it can’t be verified.¹¹¹ This is because I don’t have a subscription to the Apple Developer Program, which is required to be able to properly distribute apps. But it’s 99 USD a year, which is a cost I cannot justify at the moment.  But there is a workaround for you: to open the macOS version, right-click on the application and choose “Open” from the drop-down menu.

If you’re interested in the source code:²²² I have a private Git repository on GitHub, but I am too self-conscious about the commit history to make it public.  download the .love file and change the extension to .zip, and then open that archive. LÖVE files are just ZIP files, so this works for any game made with LÖVE!

I’m still working on it! Among the features I want to implement are a bunch of different game modes. Here is one which I call “micro-solitaire,” which has a tiny tableau and only the cards 2, 3, 4 and A:³³³ Miniature game modes like these aren’t just fun for quick games, but they’re extraordinarily useful for testing during development. 

Hope you enjoy!

---

I had a dentist visit earlier this week, to fix a cavity in my wisdom tooth. Those teeth are hard to reach to clean properly!

It reminds me of a conversation I had with my dentist in Belgium, who suggested pulling all my wisdom teeth. When I asked why, she said that they could all get cavities. I had to mentally restrain myself from asking “well, why don’t you pull all my teeth” but I’m not quite that sort of cheeky bastard.

The cavity is fixed — and I have now also finally applied for dental insurance, which I think I should’ve done years ago.

---

I have received a job offer, and now the contract negotiation phase begins.

It’s been a long time in the making. I started looking for something new in December (or maybe even earlier — can’t remember) which means I’ve been looking for more than half a year already. The market is picking up, but the competition is fierce. I’ve gotten plenty of rejections where the feedback was that I was certainly qualified, but other candidates were just a little bit better suited for this particular role.

I have high hopes for this particular job. More details in the upcoming week­notes, no doubt!

---

More and more tech companies include a code review challenge in their interview process. I like this in theory, as it has the potential to be much better than a coding challenge at giving a clear picture of the interviewee’s capabilities and the interviewing company’s culture.

But code review challenges are also tricky to get right, because the way I review a code change differs vastly depending on the context:

• Is this change on a project that is not yet live? If so, it might not be worth reviewing in detail — or even reviewing at all —  for the time being. It can be worth delaying a code review until the project is more stable. This way, code reviews won’t create friction that slows the project down, and no time is spent on reviewing code that could very well never make it to production.

• What is the seniority level of the person making the code change? For a senior engineer, I might be much more terse in my review, foregoing excessive detail that would not be useful to my fellow engineer. For a junior engineer, however, I would be much more detailed, and even push for doing the code review in a face-to-face conversation instead, as it is much more effective and allows for a two-way conversation with a tight feedback loop.

• Is this code change adding only new code, or changing existing code? The stakes are much higher for existing code, and my reviews of changes to existing code tend to be much more thorough. I would specifically look for breaks in backwards compatibility and other types of regressions. For new code, especially code behind a feature flag, the stakes are much lower (see also my first point in this list).

My #1 priority when doing a code review is to not be a blocker when I can avoid it. It is more important to keep the pace of development going, than to make sure no code gets integrated until it is “perfect.” Code is always malleable; a code review does not set the code in stone, and there is no such thing as “perfect” code.

In general, I will approve a change unless it has critical problems:

• Will this change break anything? Specifically, can I spot any backwards-incompatible changes?⁴⁴⁴ I need to point out that the purpose of code review is not to find defects, and code reviews are particularly ineffective at preventing defects. 

• Will any parts of this code change be hard to modify in the future? (For example: it is problematic to tie JSON output keys to instance variable names through reflection.)

• Are there any security issues? Is authentication and/or authorization broken or missing?

(This list is not complete, but that is what comes to mind right now.)

When reviewing a code change, I’ll ask myself the question “does this change make anything worse?” — and if the answer is no, then I’ll generally approve the change.

There are a few types of issue that I might highlight, but not mark as blocker:

• Potential performance problems (unless it would lead to critical problems)

• Naming problems (unless they are so misleading that it could create critical problems down the road)

• Missing functionality (can always be added later)

While I find that this approach to reviewing code changes works really well, it tends to not resonate well in technical interviews.⁵⁵⁵ It frankly also does not resonate well at some employers, either. Shopify, for example, has the bizarre practice of “tophatting,” which requires the code reviewer to manually test out all changes — even if those changes are covered by end-to-end tests.  This is, as far as I can tell, because most code review challenges are about spotting all the problems in a given piece of code, rather than as a reviewer helping code get shipped.

As with any step in the job interview process, a code review challenge is something where you’ll have to play the game: say what the interviewer wants to hear, and not necessarily what you think. Shrug.

---

Every time I publish my week­notes, I create a new, blank week­notes entry, and that makes me anxious because I continuously have the fear of not having anything to say for the coming week.

Time and time again, this has proven to be false: my week­notes entries likely average a thousand words these days, and that is, in my opinion, a lot.

And besides, if there were a week where I had little interesting to say — so what? There is no bar that I need to meet. I do what I do because I like it, and so whatever I achieve is exactly right.

---

Entertainment:

• I purchased the remake of Riven,⁶⁶⁶ Riven (Cyan, 2024), published by Cyan.  and wow, it is good. There are quite a few changes, and most of the puzzle solutions I remember are no longer relevant. The changes, which encompass not just puzzles but worldbuilding in general, are definitely for the better.

  Also: the hand-written journals are amazing. Most games would go the easy way and go with a cheap handwriting font, but the in-game journals are genuine. It is so pretty and it stands out.⁷⁷⁷ It stands out to me at least, perhaps because I do my own daily journaling with fountain pen and paper. My handwriting is distinctly less pretty than that of the Riven journals, however. Perhaps my only complaint is that the in-game journals set unrealistic beauty expectations! 

• I resumed playing Cities Skylines II⁸⁸⁸ Cities: Skylines II (Colossal Order, 2023), published by Paradox Interactive.  with its big new game update, and the game is much more balanced now, and also a lot harder. It is genuinely a challenge now, which I like.

---

Toots and tweets:

• Mike Hoye on the purported skull of Mary Magdalene

Links:

• There are NOT 195 countries (Map Men, Jay Foreman)

• Why People Prefer More Pain (Veritasium): I’d be different!

• Analyzing Every Torture Scene in Call of Duty — All 46 of Them (Jacob Geller): I put off watching this video because of the title, but — like all of Jacob Geller’s videos — it was well worth my time.

• how dark mode killed good design (Answer in Progress): I’ve always had mixed feelings about dark mode, and I barely use it. This video has helped me understand why.

Tech links:

• Microfeatures I Love in Blogs and Personal Websites: Stuff to take inspiration from!

• Destroy AI (Ali Alkhatib)

• I Will Fucking Piledrive You If You Mention AI Again (Nikhil Suresh): Relatable.

• Bats Can No Longer Haunt Apple VR Headsets Via Web Exploit (Donald Papp for Hackaday): Well, that is absolutely terrifying. Good that it’s fixed!

• Interviewing people for jobs (xssfox): Good stuff!