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

41–50 of 80 posts

Re: The Code Is the To-Do List

#41

Post by actionfromafar »

srer wrote: post #38
arinlen wrote: post #33

Earlier quoted context omitted.

> 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. That sounds like an awful strategy, one that needlessly creates problems and revision history noise and team distractions. Is it awful if a comment leads your CICD pipeline to break? Now imagine having you…

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…

In Eastern Liturgy, the ticket is the confession and the mandated overtime is the penance.

Re: The Code Is the To-Do List

#42

Post by edvald »

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 using it compile, but leaves the implementation TBD.

The placeholders are then implicitly flagged in test runs and easily found. Basically my text search results for 'throw "TODO"' become my TODO list.

Re: The Code Is the To-Do List

#43

Post by KronisLV »

srer wrote: post #38
arinlen wrote: post #33

Earlier quoted context omitted.

> 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. That sounds like an awful strategy, one that needlessly creates problems and revision history noise and team distractions. Is it awful if a comment leads your CICD pipeline to break? Now imagine having you…

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 teammates that you'll be working on that piece of technical debt instead of the new feature.

If you can't do that, then either the "TODO" comments/issues aren't important enough, or they're not deemed to be and will/should simply be left to rot until you either have an abundance of time to address them (which may be never), or the project is retired.

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

Re: The Code Is the To-Do List

#44

Post by bakul »

May be combine this idea with Knuth’s Literate Programming? Then when you get around actually working on the task it already tells you what you’re supposed to do!

Re: The Code Is the To-Do List

#45

Post by quickthrower2 »

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…

Even better: do it now, or not at all.

If it is a failing test do it now anyway.

The reason is the person adding the TODO may have a bias that their thing really is the most important tech debt.

However I would step back and figure out what tech debt payback offers the best ROI with the team.

If you have a pet hate refactor you want done, add it to a personal list and bring it up for consideration in that process.

Or just fix it as part of your task if practical to do so.

Re: The Code Is the To-Do List

#46

Post by quickthrower2 »

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?

Re: The Code Is the To-Do List

#47

Post by lbriner »

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 haven't done it in 2 years because it isn't a problem.

I don't understand why you want to carry on working but hold back the entire codebase until the second piece of work is done.

Re: The Code Is the To-Do List

#48

Post by arinlen »

srer wrote: post #38
arinlen wrote: post #33

Earlier quoted context omitted.

> 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. That sounds like an awful strategy, one that needlessly creates problems and revision history noise and team distractions. Is it awful if a comment leads your CICD pipeline to break? Now imagine having you…

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 the project workload changes anything?

Also, if everything is always more important than the TODO item, that is the universe telling you that your TODO item should be deleted and that you should stop wasting your bandwidth with useless and unnecessary tasks.

Re: The Code Is the To-Do List

#49

Post by sethammons »

In code review, I ask that any TODO be augmented with a link to the jira ticket tracking it. If it is not in jira, it is not getting priority. If it is too small to justify a ticket, fix it then and there.

Re: The Code Is the To-Do List

#50

Post by FooBarBizBazz »

jillesvangurp wrote: post #40
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…

It would be a cool little side project to automatically track TODO's and FIXMEs with an issue tracker. There is a lot of monkey work involved with issue tracking currently and a lot of work that isn't tracked or poorly tracked because of it. Lowering the barrier to make work and tasks more visible is useful.

Jira creates so much friction. It's a trillion dollar drag on the Tech industry. It should be as quick as writing a Slack message.
Post reply on HN