[dead]
And this is why I just love Airflow so much.
Fix your tools
61–70 of 100 posts
Re: Fix your tools
#62Excellent advice. I try to follow it in my daily work, with some success.
Excellent follow-up advice: now stop fixing your tools, and go fix your actual problem instead. I try to follow it in my daily work, with noticeably less success.
Re: Fix your tools
#63Also, FYI: Claude is very good at fixing tools
That's what I actually used to fix this one! I'm not too deep into the JVM ecosystem, so I gave Claude a try just in case... and it fixed it :)
Btw I didn't mention it in the blog post, because I think that would have derailed the conversation (after all, the point of the article is not "use LLMs", but "fix your tools"). In any case, I agree that LLMs can make it easier to fix the tools without getting side-tracked.
Re: Fix your tools
#64Earlier 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…
Early on in Amazon’s history (long before same day shipping), they added a feature that would tell you, on a product page, whether you had recently bought that same product. The metrics spoke loud and clear: it caused purchase count to go down. Human common sense about the customer’s experience overruled the data and they have some variation of that feature to this day. That’s the “customer obsession,” but unfortunately most businesses only copy the “data driven”.
Re: Fix your tools
#65> 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)
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?
Re: Fix your tools
#66[dead]
https://xkcd.com/1205/
This comic ("Is it worth the time?") is categorically incorrect, because it assumes a static system. Instead, when you make something take less time, you can do it more often. Sometimes, much more often. See: Jevon's Paradox. You would never have known that CI/CD was a useful strategy since you didn't optimize your build because you only did a full build when you released.
Re: Fix your tools
#67The 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 don't like that 'yak shaving' has degenerated into a synonym for boondoggle.
Some explanations of yak shaving split it into a complex form of procrastination and also necessary annoyances - friction - obstacles.
Sharpen your Tools often falls into the latter category, and it's always useful to question whether those 'necessary annoyances' are actually necessary.
It is, like you say, not always necessary to tackle those annoyances right now. But it is a situation where both the Campsite Rule and the Rule of Three have some domain. As a person whose entire job is about writing code to replace tedious and error-prone human tasks, you need to interrogate yourself any time you start thinking, "This is my life now." Because if anyone has the power to say 'no', it's us.
It's always worth spending 12-15 minutes most times you do a task that you have to do over and over again in service of trying to reduce the task from ten minutes to five or to zero. The reward for engaging in the task more fully rather than putting it off until it has to be done is that you're working toward a day when maybe you don't have to do it at all (you've automated it entirely or you've made it straightforward enough to delegate).
Hal's example is so funny because he's using both arms to scoop in everything from Column A and Column B at the same time. Everybody gets a laugh. A couple of those tasks actually had to be done. A couple could have gone on the shopping list.
Re: Fix your tools
#68The 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 don't like that 'yak shaving' has degenerated into a synonym for boondoggle. Some explanations of yak shaving split it into a complex form of procrastination and also necessary annoyances - friction - obstacles. Sharpen your Tools often falls into the latter category, and it's always useful to question whether those 'necessary annoyances' are actually necessary. It is, like you say, not always necessary to tackle t…
I always saw it as being multiple subtasks deep into a problem, or opening too many parentheses. Yak shaving does not imply that you're wasting time, only that the task involves solving problems that feel remote to your initial objective.
For example, I want to use ES6 modules on my website, then esbuild to compile them. However masonry.js breaks it, and instead of fixing it, I decided to get rid of it, but that breaks the layout of the /guides page, and while I'm there I might as well reorganise the list of guides.
So now I'm on week 2 of the switch to ES6, but I ended up redesigning a page, writing a bunch of tests, fixing unrelated UI bugs, making a few UX fixes, making changes to the static site generator, etc etc.
I get to do that because I'm self-employed and thinking long-term, but if I was at $PREVIOUS_EMPLOYER doing sprints, my boss would be wondering why I spent an entire sprint on this simple task.
Re: Fix your tools
#69Engineering 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.”
You semi-regular reminder that Kent Beck was one of the XP brain trust behind the Chrysler Comprehensive Compensation System disaster.
https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...
Re: Fix your tools
#70Earlier quoted context omitted.
[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.
people are so far removed from the ax that they don't realize my point. I'm sure the people Lincoln was talking to had more knowledge and so would get a different picture from the modern reader.