Live data from Hacker News

Who wrote this shit?

heltweg.org

231–240 of 300 posts

Re: Who wrote this shit?

#231
post #122

Earlier quoted context omitted.

I also had that moment; ask “Who wrote that shit?”, run ‘git blame’ and find yourself. This happened 1 year into my second job.

I had this happen _several times_ at an agency I used to work at. I stumbled across some really bad code in their main product, got irate and asked "who wrote this shit?". Ran git blame and discovered it was me. Ok, but this is still s#*t, I need to fix it. Spent a couple of hours and found no way of improving it, figured "well, it's ugly, but I guess it is what it is" and moved on. A few months later I came across t…

Would be a good idea to add a comment explaining the situation, so you don't have to waste time again on it.

Re: Who wrote this shit?

#232
post #198

On the topic of "who wrote this shit", I'd really like to plug the idea that some of the most high-impact documentation you can write is a good commit message. Say you track down a bug, find a line of code that makes no sense, and `git blame` it, to discover that you wrote it yourself, 2 years ago. If the commit message is "bugfix flaky builds", good luck figuring it out. If the commit subject rather, is "bugfix flak…

> If the commit subject rather, is "bugfix flaky builds", followed by a message that explains what the flakiness was, why you think the change will fix it, what other bugs or limitations you were working around, and what upstream changes you might be waiting on that prevented further work, you're in a much better position.

Those are very different needs.

"Why?" belongs in code as a comment. "How?" only sometimes belongs in a comment--generally if the code is "clever".

"What?" generally belongs in the commit message as it can touch multiple files and subsystems.

"Who?" and "When?" generally belong in your ticketing system.

Re: Who wrote this shit?

#233
post #219
post #207

Earlier quoted context omitted.

These two aren't mutually exclusive. Tickets, however, have lower long-term survivability (in my experience). Outsourcing, migrations, there are many scenarios in which the original tickets become inaccessible over time - and some codebases do last for years and years. Meanwhile the repository content (and thus the complete version history) usually survives as-is.

The commit message idea always felt a little strange/off to me. It's a string that you can't (generally) fix/extend later for those who may seek this information. Also nobody except the committer can write them. (Imagine an explicit @docsguy role for documenting commits along with writing ticket-based documentation.) What if VCSs used a single file or a folder, like .gitcommits, where anyone could append any sort of…

I've never used git-notes, but it sounds like this is what you are describing: https://git-scm.com/docs/git-notes

Re: Who wrote this shit?

#234
post #228

In 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…

And sometimes the horrendous code really is written by someone else. I recently came across some horrendous code [1] that needlessly wrapped syslog(), and separated the format string from the point of use (the format string was a #define). The thing is---I know the developer (he left our company over a year ago) and is a great guy (former jazz musician), but let's just say he had some questionable coding practices. […

Could there be a reason to do that? E.g. preventing the format string from accidentally coming from untrusted user data?

Re: Who wrote this shit?

#235
post #198

On the topic of "who wrote this shit", I'd really like to plug the idea that some of the most high-impact documentation you can write is a good commit message. Say you track down a bug, find a line of code that makes no sense, and `git blame` it, to discover that you wrote it yourself, 2 years ago. If the commit message is "bugfix flaky builds", good luck figuring it out. If the commit subject rather, is "bugfix flak…

I fixed a bug the other day that I was so embarrassed about, I intentionally left the commit message cryptic.

(It was a personal project.)

Sometimes the best documentation is seared into your soul as a mark of shame. I think I’ll wake up a few times wincing about it.

Re: Who wrote this shit?

#236
post #198

On the topic of "who wrote this shit", I'd really like to plug the idea that some of the most high-impact documentation you can write is a good commit message. Say you track down a bug, find a line of code that makes no sense, and `git blame` it, to discover that you wrote it yourself, 2 years ago. If the commit message is "bugfix flaky builds", good luck figuring it out. If the commit subject rather, is "bugfix flak…

I fixed a bug the other day that I was so embarrassed about, I intentionally left the commit message cryptic. (It was a personal project.) Sometimes the best documentation is seared into your soul as a mark of shame. I think I’ll wake up a few times wincing about it.

Spare me your shame.

Should someone inherit your project and end up fixing another bug in that part of the code they may be benefit from any information you share.

Shame is temporary, public repos are not.

Re: Who wrote this shit?

#237
I have a healthy habit of just assuming that if something is bad then i probably wrote it.

That way once you realize it's someone else's fault you feel slightly relieved and less prone to talk poorly about them.

It's self-deprecating sure, but I've never been a believer in the whole "believe in yourself"/pro-self-esteem mindset, if you are mentally strong enough it really doesn't have an impact on how you operate or think. There's always something more brilliant, and more stupid then you are; that poor deadline based decision has been made by both you and the person who wrote that piece of crap code. We are all the same (barring some exceptions).

Though I will say, I hate what modern program "design" has become, anytime someone mentions "sprints" you know that any maintenance you do on that codebase will be a fight uphill the whole way, there's no excuse other then an exec wanted something in half the time, just to have the poor sods that come after to be doomed to poor progress reports for months after trying to fix that garbage code they are tasked to maintain.

Re: Who wrote this shit?

#238
I love legacy software so much - all the trouble and care I put into making sure it continues to work while I fix and improve it, is like operating on a live patient. I see no point in judging; I like to dig and to understand the particular choices. Seeing how much trouble companies have with legacy code, I tried to market myself as a consultant around those kinds of problem: say, adapting a legacy system for a more reliable and pleasant development process, or things like this.

Unfortunately I found that it’s a hard work institutionally. Even where I found gratitude and respect of my people whose quality of life working with the software in question improved, I still was plagued by the problems of blame-assignment and career-making but futile huge rewrites orchestrated by people for whom destroying my work and denying its value was highly beneficial. I don’t know, I burnt out on this last time so hard I’ve been taking kind of a vacation.

As much as I love sustainable software development, it’s a losing battle and probably a futile goal in most of the industry. I’m just trying to accept this and move on.

Re: Who wrote this shit?

#239
post #198

On the topic of "who wrote this shit", I'd really like to plug the idea that some of the most high-impact documentation you can write is a good commit message. Say you track down a bug, find a line of code that makes no sense, and `git blame` it, to discover that you wrote it yourself, 2 years ago. If the commit message is "bugfix flaky builds", good luck figuring it out. If the commit subject rather, is "bugfix flak…

Eh, I'm not sure I agree. What has gotten me the most value is having either the branch or the commit message tie back to a ticket somewhere. -That- has the original bug, the comment thread that led to the decision around why this particular fix, any additional comments around tradeoffs we were aware of, and what other options we dispensed with, etc. A well written commit message might explain what the issue was, but…

I believe commit messages should also summarize the context.

Re: Who wrote this shit?

#240
post #198

On the topic of "who wrote this shit", I'd really like to plug the idea that some of the most high-impact documentation you can write is a good commit message. Say you track down a bug, find a line of code that makes no sense, and `git blame` it, to discover that you wrote it yourself, 2 years ago. If the commit message is "bugfix flaky builds", good luck figuring it out. If the commit subject rather, is "bugfix flak…

I fixed a bug the other day that I was so embarrassed about, I intentionally left the commit message cryptic. (It was a personal project.) Sometimes the best documentation is seared into your soul as a mark of shame. I think I’ll wake up a few times wincing about it.

To err is human. Don’t feel bad about it. You fixed it :)

(I say this as someone who has a track record of being too hard on myself!)

Post reply on HN