I knew which vid's it gonna be before even clicking. Still hilarious.

This only happens when the tools have become so neglected that every single one is broken. You should still take the time to pay down that debt, and in the process learn the lesson to pay the debt in smaller chunks in the future.

You are going to pay it anyway, its not an "if" its a "when"

There is simply no general recipe for this. Sometimes I put my little tools and libraries in order and then I'm very productive with them and looking back it seems to have been the key enabler to the actual thing getting done. Other times I go dirty mode and just hardcode constants, copy code files under time pressure and looking back it is clear that getting to the same result with the clean approach would have taken months and the benefit for later tasks would be unclear.

I know some are tired of AI discourse, but I found AI can help to sharpen the tools but at the same time I find that my scope grows such that dealing with the tools takes just as much time but the tools have more features "just in case" and support platforms or use cases that I won't often need, but it feels easy enough to just do, but then as I said it still takes long in total.

It's all mostly an emotional procrastination issue underneath it. Though that can go both ways. Sometimes you procrastinate on thinking about the overall architecture in favor of just making messy edits because thinking about the overall problem is more taxing than just doing a small iteration, sometimes you procrastinate on getting the thing done in favor of working on more tightly scoped neat little tools that are easier to keep in mind than the vague and sprawling overall goals.

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

What looks like "wasting time on procrastination" may be actually "spending time on thinking". Thinking takes time.

Making messy edits is a bet on previous code quality. If you have paid off enough technical debt, you can take another "technical loan" and expect the rest of the owl to still function despite the mess being introduced. If things are already messy, there's always a risk to make the fess incomprehensible and failing in mysterious seemingly unrelated ways, with the only way to fix it being to git reset --hard to the prior point, and do a more right thing. But the time would have been wasted already.

My approach is usually to timebox it, and cut the losses if an acceptable solution is not yet in sight when the time runs out.

LOL! Well, somebody's gotta shave it!

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.

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.

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.

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

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.

I have mixed feelings here because on one hand I prefer the “axe” when programming (vim with only the right extensions and options). But for trees… chainsaws are quite a bit easier. Once it is chopped down, maybe rent a wood splitter.

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.

I always liked "The craftsman who wishes to do his work well must first sharpen his tools" by Confucius

Ah; if only this was really true. You can certainly get a computer into a permanently bricked state, especially an embedded device. Even a modern x86 machine can be basically toasted by a bad firmware update.

That’s the same video (but in a higher quality) as in the grandparent comment.

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

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

How'd you get the notice that this was submitted so quickly?

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.

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.

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?

If you watch your refers you'll see HN pretty easily. Could be even setup as a notification.

hello, it's me the Language Fairy.

Sometimes when people use an expression to convey an idea concisely , the details of the imaginary scenario within the expression are less important than the concept being expressed (just so long as the general shape of that scenario fits the thing being discussed).

To be more particular, the exact time it takes to sharpen an ax and chop down a tree are not important here.

I got a notification through F5 bot (https://f5bot.com/)

Good to know, thanks!