I enjoyed reading this because it reminded me of a moment of hubris as junior developer. I was working with a complicated data structure I wanted to visualize, so I decided to write some quick code to basically read the data structure and output a graph as rectangles and lines connecting them.
I was chastened by the complexity of just drawing the lines between boxes so that they didn't overlap (as much as possible) and were drawn on facing sides (one of the later problems discussed in the article). I don't recall how I did it, but I do remember a sudden refresher on matrix multiplication.
It drove home how simple things can be more complicated than you might expect.
EDIT: also, I appreciated the way the article was written. No cruft.
I've had similar experiences on many projects. You start out thinking something is going to be super simple and you provide estimates that match your naive design and later find it'll take 2.5x-5x longer than you wanted. It's definitely humbling.
Nowadays when I have new work that has a lot of unknowns, I try to jump in and create a proof of concept as quickly as I can, even if it requires a ton of hacks. I want to know right off the bat if there's something obvious that's going to make the task take much longer than I wanted.
I was chastened by the complexity of just drawing the lines between boxes so that they didn't overlap (as much as possible) and were drawn on facing sides (one of the later problems discussed in the article). I don't recall how I did it, but I do remember a sudden refresher on matrix multiplication.
It drove home how simple things can be more complicated than you might expect.
EDIT: also, I appreciated the way the article was written. No cruft.