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.
Fix your tools
41–50 of 100 posts
Re: Fix your tools
#42Engineering 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.”
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?
Re: Fix your tools
#43Using 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 i…
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
Re: Fix your tools
#44"Give me six hours to chop down a tree and I will spend the first 4 sharpening the axe"
[flagged]
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.
Re: Fix your tools
#45The 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
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.
Re: Fix your tools
#46My version of this is ‘always be toolin’, but then of course one must use judgement lest it be better to just get on with it.
Re: Fix your tools
#47Re: Fix your tools
#48Earlier quoted context omitted.
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…
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.
Re: Fix your tools
#49Engineering 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 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.
Re: Fix your tools
#50Earlier quoted context omitted.
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…
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 their own axes. Amazon even made an axe so sharp they could sell it to half the world.