Whenever I see this clip, my first thought is always that’s it’s a perfect manifestation of my ADHD. Which does of course heavily feature lack of prioritization. To me that false sense of dependent tasks (which in fact, aren’t) is one of the hallmarks.
I'm just trying to change this lightbulb (2014)
21–30 of 40 posts
Re: I'm just trying to change this lightbulb (2014)
#22That scene is FAR better as a video than a gif: https://www.youtube.com/watch?v=AbSehcT19u0
Re: I'm just trying to change this lightbulb (2014)
#23There's definitely a lesson in prioritization in there, as these task are mostly not dependent on each other. Hal already had the light bulb in his hand when he noticed the loose shelf and he already had the tools to fix the shelf when noticing the squealing. The only dependency in there was fixing the car to get WD40 and fix the drawer. From a business perspective, he could have finished the first two tasks before g…
Re: I'm just trying to change this lightbulb (2014)
#24Earlier quoted context omitted.
Right the management would be in charge of course. They would decide whether a given TDEBT-issue should be worked on as a "secondary project" perhaps or not. I think they would still appreciate having the knowledge of the technical debt their company is taking on. You don't need to do anything about (technical or other kind of) debt until you have the money and will to get rid of it. But it's still valuable to know a…
I do agree... but I'm a FTE in that's been in my current position for 7 years. I'm not worrying about which way the burn down charts go (and sigh when the estimation is removed - well, at least it's in the history). I occasionally think about how to implement PEF/REV ( https://www.fincher.org/tips/General/SoftwareDevelopment/Bug... - though https://lostgarden.home.blog/2008/05/20/improving-bug-triage... is another ap…
> technical debt is ignored at nearly every level.
I agree. Technical debt is bad/evil and many (short-sighted) managers try to see no evil hear no evil speak no evil.
They don't want to tell their bosses the software is a maintenance nightmare which will cost the company dearly in the future.
I think we need a new better notion of "code ownership". People who write the code should in some sense "own" it. Only that way they will have a true incentive to make code maintainable and to minimize technical debt. The manager should of course own their shared of the code-ownership. They helped decide what should be in it and what not.
Re: I'm just trying to change this lightbulb (2014)
#25There's definitely a lesson in prioritization in there, as these task are mostly not dependent on each other. Hal already had the light bulb in his hand when he noticed the loose shelf and he already had the tools to fix the shelf when noticing the squealing. The only dependency in there was fixing the car to get WD40 and fix the drawer. From a business perspective, he could have finished the first two tasks before g…
https://wondermark.com/464/
Broken SSL
Re: I'm just trying to change this lightbulb (2014)
#26Earlier quoted context omitted.
In the original yak shaving story, every next step was not an optional distraction but was a prerequisite to doing the previous thing; often caused by 'tech debt' (e.g. the protagonist couldn't borrow the tool you needed from your neighbor because he hadn't fulfilled an earlier obligation, and needed the yak hair to do that)
Don’t Shave That Yak! - https://seths.blog/2005/03/dont_shave_that/ (this is the original with the borrowed EZPass) 2020 https://news.ycombinator.com/item?id=21930441 (81 comments) Don’t shave that yak – God loves lazy programmers https://petewarden.com/2010/06/26/dont-shave-that-yak-god-lo... 2012 https://news.ycombinator.com/item?id=4034034 (3 comments)
The third link has a link to http://www.catb.org/%7Eesr/jargon/html/Y/yak-shaving.html
> [MIT AI Lab, after 2000: orig. probably from a Ren & Stimpy episode.] Any seemingly pointless activity which is actually necessary to solve a problem which solves a problem which, several levels of recursion later, solves the real problem you're working on.
So yeah, both in your first link (mostly) and here: prerequisite - something you have to do, not a side thing like the clip of Hal. That GIF has apparently been misused this whole time, muddying the issue.
(The first link ends with the equivalent of "you can avoid yak shaving by introducing technical debt")
Re: I'm just trying to change this lightbulb (2014)
#27I really like this analogy. Its very prevalent in many teams. Tho I would say experienced developer is able to recognize business needs and how much work has to be put into something NOW. Being able to leave stuff open for fixing later is a crucial skill. I would even go as far as say that not having this skill automatically discredits someone from a Senior position.
sure. and when you're done they throw a new project at you with another arbitrarily tight deadline and it never gets fixed. that's how we accumulate the debt, because we are focusing on the crucial things.
Re: I'm just trying to change this lightbulb (2014)
#28I think what could help is using JIRA -like issues-reporting system dedicated not to publicly observable problems ("bugs") with the software application, but internal code-design issues which can be seen to possibly cause detrimental issues with software maintenance later. In other words issues which can be categorized as technical debt. Technically this could be implemented using the same software that is used for b…
But would management approve of spending time on reporting and possibly
fixing design issues? Well why not because if the knowledge of the issues
exists only in the head of some developers, it is not really owned by the
company. Whereas if it was reported in an issue-tracking system it would
become official part of the IP owned by the company, increasing its value.
Using such a system would seem to make a lot of sense to me. Perhaps
companies are already doing it?
Re: I'm just trying to change this lightbulb (2014)
#29The best time to pay off most debt is: as soon as possible. The sooner, the easier.
A bad file format, if shipped, will cause decades of debt. Same for critical APIs. Not all debt is this way - you need to identify what debt will multiply and tackle that type of debt ASAP.
Startups iterate fast because they have the least debt. If you want to maintain your edge, you can't let debt grow.
Re: I'm just trying to change this lightbulb (2014)
#30Is it technical debt though? I always thought of technical debt as being the ongoing problems caused by taking short cuts (specifically: borrowing time from the future to avoid spending time now)
In this example it would have been tech debt if he couldn’t find a light bulb so he plugged a lamp into an extension cord and draped it over the floor… it would work, but eventually someone will trip over the cord.
None of the activities that distracted Hal were essential to changing the light bulb. It wasn’t tech debt and it wasn’t yak shaving. It was just a lack of discipline to do the first job first.
Sorry to be so literal but this is HN. I still thought the clip was funny!