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

The Code Is the To-Do List

executeprogram.com

Post reply on HN
Print view View original

61–70 of 80 posts

Re: The Code Is the To-Do List

#61

Post by ParetoOptimal »

arinlen wrote: post #35
Groxx wrote: post #25

Earlier quoted context omitted.

It was just to ensure it wasn't forgotten. If it's "long term", stick it for a year out or something, it's fine. Truly timeless? Year 2999 works pretty well, or just don't use "todo" because it apparently isn't gonna happen. We fairly often used it for stuff like "X should be upgraded to fix Y by now, see if this hack is still necessary". If was not, just push it out and check again then. Or do whatever else might be…

> It was just to ensure it wasn't forgotten. Why don't you just add a ticket in a ticket backlog, then?

Most of the time it's not possible to trust items you add to the backlog related to tech debt will actually get done.

Why make lists that will never be completed?

Or put another way, there is no pain that can't be avoided by ignoring the backlog.

You can only ignore these TODOs until your build fails, then you have to reflect on whether to do them, push them into the future, or delete them.

I think this works because it really makes backlog grooming a group activity where everyone is involved, so everyone feels they have a say in setting priority.

Re: The Code Is the To-Do List

#62

Post by arinlen »

ParetoOptimal wrote: post #60
KronisLV wrote: post #43

Earlier quoted context omitted.

> But it never does, there's always some critical new feature sales wants, or something bigger on fire. Then clearly it is not deserving of your attention according to the powers that be. If it is, then talk in the language that these parties understand better/prefer: bump up the priority of the task, add a "blocked by" or "has to be done after" link to these other issues in the tracker and tell the rest of the teamm…

> If more pushback is necessary, then do it doing any estimates (provided that you have any): "Task $FOO will take X% more time due to $BAR not being finished and slowing down development. Consider doing $BAR first and $FOO should become less complex then." Creating those estimates alone is more than the sum of total work usually. Then the problem of convincing others is itself typically more than the sum of total wo…

> Creating those estimates alone is more than the sum of total work usually.

If that was true then it would be trivial to just push a pull request and update the ticket to review it.

> Then the problem of convincing others is itself typically more than the sum of total work.

When that happens, that's the universe trying to explain to you that you're wasting your time with stuff that does not add tangible value.

This does not change with petty office politics moves such as ignoring your team's best judgement and continue pushing for something that was already decided to be a waste of time.

Re: The Code Is the To-Do List

#63

Post by DennisP »

KronisLV wrote: post #43
srer wrote: post #38

Earlier quoted context omitted.

I do that, create the ticket. I want to believe it means one day we will do that TODO, it'll beat the priority of all the other tickets in the queue. But it never does, there's always some critical new feature sales wants, or something bigger on fire. I still create the tickets, as a kind of cathartic process, a confession to the jira gods, I have sinned and half assed something. Please take this ticket as my penance…

> But it never does, there's always some critical new feature sales wants, or something bigger on fire. Then clearly it is not deserving of your attention according to the powers that be. If it is, then talk in the language that these parties understand better/prefer: bump up the priority of the task, add a "blocked by" or "has to be done after" link to these other issues in the tracker and tell the rest of the teamm…

That's definitely the way management wants you to work, and it's worth trying to see how it works out. But in many cases it's not in your personal best interest.

In those cases, there's a way to keep management happy and yourself too:

1) Realize that when management asks for time estimates, they don't want your median estimate, because you'll be late half the time and that messes up their scheduling. Give them an estimate that you'll meet at least 90% of the time.

2) This means in almost half the cases, you'll have extra time. You can give some of that back to management, but use some of the time to fix technical debt. The more debt, the more of the time you spend fixing it.

3) With less technical debt, you can speed up your estimates and still be at that 90% level. Now you're delivering as much as if you let management fill your time in the first place. Your code magically has fewer bugs, there aren't many unexpected delays, and you almost always meet your deadlines. But you still have plenty of free time to improve things even more, develop your skills, etc.

As a bonus, you have more of a sense of agency, which is an important factor in feeling happy at work.

Re: The Code Is the To-Do List

#64

Post by jandrewrogers »

planede wrote: post #55
Groxx wrote: post #6

One of my favorite small linters I made on a previous team: // todo 2022-06-09 something ^ on that date, it'd fail the linter, and print the comment. Every TODO needed a date. Got a failure and need to get past it for now? No problem: bump the date for a week or something. Now at least two people are aware that it exists (author+reviewer)... and one is in the git history for that line. Makes it rather easy to trace b…

I don't get why so many people likes this. No, I don't want a suddenly failing pipeline on master because of an expiring TODO. A better approach is for a TODO to be required to reference a ticket, and add a ticket. Prioritization should happen in your issue tracking, not in the code.

Many TODOs (the majority in code bases I've worked on that had them) do not require any action, they are annotations to the code base about future potential development or research. Addressing the TODO, either by removal or implementation, could be deferred indefinitely with no consequences and often are. These aren't things that need to be fixed per se. For example, I've seen TODOs widely used to document optimization or generalization opportunities in the code base.

You do not want to pollute your ticketing system with myriad TODOs. They are not meaningfully actionable and they tend to require very local code context so it is easier to understand them as code annotations.

Re: The Code Is the To-Do List

#65

Post by ParetoOptimal »

arinlen wrote: post #62
ParetoOptimal wrote: post #60

Earlier quoted context omitted.

> If more pushback is necessary, then do it doing any estimates (provided that you have any): "Task $FOO will take X% more time due to $BAR not being finished and slowing down development. Consider doing $BAR first and $FOO should become less complex then." Creating those estimates alone is more than the sum of total work usually. Then the problem of convincing others is itself typically more than the sum of total wo…

> Creating those estimates alone is more than the sum of total work usually. If that was true then it would be trivial to just push a pull request and update the ticket to review it. > Then the problem of convincing others is itself typically more than the sum of total work. When that happens, that's the universe trying to explain to you that you're wasting your time with stuff that does not add tangible value. This…

> When that happens, that's the universe trying to explain to you that you're wasting your time with stuff that does not add tangible value.

That's not always true, especially if it's tangible value that takes more than a week or two to see.

Tech is very biased to short-term rewards that cost more in the long term.

> This does not change with petty office politics moves such as ignoring your team's best judgement and continue pushing for something that was already decided to be a waste of time.

If this happens, it's usually because that team is conflict avoidant or only minimally addresses surface level concerns in disagreements.

If you just want to get your paycheck, that works fine. If you are interested in improving, this is frustrating because the correct or more correct answers are never worth the time.

Re: The Code Is the To-Do List

#66

Post by ParetoOptimal »

arinlen wrote: post #56
cseleborg wrote: post #53

Earlier quoted context omitted.

That TODO item is just the receipt for a few bytes of technical debt you took with the universe. A few bytes is nothing compared to Management's roadmap, so it gets ignored. But have no doubt: the universe always returns to claim its technical debt...

> That TODO item is just the receipt for a few bytes of technical debt you took with the universe. It really isn't. A TODO item that you feel does not justify a ticket is just a subjective nice-to-have expressed as noise/a declaration of intent with no intention to deliver, which ultimately only results in noise. It's not even technical debt. At most, it's a pledge to goldplate something without being able to argue a…

> At most, it's a pledge to goldplate something without being able to argue any tangible upside.

One person's gold plating with no tangible upside is another person's not be woken up by pagerduty at 3am ;)

Re: The Code Is the To-Do List

#67

Post by 100011_100001 »

I dislike //TODOs for the same reason I dislike commented out code.

It adds noise to the code with no actual benefit. If a TODO is outdated it actually becomes a false flag, it's like a comment that doesn't reflect the code changes so now it adds to the confusion instead of alleviate it.

Personally I add // FIXME while writing code but I make sure to remove all of them prior to creating a merge request. It's my way to track outlier issues that I will turn around and fix as I parse my code. If I find a // FIXME that deserves to be its own enhancement or a future TODO I will capture it as a story. My org is Agile story driven which is why I put it there.

Perhaps adding TODOs for a personal project is fine. However for repositories that multiple developers touch a TODO at best is noise, at worst a point of confusion.

Re: The Code Is the To-Do List

#68

Post by 100011_100001 »

yuvalr1 wrote: post #20

I always use code comments with my name during the work to help me remember things I want to change but don't want to do them right in this moment. Then before pushing I make sure there is no comment bearing my name.

I use // FIXME for the same reason. When I get ready to create my merge request a global // FIXME will point out anything I missed.

Re: The Code Is the To-Do List

#69

Post by edvald »

quickthrower2 wrote: post #46
edvald wrote: post #42

One trick I employ for myself is: throw "TODO" // Substitute for your language's syntax of course. I find this especially handy when writing test specs, but it's also handy when creating new functions etc. For tests I lay out the test descriptions with just this one line in the function body. For new functions/methods I can define the function and its return type (assuming a type-safe language) which makes the code u…

That sounds good within a feature branch but you wouldn’t merge those to main, right?

No definitely not, this is just for WIP branches. I usually don’t even push these, unless it’s something big that I need early review on.

Re: The Code Is the To-Do List

#70

Post by madmax108 »

I've had great success with a lot of smaller engineering teams (3-8 Engineers) just using a simple grep of codebase to write out TODOs to a seperate file at root directory of the and make this part of the build process. eg

    task updateTODO(type: Exec) {
        commandLine "bash", "-c", "grep -ri \"\\bTODO\\b\" src > TODO"
    }
Advantages:

- It's unintrusive and the TODOs get updated automatically (Also doesn't create sudden build failures like some approaches suggested on this thread)

- It's in the git repo so accessible to everyone easily and you don't need any special tools/plugins to see TODOs. Even better, I can just give a link (since it's just a github link) to the TODOs file to someone like a PM/PO to get time for my team for engineering tasks without needing to go through creating tickets and "BaCkLoG GrOOmINg" stuff.

- Every few months, we organize a refactoring sprint where having all TODOs in a single place allows engineering team to sit together and see what the TODOs are that need to be handled.

Post reply on HN