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

Plotting the source code “TODO” history of the most popular open source projects

schleiss.io

Post reply on HN
Print view View original

101–110 of 114 posts

Re: Plotting the source code “TODO” history of the most popular open source projects

#101

Post by hinkley »

actinium226 wrote: post #86
twelvechairs wrote: post #61

Is it controversial to say that those with low TODOs are pretty clearly the cleanest packages I enjoy working with most? (Postgres, Rust, Django, VueJS, maybe Python)

Well, is the converse true? Are the packages with high TODOs the dirtiest packages that you least enjoy working with?

"I'll do it later" is one of the more challenging personality faults to deal with in coworkers. There are very few people you can trust to make that statement, while most of the rest behave as if you should trust them as well, even though everybody knows they won't in fact do that later.

Not only will they not do that later, but at some point they will compare their productivity to someone who ended up having to 'do that later' for them, causing their other work to suffer.

Re: Plotting the source code “TODO” history of the most popular open source projects

#102

Post by berkes »

eXpl0it3r wrote: post #54
_Understated_ wrote: post #52

Earlier quoted context omitted.

I dunno... I think they have their place. I'm working on a personal project right now and in order to see how things look, if they work etc, I've got a bunch of vanilla js frontend code and //TODO in a few places to call an API and get actual data. It works great for now as I've hardcoded everything, got it looking broadly like the finished product, and it means that I just have to do the API calls (and programme the…

On a personal project, I can see this working, on a team project, you're not gaining anything with TODOs, because the chances that you or your colleagues actually go back and fix/implement the TODO are close to zero. Not only are you rarely gonna have the time to fix the TODO, but weeks, months, years later when you run into a TODO in your code, you have no idea what the actual requirements were, why it was not imple…

> because the chances that you or your colleagues actually go back and fix/implement the TODO are close to zero.

This depends entirely on the team, company and/or work, though. It certainly is not a given.

> TODO in your code, you have no idea what the actual requirements were, why it was not implemented, why it hasn't hurt anyone and whether anyone is actually needing it

This depends on the task you are TODO-ing. Sure, if it is a "TODO: seems broken, fix." or "TODO: make sure that users don't see this", you are putting not just the wrong things in TODOs you are not giving them enough context. Compare that with a "TODO: this duplicates the routine in FooBars#bar_bar, but we cannot move this to a generic helper until the BarBar can handle both ActiveUsers and PendingUsers. Once that polymorphism is implemented, this can be DRYd up", which gives context, predicaments, and communicates that the author knows it is suboptimal, and explains how the author would've fixed it.

Re: Plotting the source code “TODO” history of the most popular open source projects

#103

Post by hinkley »

berkes wrote: post #96
shireboy wrote: post #80

Well, I'm glad I'm not the only one who never gets around to my //TODO#s. One related tip for devs: I've started adding "You are here" as a placemark for where I'm working in the code. So for example, on friday, if I want to pick up quickly next monday, I add "//TODO: YOU ARE HERE Finish doing foo". Then on monday, I search for "You are here" and pick up where I left off easier. Saves me a few cycles, though if I'm h…

I've been annotating my work several times a day, with `INK`, from "leave some water in the well", a productivity hack from Hemingway[0]. I forgot how I went from "Water in the well" to "ink the well", though. It's been a while since I started doing it, and I wrote a blog-post[1] with some scripts and helpers that I still use. [0] https://www.fastcompany.com/3021905/hemingways-secret-to-mai... [1] https://berk.es/201…

> in other words, never end a day’s work without knowing how you are going to start the next day.

This turns out to be very hard advice for developers to follow. I don't say that as a complaint about Hemingway, but as a complaint about developer neuroses.

I have tried many, many times to convince people to associate their 'sense of completion' not with the act of getting their changes into master but the act of committing their changes (or pushing it to a branch, if you are PR-driven). It works less than half the time, and almost always with the more junior people...

So many incidents of someone staying late to finish something, pushing it, then coming in late the next day (because they stayed late) to a bunch of upset coworkers who had to clean up the mess they made.

Completionism will be the death of us all.

Re: Plotting the source code “TODO” history of the most popular open source projects

#104

Post by the__alchemist »

jpswade wrote: post #51

Todos are generally terrible practice in code, as they often don’t give any indication how they are going to get to done. They never get prioritised and very rarely does anyone get to do them. So what’s the point? It feels like a todo is really only there to serve as an excuse for suboptimal solutions.

I'd rather have a todo (that marks the line with a nice bright color in my IDE) than the immediate alternatives of #1: Not implementing a feature because it has room for improvement, or #2: Leave out the deficiency marking because it makes the code look more complete.

Re: Plotting the source code “TODO” history of the most popular open source projects

#105

Post by berkes »

hinkley wrote: post #103
berkes wrote: post #96

Earlier quoted context omitted.

I've been annotating my work several times a day, with `INK`, from "leave some water in the well", a productivity hack from Hemingway[0]. I forgot how I went from "Water in the well" to "ink the well", though. It's been a while since I started doing it, and I wrote a blog-post[1] with some scripts and helpers that I still use. [0] https://www.fastcompany.com/3021905/hemingways-secret-to-mai... [1] https://berk.es/201…

