4 ms·
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,
by nescioquid 5y ago
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.
- pintxo 5y agoIf you want to add another level of complexity, add (non-overlapping) labels to your boxes and arrows ...
- deleted 5y ago[deleted]
- kazinator 5y agoToday (or twenty years ago, for that matter) I'd just output the data structure in graphviz syntax and throw it at the dot tool.
- db48x 5y agoThat’s what I do too. Then I make the graph output into a test.
- allenu 5y agoI'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.