Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fix your tools

ochagavia.nl

Post reply on HN
Print view View original

91–100 of 100 posts

Re: Fix your tools

#91

Post by rileymichael »

thaumasiotes wrote: post #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) 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?

the tests are validating the plugin by executing actual builds in an isolated/temporary gradle project. debugging doesn't work out of the box because it's another process

https://docs.gradle.org/current/userguide/test_kit.html#sub:...

Re: Fix your tools

#92

Post by hinkley »

locknitpicker wrote: post #83
hinkley wrote: post #67

Earlier quoted context omitted.

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 don't like that 'yak shaving' has degenerated into a synonym for boondoggle. What do you mean "degenerated"? The term was always a synonym for procrastination and slacking off. It's just that in some cases the procrastinator/slacker argued otherwise. https://web.archive.org/web/20210112174206/http://projects.c...

> You see, yak shaving is what you are doing when you're doing some stupid, fiddly little task that bears no obvious relationship to what you're supposed to be working on, but yet a chain of twelve causal relations links what you're doing to the original meta-task.

What do you think a “causal relation[ship]” means? It means need, not avoidant behavior.

Re: Fix your tools

#93

Post by hinkley »

narag wrote: post #90
locknitpicker wrote: post #83

Earlier quoted context omitted.

> I don't like that 'yak shaving' has degenerated into a synonym for boondoggle. What do you mean "degenerated"? The term was always a synonym for procrastination and slacking off. It's just that in some cases the procrastinator/slacker argued otherwise. https://web.archive.org/web/20210112174206/http://projects.c...

Aside from the origin, there're situations in which you need to somehow shave the yak. Yes, it's about procrastination, but not of the task at hand. You procrastinate in some older task that's really blocking what you need to do now. It's chain procrastination. Oldest task blocks older task that blocks old task that blocks current task. It's evil because it overflows the task planning buffer. Also you get used to say…

The thing about the Mikado method is that you’re taking what from your perspective is a top down task and flipping it to bottom up. Which is for instance more amenable to refactoring, which is a bottom up task.

Sometimes when you get to the bottom you discover a shorter route backup to the top. The trap is that since you “already wrote the code” is seems a shame to delete it. But that code hasn’t been reviewed or vetted and “code is not the bottleneck”. You really do want to delete it because there’s a new version that’s 1/3 the code, and touches less of the existing system, and so will take less work to review and vet.

Re: Fix your tools

#94

Post by godelski »

nicbou wrote: post #7

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 think some people frame Yak shaving as a bad thing but I'm not sure it always is, and often even it is it is bad because you're resolving debt.

The example with Hal is funny, repeatable (I share it frequently), but also the tasks are (mostly) independent. It feels more like my ADHD. They're things that need to get done, easy to put off/triage, and but make doing other tasks difficult so maybe they actually shouldn't be put off?

But there's also the classic example we're doing something is a bigger rabbit hole than expected. Usually because we were too naïve and oversimplified the problem. An old manager gave me a good rule of thumb: however long you think something is going to take, multiply it by 3. Honestly I think that number is too low and most people miss the mark. I'm pretty sure he stole it from Scotty from Star Trek but forgot that even that is fantasy.

Personal I think you have to be careful about putting off the little things. It's a million times easier to solve little problems than big ones. So you have to remember that just because it's a little problem now doesn't mean it'll grow. The danger is that it's little, so you forget about it. The shitty part is that if you tell you boss they get upset at you if you solve it now but you look like a genius if you solve it after it festers. Invisible work...

https://scifi.stackexchange.com/questions/99114/source-of-sc...

Re: Fix your tools

#95

Post by godelski »

bonoboTP wrote: post #45
nicbou wrote: post #7

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

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 take…

I used to work as a physical engineer and a common task is "where's that tool?" People leave things at their work station and they float around and well... you can't keep track of things you can't see.

Manager finally got fed up (yes, he was the biggest offender lol) and we organized the whole shop. Gave every tool a specific place. Required tools to be put back. But it actually became easier to put back because everything had a home and we made it so their home was accessible (that's the trick).

Took us like a week to do and it's one of those things that seemed useless. But no one had any doubts of the effectiveness of this because it'd be really difficult to argue that we didn't each spend more than a week (over a year) searching for things. Not only that, it led to fewer lost and broken tools. It also just made people less frustrated and led to fewer arguments. Maybe most important of all, when there was an emergency we were able to act much faster.

So that's changed my view on organizing. It's definitely a thing that's easy to dismiss and not obviously worth the investment but even in just a year there's probably a single event that is solved faster due to the organization. The problem is you have to value the money you would have lost were you not organized. It's invisible and thus easy to dismiss. It's easier because everything else seems so important. But there's always enough time to do things twice and never enough time to do it right.

Re: Fix your tools

#96

Post by pavlus »

malux85 wrote: post #51
nicbou wrote: post #7

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

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"

Sometimes it's "who". Teams can ignore the elephant in the room, and be grateful if someone moves it away at the same time.

Re: Fix your tools

#97

Post by malux85 »

pavlus wrote: post #96
malux85 wrote: post #51

Earlier quoted context omitted.

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"

Sometimes it's "who". Teams can ignore the elephant in the room, and be grateful if someone moves it away at the same time.

Who is decided by the team leader, if who is unclear thats a management problem

Re: Fix your tools

#98

Post by narag »

hinkley wrote: post #93
narag wrote: post #90

Earlier quoted context omitted.

Aside from the origin, there're situations in which you need to somehow shave the yak. Yes, it's about procrastination, but not of the task at hand. You procrastinate in some older task that's really blocking what you need to do now. It's chain procrastination. Oldest task blocks older task that blocks old task that blocks current task. It's evil because it overflows the task planning buffer. Also you get used to say…

The thing about the Mikado method is that you’re taking what from your perspective is a top down task and flipping it to bottom up. Which is for instance more amenable to refactoring, which is a bottom up task. Sometimes when you get to the bottom you discover a shorter route backup to the top. The trap is that since you “already wrote the code” is seems a shame to delete it. But that code hasn’t been reviewed or vet…

Thank you, I had not hear of that method (my comment was more about wetware) but I doubt it will be unfamiliar to me, I've done everything refactor related, mostly successfully... when they let me (see https://news.ycombinator.com/item?id=47163985 )

Re: Fix your tools

#99

Post by Sophira »

Sophira wrote: post #10
nicbou wrote: post #7

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

Relevant XKCD: https://xkcd.com/349

Replying to myself because I actually found an even more relevant XKCD today: https://xkcd.com/1739

Re: Fix your tools

#100

Post by pavlus »

malux85 wrote: post #97
pavlus wrote: post #96

Earlier quoted context omitted.

Sometimes it's "who". Teams can ignore the elephant in the room, and be grateful if someone moves it away at the same time.

Who is decided by the team leader, if who is unclear thats a management problem

Why would they decide on "who", if nobody shows enough effort to signal on "what"? Whining doesn't count while the result is achieved, because "it works" and "don't fix it if it ain't broken".

It's a popular theme in corporate culture to avoid initiative, because you may be then made responsible. You can become responsible first on your own terms instead.

Post reply on HN