This comic definitely speaks to me on a deep emotional level, but at the same time one of the things I like so much about computers is they're essentially unbreakable.
Not that you can't get one into a non-working state, that is, of course, trivial but with the lone exception of deleting data, you can always restore a computer, the only tool being needed is some kind of boot disk.
(Compare that to breaking a literal hammer, you'd need a pretty specialized set of tools handy if you wanted to actually restore it)
That’s the same video as in the grandparent post (but in a higher quality).
kurthr 1 hours ago [-]
LOL! Well, somebody's gotta shave it!
highfrequency 1 hours ago [-]
Engineering is a continual lesson in axe-sharpening (if you have 6 hours to chop down a tree, spend the first 4 sharpening your axe).
My favorite framing, from Kent Beck: “first make the change easy, then make the easy change.”
qup 9 minutes ago [-]
I don't think you spend all 4 hours up front, friend.
In my experience you're going to want a sharp axe later in the process, once you've dulled it.
Not sure if that ruins the analogy or not.
ShellfishMeme 13 minutes ago [-]
This approach is also what I'm still missing in agentic coding.
It's even worse there because the AI can churn out code and never think "I've typed the same thing 5x now. This can't be right.".
So they never make the change easy because every change is easy to them... until the lack of structure and re-use makes any further changes almost impossible.
goda90 57 minutes ago [-]
I recently got assigned to enhance some code I've never seen before. The code was so bad that I'd have to fully understand it and change multiple places to make my enhancement. I decided that if I was going to be doing that anyway, I might as well refactor it into a better state first. It feels so good to make things better instead of just making them do an extra thing.
IshKebab 16 minutes ago [-]
Most of my colleagues are content to spend 50 hours chopping up the tree with a pipe. We don't have time to spend making things work properly! This tree has to be finished by tomorrow! Maybe after we've cut up this forest, then we'll have a bit of spare time to sharpen things.
maccard 12 minutes ago [-]
I aim for the Boy Scout rule - always leave things better than you found it. It’s always a balance and you have to not lose the forest for the trees. Always ask what is the end goal, and am I still moving forward on that.
wangzhongwang 49 minutes ago [-]
Totally agree with this. I spent way too long fighting my dev environment last month before I finally sat down and properly configured everything. The ROI on fixing your tools is insane - what took me 2 hours of yak-shaving per week now takes zero.
The hard part is convincing yourself it's worth the upfront time. There's always "real work" that feels more urgent than fixing your build script or editor config.
If you like what you just read you should probably never install Emacs.
You're welcome.
yegle 31 minutes ago [-]
My friend once told this joke:
> "A good programmer, when encountering a debugger bug," he paused, cleared his throat, and said solemnly: "should immediately drop the program they're debugging and start debugging the debugger instead!" The auditorium once again erupted in thunderous applause.
unkulunkulu 1 hours ago [-]
Using the debugger to understand/read code is invaluable. Seeing live stacks is so powerful compared to static analysis.
bluGill 45 minutes ago [-]
I'm not convinced. At times it can be valueable, but at times you can go around in circles, changing checking variables/break points all the time, but never finding the problem. Often thinking about the problem and what is important is what you need. Playing in the debugger is fun and feels like progress, but it can just be a distraction from understanding the real problem.
I'm not completely against debuggers, but in my experience they only are useful either to get the trace of the problem when it first occurs and then use static analysis until you have a theory the debugger can prove/disprove - but only prove/disprove that theory don't keep looking: you will feel productive but in fact be spinning circles
chihuahua 1 hours ago [-]
Ugh, this brings on flashbacks to when I had to work with Ruby, and the *** debugger would break with every single release. The RubyMine IDE that 45% of the company used was based on some bizarre custom Ruby gems to enable debugging, and that crap would take a month to be fixed by JetBrains. 10% used VSCode where debugging would sometimes work and sometimes not.
stivikivi 2 hours ago [-]
This is the reminder I needed. For some projects the python LSP I am using in Neovim just breaks sometimes. Always so frustrating when I start fuzzy searching instead of just jumping to a declaration or restart it.
mentalgear 26 minutes ago [-]
"first we shape our tools, then our tools shape us"
wofo 2 hours ago [-]
OP here, thanks for submitting!
bpavuk 2 hours ago [-]
hey, the idea of Krossover is actually dope! my sole question is, why does it exist?
I understand that one might call Rust from Kotlin for performance reasons (I do that often, Mozilla does, some others too), but Kotlin from Rust? where would it be useful?
no snark or subtext here, I'm genuinely curious
wofo 52 minutes ago [-]
Calling Kotlin from Rust (and other languages) is useful when you want access to an existing Kotlin codebase and would rather avoid creating a full-blown port. I guess most people don't do things like this because creating bindings for languages that are not C (or C-like) is usually cumbersome. Krossover is trying to fill that gap for Kotlin. Does that make sense?
obsidianbases1 2 hours ago [-]
How'd you get the notice that this was submitted so quickly?
If you watch your refers you'll see HN pretty easily. Could be even setup as a notification.
d--b 1 hours ago [-]
Also, FYI: Claude is very good at fixing tools
r1cka 2 hours ago [-]
"Give me six hours to chop down a tree and I will spend the first 4 sharpening the axe"
bluGill 41 minutes ago [-]
I takes less than 2 hours to chop down a tree [of the type Lincoln would have been chopping down with an ax - trees elsewhere may be different]. It doesn't take 4 hours to sharpen an ax unless you were mistreating it either though. So given 6 hours to chop down a tree I'd spend 15-20 minutes sharpening my ax (divided into several 2-5 minute sessions when I need a break anyway), 2 hours chopping the tree, and the remaining 3.5 hours reading a book. But I keep my tools in good shape so I don't need a long presharpending before the first cut.
I'm not physically in good enough shape to swing an ax for 2 hours, but I've done enough with an ax to know the above is right if I was in physical shape to do it.
phendrenad2 30 minutes ago [-]
I always liked "The craftsman who wishes to do his work well must first sharpen his tools" by Confucius
Rendered at 18:28:06 GMT+0000 (Coordinated Universal Time) with Vercel.
More often than not I end up three or four tasks deep while trying to fix a tiny issue.
https://m.youtube.com/watch?v=_UZFI-8D5uA
Not that you can't get one into a non-working state, that is, of course, trivial but with the lone exception of deleting data, you can always restore a computer, the only tool being needed is some kind of boot disk.
(Compare that to breaking a literal hammer, you'd need a pretty specialized set of tools handy if you wanted to actually restore it)
My favorite framing, from Kent Beck: “first make the change easy, then make the easy change.”
In my experience you're going to want a sharp axe later in the process, once you've dulled it.
Not sure if that ruins the analogy or not.
So they never make the change easy because every change is easy to them... until the lack of structure and re-use makes any further changes almost impossible.
The hard part is convincing yourself it's worth the upfront time. There's always "real work" that feels more urgent than fixing your build script or editor config.
You're welcome.
> "A good programmer, when encountering a debugger bug," he paused, cleared his throat, and said solemnly: "should immediately drop the program they're debugging and start debugging the debugger instead!" The auditorium once again erupted in thunderous applause.
I'm not completely against debuggers, but in my experience they only are useful either to get the trace of the problem when it first occurs and then use static analysis until you have a theory the debugger can prove/disprove - but only prove/disprove that theory don't keep looking: you will feel productive but in fact be spinning circles
I understand that one might call Rust from Kotlin for performance reasons (I do that often, Mozilla does, some others too), but Kotlin from Rust? where would it be useful?
no snark or subtext here, I'm genuinely curious
I'm not physically in good enough shape to swing an ax for 2 hours, but I've done enough with an ax to know the above is right if I was in physical shape to do it.