Fits writing words as well, where you’ll look back in your first blog posts a decade later and wonder who would write such things.
Who wrote this shit?
131–140 of 300 posts
Re: Who wrote this shit?
#132TBH this is a big motivator for my code comments - “Ideally this code would do X, but because of constraint Y we are settling for Z. If you can think of a way to achieve X without the compromise then by all means burn this module with fire, and add me as a code reviewer so we can celebrate together.”
Re: Who wrote this shit?
#133We have a rule that if you have to leave shit code as it is for a serious reason (time constraints, shifting requirements) you must leave a TODO in the code which poins to a freshly created issue in the tracker which explains what's wrong with the code and how it can be fixed. The ideal is that these issues eventually get fixed, which is often not the case (new features are prioritized over tech debt etc.), but at least new devs will immediately see that it's a known problem and that there're known solutions.
Re: Who wrote this shit?
#134It was me ... several times I have found a bug or code smell and then been surprised that the I was the original author. For the last fifteen to twenty years, I've generally found looking at code I wrote six months ago equally distasteful. So now my default behavior is to assume the code met the business function at the time, acknowledge that I'm continuously improving in my craft and finally, gained a joy in spendin…
I'm a strong believer in continuous refactoring. Improve existing code when you touch it. Defer architectural choices untill the moment you have enough info. And leave cleaning up to the moment that it starts becoming messy, not before. That implies, code never is perfect. Not even good. But clunky, cobbled together, expermental or just plain stupid. But always just about 'good enough' to solve the issue at hand.
I reached the same conclusion.
I just would add, that the urge to refactor things whenever possible, definitely introduced bugs for me, because also refactoring has to be done with consideration and some things were weird for a reason, you do not see at first glance.
And refactoring can also hurt you, or another person just used to that code in its old shape. And then missunderstanding things.
Re: Who wrote this shit?
#135It's an exhausting cycle of writing code, hiring new people who say it's shit, who write their own code that next year the new batch of hires says it's shit again and needs to be rewritten. Of course all of these developers are too good to write a comment because their code is so easy to read that it's 'self documenting'
Comments shouldn't be the default way of documentation anyway.
Re: Who wrote this shit?
#136There's little joy greater than finding a vast swathe of horrible code written by Past Me ("that asshole") and being able to delete it.
Re: Who wrote this shit?
#137In my first corporate job out of college (a NOC at an ISP) I was asked to update the documentation for troubleshooting quality of service issues. I checked our wiki for what was already there and it horrendous. I started to mentally thrash the person and was going to go confront them about it. When I checked the edit history I was greeted by a single edit and my username a week after I started the job. I learned a gr…
Always check git blame before winging out insults. Then, only blame people no longer at the company ;)
Re: Who wrote this shit?
#138We have a rule that if you have to leave shit code as it is for a serious reason (time constraints, shifting requirements) you must leave a TODO in the code which poins to a freshly created issue in the tracker which explains what's wrong with the code and how it can be fixed. The ideal is that these issues eventually get fixed, which is often not the case (new features are prioritized over tech debt etc.), but at le…
> We have a rule that if you have to leave shit code as it is for a serious reason (time constraints, shifting requirements) you must leave a TODO in the code which poins to a freshly created issue in the tracker which explains what's wrong with the code and how it can be fixed.
This seems like a really sane thing to do!
In addition, if you want to keep track of the commits and the context behind them, i've found that merge/pull request descriptions are also really nice for this!
Back when i had to struggle with an Eldritch DB schema that someone wrote and had to patch in new functionality, i ended up painstakingly mapping out how it corresponded to the business concepts/objects (which was pretty loosely) and threw that diagram into the merge request, because sadly otherwise the schema still wasn't all that clear...
...just to have that very same diagram save my hide when i had to go back to it months later to update some of the code, which necessitated rediscovering how everything works.
Now, whether things belong in the issue tracker or somewhere that's more close to the code repo is probably just a cultural question, but i'd say the main thing is to have some place to store information like that.
Re: Who wrote this shit?
#139There is a risk if you stay in one place (or work on the same FOSS codebase) too long, because the answer to "who wrote this shit" often turns out to be "wow, what was I thinking?"
Re: Who wrote this shit?
#140I maintain an analytics tool for a large newspaper. I wrote the code for it in PHP 13 years ago. The app has been running without interruption for 13 years and is used by hundreds of employees every day. Still, it needs a bit of maintenance (APIs change). The code is scary and I will probably maintain the project for the rest of my life because anyone else would pull their hair out. I'm not proud of it and write better code in the meantime, but rewriting all the code from 13 years ago would be way too expensive for the company.