Live data from Hacker News

Who wrote this shit?

heltweg.org

221–230 of 300 posts

Re: Who wrote this shit?

#221

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…

Always check git blame before winging out insults. Then, only blame people no longer at the company ;)

[deleted]

Re: Who wrote this shit?

#222
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.

More than once I've googled how to do something new and found the answer on Stackoverflow, written by me. I haven't even written that many answers on Stackoverflow.

Well, I hope you gave yourself a good answer.

Re: Who wrote this shit?

#223
post #19
post #4

My favourite is when you're a solopreneur working in your own repos and still asking yourself "who wrote this shit?!"

I heard a saying once: "all developers should be embarrassed about code they wrote more than a year ago" as a (cheeky) measure of ongoing growth and development. :-)

I've read that and think the saying is fundamentally wrong. If you're constantly embarrassed at code that is only a year old, I think it's much more likely that you are chasing fads rather than actually improving your code quality.

I would go as far as to say that it's a negative signal, because instead of improving code quality you are just changing things that don't really matter.

Re: Who wrote this shit?

#224
post #122

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…

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 the same chunk of code... "Who wrote this shit?", and off we go again. I must have gone through this loop 4 or 5 times with the same piece of code.

Re: Who wrote this shit?

#225
post #142

Many people in this thread are saying they are surprised by their own shitty code, 6 month ago. I read this everywhere on the Web. It's like I should myself be finding my code from 6 months ago horrible. I don't know. I tend to remember what code I wrote, and recognize my own code when seeing it, even years later. My code from 6 months ago looks good to me. My code from 10 years ago looks "reasonable, if a bit messy"…

It's a bit of confirmation bias though: code you wrote well is less likely to come back and bite you in the ass. 20 years on, I still feel the 6 months ago thing.

Re: Who wrote this shit?

#226
At one of my early software engineering jobs, my team was generous enough to entrust me with building a fairly complex component from start to finish. What I made worked reliably but the underlying code was spaghetti. I hope they felt no qualms about trashing it and have had an opportunity to refactor it since.

Re: Who wrote this shit?

#227
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…

Put the reason for the weird code in the comments explaining why it is. Don't make somebody run git blame.

Re: Who wrote this shit?

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

[1] http://boston.conman.org/2022/01/04.1

Re: Who wrote this shit?

#229
post #207

Earlier quoted context omitted.

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…

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.

I didn't mean to imply they were mutually exclusive; just that in terms of "most high-impact documentation you can write", I find ensuring I link the ticket higher than making sure I have a thoughtful commit message, for the reasons listed.

Fair that it can disappear eventually if you change ticket trackers or whatever; that's a risk of changing ticket trackers. Hopefully you maintain both for a bit, and once you're six months out or whatever and retire the old, you don't need as much context since things have moved on (and there's a generational effect in tickets akin to that in garbage collection; you tend to need recent things more often than old things, and the older, the less likely you are to need it).

But just in terms of "what would I rather have", a link to the ticket every time. And in terms of "what am I more likely to provide", a link to the ticket every time as well (since all the communication on the ticket came about out of need; writing a thorough commit message is out of preparation, and I, and everyone else, am WAY better at consistently doing things that I need to do than preparing for possible future things)

Re: Who wrote this shit?

#230
post #72
post #37

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

> always just about 'good enough' to solve the issue at hand

I've seen this approach really bite teams that only focus on the cost of implementing application behaviors rather than the long-term costs in terms of maintenance and systems complexity. If too many poor design decisions are made when a project is greenfield under the premise of "good enough" it can create technical debt so bad that the devs can't extricate the debt from core product features further down the line.

Post reply on HN