Writing more in 2026

I plan to write a bit more this year. Nothing too ambitious - just capturing thoughts as they come, publishing short monthly updates to reflect on how things are evolving. Writing helps me. It forces me to think more clearly, and I have been doing it too little lately.
I’ll try to use as little AI here as I can - as I want my thoughts to be my own, no matter how wrong they are. I will still use it for grammar check and Latex.

So here’s the first one.

Where You Split the Problem Matters

I’ve been playing with The Elements of Computer Systems (nand2tetris), where you build an entire computer from the ground up. It’s a fantastic book. You take NAND and from it construct NOT, AND, OR, and then keep going - building increasingly complex chips until you have a full working machine.

The way I understand hardware engineers build chips is by using some sort of simulation or a specialized language to model the structure and behavior of a digital circuit. In nand2tetris, we use a simplified version of Hardware Description Language, where you can describe and simulate chips. The IDE looks something like this:

You can try it out yourself here: https://nand2tetris.github.io/web-ide/chip/

I got stuck on Mux chip, and where exactly I failed is more interesting to me than the problem itself.

A multiplexer is simply naive: you have two inputs (a and b) and a selector bit (sel). If sel is 0, output a. If sel is 1, output b. That's it.

The standard approach I take is to write out the truth table and derive a Boolean formula. So I did. But here’s where I went wrong - I decided to group the truth table by the inputs (a, b) instead of sel. For some reason, it felt natural: ‘when not a, then some logic with b and sel.. when a, then some other logic..’. I was essentially treating the if-statement nature of the problem as secondary, splitting on the wrong predicate.

The formula I got was technically derivable, and perhaps I could get out to the right result, but it felt too tricky to group in the chips I could use, like NAND, AND, NOT, OR. It got to the point when it was hard to simplify and even harder to verify its correctness. Something was wrong, but I got stuck and spent much more time than needed conquering my formula.

After some time, I decided to step back and to look at the problem differently. Now, instead of the truth table, I re-read the plain English description (deeply for the first time, hah):

if sel is 0, output a; if sel is 1, output b;

Damn, that was so obvious now, you have two clean cases split by sel. So I regrouped the table by sel. And the formula writes itself:

out = Not(sel) And a) Or (sel And b)

That’s it. Naively simple. Two AND gates, one NOT gate, and one OR.

The takeaway

Two things I got out of it. First, when you’re stuck, try looking at the problem from a different angle. I was locked for too long into one representation and couldn’t see the simplicity hiding in it. Switching to natural language just made it so obvious.

Second, in divide and conquer, we tend to focus on the conquer part. In my case divide is where all the magic happened. Often, how you split the problem determines whether the rest feels elegant or not.

tl;dr I still don't regret a single second spent sitting and struggling with it. I also don't feel dumb for not coming up with the solution much faster. Just a few years ago, I would have been very annoyed not being able to solve it in minutes. Today I feel it's a healthier approach — but I should still keep an eye on staying ambitious while keeping it healthy.