Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I used to keep a so-called shitlist for a long term project I was involved in.

The idea was to document all the worst places in the codebase(150k LOC) that frequently caused weird behaviours.

Each record contained a short description, the reason why this piece is bad, hash of the commit that introduced it and of course the perpetrator.

Of course the main purpose it served was to relieve stress, nevertheless it helped me with my work a few times.

One could ask why didn't I just refactor these pieces right away? Two things often stopped me from doing this: first, some of those lines were over eight years old and a huge part of the system depended on their sometimes buggy behaviour. Second, the company review policy was "stability, stability, stability", so any change beyond the scope of the thing I was working on was automatically rejected.



I've done the same, although, i just put it right in the code:

TODO, REDO, DONE with the corresponding JIRA ticket ID for extended mental notes (Pull Request fits here too). IDEs can grok all that together so you can quantify the bad stuff in the code, which can help management make better decisions.


I would do the same if I weren't afraid of coming off as passive-aggressive given that I voiced my opinions in the past but received a reply in the vein of: "We're aware that this old code is really bad, but with our constrained resources we need to prioritize keeping this boat afloat.".


I keep mine locally. I have the PlainTasks[0] package installed for Sublime Text. It's a plaintext file with a bit of TODO functionality baked in. When I find something, I note the commit, the line (or block), and why I want to fix it. I try to slightly estimate high enough that I could throw some fixes in for the sprint.

[0]: https://github.com/aziz/PlainTasks


At some point you do need to stop baling water and actually plug the hole though.


Nah. The bridge crew all have executive lifeboats. No biggie if the ship goes down.


To completely and hyperbolically torture this metaphor, as long as you whip the galley slaves to row fast enough so that you can jump to safety on "Short Term Stock Gain" Island, you'll be fine.


They should teach this at MBA school. But they don't.


As well as the many IDEs and editors that support these comment tags, Ruby on Rails (and I'm sure other frameworks also) provides direct support for these.

  rails notes
Will return you a little text report that you can use in your CI or anywhere else that groks text.


I used to do this in visual studio, it had a task list view that would aggregate all the comments that start with 'TODO'. Since I made the move to VSCode I haven't found anything similar.



Thank you!


> Of course the main purpose it served was to relieve stress, nevertheless it helped me with my work a few times.

That seems more preferable to becoming what essentially amounts to becoming a mouth piece for potential areas of preference (error?) in software design.


I would call it notes.txt to make it more positive. Bad code is everywhere, and don't let them make you sad.


Actually the fact that I finally had an outlet for my frustrations was very cathartic. It was a lot like writing sad poetry over lost love.


Or the epilogue to my life spent indoors fixing bad code.


That may be the most depressingly truthful description of software development I've ever run across.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: