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

51–60 of 80 posts

Re: The Code Is the To-Do List

#51

Post by giancarlostoro »

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…

How do I get such a linter into Visual Studio, I've never added anything like that to C#, my personal strategy is to just make tickets, but also with stuff like JetBrains different IDEs you can fetch all the TODO's in a list. I opt for tickets so they dont get lost.

Re: The Code Is the To-Do List

#52

Post by jeremyjh »

lbriner wrote: post #47

Unless I've misunderstood, I don't like this proposal. To me: Scenario 1: The code needs doing as part of the work I am doing. Solution: Do it before your current branch is merged otherwise your story is not complete. Scenario 2: The code will eventually need doing but not now. Raise a task/ticket. Don't pollute the code with things that might never get done. We intended to remove a load of old code previously and ha…

As I understand it, this is a forced reminder for scenario 1; to ensure the other change is also made before merge.

Re: The Code Is the To-Do List

#53

Post by cseleborg »

arinlen wrote: post #48
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…

> 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. Why do you expect that random comments in the code will affect the priority of some tasks? Do you feel that stashing out-of-band info on pending tasks which were deemed not important regarding t…

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...

Re: The Code Is the To-Do List

#54

Post by briHass »

giancarlostoro wrote: post #51
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…

How do I get such a linter into Visual Studio, I've never added anything like that to C#, my personal strategy is to just make tickets, but also with stuff like JetBrains different IDEs you can fetch all the TODO's in a list. I opt for tickets so they dont get lost.

VS automatically creates a To Do list window with all your TODO and similar comments. If you don't want to go as far as making it a git hook or built into your CI, you can use something like this: https://marketplace.visualstudio.com/items?itemName=MattLace...

Re: The Code Is the To-Do List

#55

Post by planede »

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.

Re: The Code Is the To-Do List

#56

Post by arinlen »

cseleborg wrote: post #53
arinlen wrote: post #48

Earlier quoted context omitted.

> 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. Why do you expect that random comments in the code will affect the priority of some tasks? Do you feel that stashing out-of-band info on pending tasks which were deemed not important regarding t…

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 any tangible upside.

> A few bytes is nothing compared to Management's roadmap, so it gets ignored.

Bytes are irrelevant. Tickets also cost bytes. Tickets also track rationale and context. What really matters is allocated resources in order to deliver value.

The only reason your TODO item gets ignored is because the potential value it promises does not justify allocating resources to it.

People need to be smart about how they invest their time and effort. Tracking vague tasks deemed unnecessary or useless in a separate out-of-band source of info is not productive and ends up only creating noise and distractions.

Re: The Code Is the To-Do List

#57

Post by ParetoOptimal »

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.

Because the annoyance means it will get fixed? In issue tracking it just gets archived.

Re: The Code Is the To-Do List

#58

Post by planede »

ParetoOptimal wrote: post #57
planede wrote: post #55

Earlier quoted context omitted.

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.

Because the annoyance means it will get fixed? In issue tracking it just gets archived.

If you want to set it a date, then set a deadline for the issue. It should still annoy the right person.

Re: The Code Is the To-Do List

#59

Post by arinlen »

ParetoOptimal wrote: post #57
planede wrote: post #55

Earlier quoted context omitted.

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.

Because the annoyance means it will get fixed? In issue tracking it just gets archived.

> Because the annoyance means it will get fixed? In issue tracking it just gets archived.

That makes no sense at all.

If a ticket is archived them that means the issue was evaluated and considered irrelevant and a distraction that should be ignored. Otherwise in the very least it should be placed on a backlog, and reconsidered each and every single time someone picks/is assigned a new task.

Nagging through out-of-band means to push an irrelevant task that was already considered and discarded makes all matters worse, and frankly sounds like a playground for petty passive-aggressive office politics.

Re: The Code Is the To-Do List

#60

Post by ParetoOptimal »

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…

> 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 work.

Usually metrics aren't accurate enough to be able to prove these things anyway in my experience.

Post reply on HN