←back to thread

-2000 Lines of code

(www.folklore.org)
499 points xeonmc | 2 comments | 25 Jun 25 19:53 UTC | HN request time: 0.412s | source
Show context
bironran ◴[25 Jun 25 22:55 UTC] No.44382555[source]▶
One of my best commits was removing about 60K lines of code, a whole "server" (it was early 2000's) with that had to hold all of its state in memory and replacing them with about 5k of logic that was lightweight enough to piggyback into another service and had no in-memory state at all. That was pure a algorithmic win - figuring out that a specific guided subgraph isomorphism where the target was a tree (directed, non cyclic graph with a single root) was possible by a single walk through the origin (general) directed bi-graph while emitting vertices and edges to the output graph (tree) and maintaining only a small in-process peek-able stack of steps taken from the root that can affect the current generation step (not necessarily just parent path).

I still remember the behemoth of a commit that was "-60,000 (or similar) lines of code". Best commit I ever pushed.

Those were fun times. Hadn't done anything algorithmically impressive since.

replies(13): >>44382607 #>>44383577 #>>44383660 #>>44384143 #>>44384528 #>>44384875 #>>44385261 #>>44385550 #>>44385861 #>>44386549 #>>44386714 #>>44386823 #>>44388515 #
ifellover ◴[26 Jun 25 05:49 UTC] No.44384528[source]▶
I’m a hobby programmer and lucky enough to script a lot of things at work. I consider myself fairly adept at some parts of programming, but comments like these make it so clear to me that I have an absolutely massive universe of unknowns that I’m not sure I have enough of a lifetime left to learn about.
replies(6): >>44384974 #>>44385333 #>>44385697 #>>44385739 #>>44386666 #>>44388151 #
1. neilv ◴[26 Jun 25 09:35 UTC] No.44385697[source]▶
You could've figured out this one with basic familiarity with how graphs are represented, constructed, and navigated, and just working through it.

One way to often arrive at it is to just draw some graphs, on paper/whiteboard, and manually step through examples, pointing with your finger/pen, drawing changes, and sometimes drawing a table. You'll get a better idea of what has to happen, and what the opportunities are.

This sounds "Then draw the rest of the owl," but it can work, once you get immersed.

Then code it up. And when you spot a clever opportunity, and find the right language to document your solution, it can sound like a brilliant insight that you could just pull out of the air, because you are so knowledgeable and smart in general. When you actually had to work through that specific problem, to the point you understood it, like Feynman would want you to.

I think Feynman would tell us to work through problems. And that Feynman would really f-ing hate Leetcode performance art interviews (like he was dismayed when he found students who'd rote-memorize the things to say). Don't let Leetcode asshattery make you think you're "not good at" algorithms.

replies(1): >>44390614 #
2. bironran ◴[26 Jun 25 19:45 UTC] No.44390614[source]▶
I despise leetcode interviews. These days, with coding LLMs, I see them as even less relevant than they were before.

Yet, you ask someone "how do you build an efficient LFU" and get blank stares (I just LOVE the memcache solution of regions and probabilistic promotion/demotion).