I would fix my tools but apparently my CPU is too old to run the Rust debugger which needs SSE4.
Fix your tools
71–80 of 100 posts
Re: Fix your tools
#72Earlier quoted context omitted.
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…
It's not about incentives; it's just bad management. As you said, the business just wants trees on trucks, so good management would realise that you need to spend some time sharpening axes to get trees on trucks quickly. It just seems to be something that a lot of software managers don't get. I don't think every company is like this though. E.g. Google and Amazon obviously have spent a mountain of time sharpening the…
There is some amount of time to spend on sharpening that, if you spend either more or less time sharpening, net amount of trees on trucks goes down. Smart businesses look for that amount. Really smart businesses know what the amount is, and make sure that they spend very close to that amount of time sharpening.
Re: Fix your tools
#73Good lesson! Can be tempting to fix the problems up the chain especially if the problem might happen again in the future. It depends on how much time, attention, and number of steps up the chain. Sometimes a work around keeps you moving forward but you miss some interesting (rare? learnings).
Re: Fix your tools
#74[dead]
Re: Fix your tools
#75> So I fixed the debugger (it turned out to be a one-line configuration change) That line links to the commit, which adds .withDebug(true) to an invocation of GradleRunner in a file named AllFunctionalTests.kt in the krossover project. My question is: Why can the software choose whether, when I run a debugger on it, the debugger will work? It can't, of course, so what's going on?
yea, good point. The debugger should be able to say up front. "This code isn't debuggable" or some warning to that effect.
Re: Fix your tools
#76Next time use AI.
Funny you got downvoted when the OP admitted that's what they did.
Re: Fix your tools
#77That's why this course is so important: https://missing.csail.mit.edu
Re: Fix your tools
#78> So I fixed the debugger (it turned out to be a one-line configuration change) That line links to the commit, which adds .withDebug(true) to an invocation of GradleRunner in a file named AllFunctionalTests.kt in the krossover project. My question is: Why can the software choose whether, when I run a debugger on it, the debugger will work? It can't, of course, so what's going on?
I also clicked through to that and was similarly confused. Not a Kotlin dev but this doesn’t really seem like fixing your tools? More like understanding them properly. I wouldn’t call a configuration change like this “debugging the debugger” as another comment mentioned.
I’d also like to know the answer to your question about what is going on. I know Java and maven but not kotlin or gradle, but wouldn’t a debugger be interfacing more at the JVM level?
Re: Fix your tools
#79Tools exist to be an energy/effort multiplier, so it's pretty intuitive that increasing that multiplier will make it easier to get more done.
In practice it's pretty difficult to find the balance between yak shaving and piling in unnecessary manual labour by just trying to do the work with existing (possibly poorly fitting) tools.
If you're planning to stick with your current tools for a long time, each 1% improvement compounds massively over time, so that balance is probably much closer to yak shaving than most people might realise.
Re: Fix your tools
#80Earlier quoted context omitted.
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.
Just be careful that 'better' doesn't just mean 'written by me'. I've seen that a lot too
More often than not I've seen this be the case. Refactoring as "rewrite using my idiomatic style, so that I can understand it", which does not scale across the team so the next engineer does the same thing.