> in other words, never end a day’s work without knowing how you are going to start the next day. This turns out to be very hard advice for developers to follow. I don't say that as a complaint about Hemingway, but as a complaint about developer neuroses. I have tried many, many times to convince people to associate their 'sense of completion' not with the act of getting their changes into master but the act of commi…

> but the act of committing their changes (or pushing it to a branch, if you are PR-driven)

I'm not sure if I understand you entirely correct, but it seems the "you have to commit" is a large part of the problem.

You don't.

Your harddrive is not going to crash between tonight and tomorrow. And if it may, and this is crucial, git is not a backup system, so get a proper backup system in place.

Commit when you have a coherent piece of work done. Or maybe commit a "WIP: working on foo, halted for emergency hotfix X" if stashing is out of the question.

Part of my "INK" workflow is not committing to RCS. Leave the dirty state as another mental nudge what you were working on; and add your current memory-state as annotations in the code behind an INK.

I've mentored a junior and he was the opposite, never committed untill he was finished, sometimes work of multiple weeks, then he commited it with "finished the FooBar". We agreed he would try to commit at least daily. So then he made one commit a day. "17:00 going home. commit" in the logs. Every day. Needless to say, we did not keep him for long.

Re: Plotting the source code “TODO” history of the most popular open source projects

#106

Post by thamer »

tastroder wrote: post #48
pc86 wrote: post #43

Earlier quoted context omitted.

Stupid question, is "TODO" in this instance case sensitive?

It's case sensitive by default, you can add -i/--regexp-ignore-case to disable that.

You might also want -w for whole words, otherwise commits by your colleague Todor might cause some confusion.

Re: Plotting the source code “TODO” history of the most popular open source projects

#108

Post by hinkley »

berkes wrote: post #105
hinkley wrote: post #103

Earlier quoted context omitted.

> in other words, never end a day’s work without knowing how you are going to start the next day. This turns out to be very hard advice for developers to follow. I don't say that as a complaint about Hemingway, but as a complaint about developer neuroses. I have tried many, many times to convince people to associate their 'sense of completion' not with the act of getting their changes into master but the act of commi…

> but the act of committing their changes (or pushing it to a branch, if you are PR-driven) I'm not sure if I understand you entirely correct, but it seems the "you have to commit" is a large part of the problem. You don't. Your harddrive is not going to crash between tonight and tomorrow. And if it may, and this is crucial, git is not a backup system, so get a proper backup system in place. Commit when you have a co…

> Commit when you have a coherent piece of work done.

No, that's the problem.

Commit when you are available to deal with the consequences of commit. Having a coherent piece of work reduces, but does not eliminate the chance for problems. If you leave before the code builds, you've created problems for someone else to fix. If you haven't budgeted time for the rollback to go wrong on the first try, you're creating problems for other people.

This is why reliability and responsiveness of CI/CD systems matter much more than most people allow. On a good project, pushing things after 4 is probably a bad idea. On less well run systems, anything after 3 might be risky. On a bad one, 2:30 might be pushing things. So depending on meetings and lunch time there may be very small intervals where you can push things, and when the clock is ticking we begin to rationalize, which just makes the likelihood of failure increase.

Re: Plotting the source code “TODO” history of the most popular open source projects

#109

Post by berkes »

hinkley wrote: post #108
berkes wrote: post #105

Earlier quoted context omitted.

> but the act of committing their changes (or pushing it to a branch, if you are PR-driven) I'm not sure if I understand you entirely correct, but it seems the "you have to commit" is a large part of the problem. You don't. Your harddrive is not going to crash between tonight and tomorrow. And if it may, and this is crucial, git is not a backup system, so get a proper backup system in place. Commit when you have a co…

> Commit when you have a coherent piece of work done. No, that's the problem. Commit when you are available to deal with the consequences of commit. Having a coherent piece of work reduces, but does not eliminate the chance for problems. If you leave before the code builds, you've created problems for someone else to fix. If you haven't budgeted time for the rollback to go wrong on the first try, you're creating prob…

> If you leave before the code builds, you've created problems for someone else to fix.

I'm curious to your workflow now. How can it be someone else's problem if you do not commit (and/or don't push) your work? Is everyone working only on master/main/develop branch? Do you work in a shared drive? Is your entire team working off a dropbox or network drive (I've seen this, I needed eyebleech)?

Re: Plotting the source code “TODO” history of the most popular open source projects

#110

Post by efnx »

mihi wrote: post #84
stevenhuang wrote: post #75

Earlier quoted context omitted.

Or do both. Might as well add TODO: to make it stand out as a thing that can be improved while also making it greppable.

Might also be cool to automatically create these tickets (when commited to master?). Then you don't forget, and even if they end up not that detailed, you at least get a nice list of all of them.

If you want a cli tool for this I have one here https://github.com/Schell/todo_finder

You can output to markdown or to GitHub issues with a token.

I used to operate a service that did this for you.

Post reply on HN