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)
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.
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.
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.
As Charlie Munger used to say “show me the incentives and I’ll show you the outcome”.
What are the incentives for these developers? Most businesses want trees on trucks. That’s the only box they care to check. There is no box for doing it with a sharp axe. You might care, and take the time to sharpen all the axes. Everyone will love it, you might get a pat on the back and a round of applause, but you didn’t check any boxes for the business. Everyone will proceed to go through all the axes until they are dull, and keeping chopping anyway.
I see 2 year old projects that are considered legacy systems. They have an insurmountable amount of technical debt. No one can touch anything without breaking half a dozen others. Everyone who worked on it gets reasonable rewarded for shipping a product, and they just move on. The business got its initial boxes checked and everyone who was looking for a promotion got it. What other incentives are there?
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.
Yes, but the answer depends on the bug. 100% test coverage leads to brittle tests, when any change leads to many broken tests, and fixing them is like repeating the change multiple times.
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.
If you're still dipping your toes into an LLM world, this is an excellent place to begin. I helped with a deploy at work the other day, we have some QA instructions (Notion). I pointed the LLM at one of the sections, asked it to generate task list for each section, and once that looked good, had to convert the processes into a set of scripts. The latest models make short work of scriptable stuff that you can use for debugging, testing, poking, summarizing, etc.
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
As with most continuous arguments in SWE, it really depends. I used to do a lot of debugging of random (i.e. not written by me) bioinformatics tools and being able to just fire up gdb and get an immediate landscape of what the issues were in the program was just invaluable.
Times when I was more familiar with the program or there were fewer variables to track it was less helpful
> "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.
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.
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.
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?
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?
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.
The caveat is that you might end up shaving a yak.
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
I knew which vid's it gonna be before even clicking. Still hilarious.
Weird. I happen to be watching Malcolm in the Middle and I find a link to Malcolm in the Middle
Relevant XKCD: https://xkcd.com/349
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)
And perhaps less well known to the Hacker News crowd, relevant Malcom in the Middle: https://www.youtube.com/watch?v=5W4NFcamRhM
That’s the same video (but in a higher quality) as in the grandparent comment.
LOL! Well, somebody's gotta shave it!
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.”
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.
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.
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.
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.
As Charlie Munger used to say “show me the incentives and I’ll show you the outcome”.
What are the incentives for these developers? Most businesses want trees on trucks. That’s the only box they care to check. There is no box for doing it with a sharp axe. You might care, and take the time to sharpen all the axes. Everyone will love it, you might get a pat on the back and a round of applause, but you didn’t check any boxes for the business. Everyone will proceed to go through all the axes until they are dull, and keeping chopping anyway.
I see 2 year old projects that are considered legacy systems. They have an insurmountable amount of technical debt. No one can touch anything without breaking half a dozen others. Everyone who worked on it gets reasonable rewarded for shipping a product, and they just move on. The business got its initial boxes checked and everyone who was looking for a promotion got it. What other incentives are there?
> The very desire to fix the bug prevented me from seeing I had to fix the tool first, and made me less effective in my bug hunt
Kenneth Stanley's book "Why Greatness Cannot Be Planned: The Myth of the Objective" is dedicated to this phenomenon
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.
https://xkcd.com/1205/
It's not just the tools, it is your tests. Most times you encounter and fix a bug, your first question should be 'Why didn't my tests catch this?'
Yes, but the answer depends on the bug. 100% test coverage leads to brittle tests, when any change leads to many broken tests, and fixing them is like repeating the change multiple times.
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.
If you like what you just read you should probably never install Emacs.
You're welcome.
If you're still dipping your toes into an LLM world, this is an excellent place to begin. I helped with a deploy at work the other day, we have some QA instructions (Notion). I pointed the LLM at one of the sections, asked it to generate task list for each section, and once that looked good, had to convert the processes into a set of scripts. The latest models make short work of scriptable stuff that you can use for debugging, testing, poking, summarizing, etc.
Using the debugger to understand/read code is invaluable. Seeing live stacks is so powerful compared to static analysis.
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
As with most continuous arguments in SWE, it really depends. I used to do a lot of debugging of random (i.e. not written by me) bioinformatics tools and being able to just fire up gdb and get an immediate landscape of what the issues were in the program was just invaluable.
Times when I was more familiar with the program or there were fewer variables to track it was less helpful
I’m talking about using debuggers not even to debug, but to familiarize yourself with the codebase and gain general understanding.
Measure of progress for me is formulating and answering questions. Sometimes trying to answer a question leads to formulating sub questions.
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.
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.
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.
Next time use AI.
OP here, thanks for submitting!
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
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?
How'd you get the notice that this was submitted so quickly?
I got a notification through F5 bot (https://f5bot.com/)
If you watch your refers you'll see HN pretty easily. Could be even setup as a notification.
"Give me six hours to chop down a tree and I will spend the first 4 sharpening the axe"
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.
I always liked "The craftsman who wishes to do his work well must first sharpen his tools" by Confucius
Also, FYI: Claude is very good at fixing tools
"first we shape our tools, then our tools shape us"