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

Who wrote this shit?

heltweg.org

Post reply on HN
Print view View original

201–210 of 300 posts

Re: Who wrote this shit?

#201

Post by Yajirobe »

sshine wrote: post #122
bikingbismuth wrote: post #44

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.

It sometimes can be misleading. If I'm refactoring large parts of code (e.g. splitting a large file to smaller ones), then sometimes the original logic written by someone else will be left, but git blame will show me because I was the last to make changes

Re: Who wrote this shit?

#203

Post by lostcolony »

Yen wrote: 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 it won't have anywhere near the context the ticket and resulting comment thread should have.

Re: Who wrote this shit?

#205

Post by lostcolony »

taocoyote wrote: post #187
matwood wrote: post #137

Earlier quoted context omitted.

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

Find incomprehensible code. Get email from blame. Search for them on Linkedin. If they are working as a developer in some senior capacity, then the code is probably a learning opportunity for me. If they are working as a scrum master code is probably as bad as it looks. I say this in jest, mostly...

I dunno; I've known horrible senior devs who wrote solutions that were clearly resume driven development who ended up as tech leads elsewhere when there was a regime change and actual scrutiny began to be applied to them.

Re: Who wrote this shit?

#206

Post by wnoise »

matwood wrote: post #137
bikingbismuth wrote: post #44

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 ;)

https://github.com/jayphelps/git-blame-someone-else

Re: Who wrote this shit?

#207

Post by V-2 »

lostcolony wrote: post #203
Yen wrote: 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…

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.

Re: Who wrote this shit?

#208

Post by u801e »

lostcolony wrote: post #203
Yen wrote: 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…

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

That works until the bug tracker goes down or the company decides to use a different bug tracker and the import doesn't preserve information, or the link in the commit message doesn't resolve to the corresponding ticket in the new bug tracker. This is far less likely to happen to the git history given that it's distributed.

That being said, adding information to the merge commit message linking to the discussion or actually summarizing it in the commit message itself would definitely be an improvement. The merge commit has references to the commit the branch is based off of and the head commit of the branch, so you can limit git log output to just commits in the branch long after it has been merged.

Re: Who wrote this shit?

#209

Post by runjake »

I've had this exact experience, except I didn't see Torben's name, I saw my own name. And there was no excuse about deadlines and whatnot, I was just awful.

10 years from now, I'll be saying the same about the code I write now. And that's okay.

Re: Who wrote this shit?

#210

Post by jbgreer »

I have often said to other devs that if you write code long enough, you’ll eventually find some crusty piece of your own code that will make you want to throw up.
Post reply on HN