The "who wrote this?" mentality is a trap that's good to avoid. Get comfortable with different ways of writing something that, while they might have different tradeoffs, accomplish the same thing, and try to see past that. Understand that most code wasn't written by anybody--lines 1 and 3 were written by Alice a year ago, line 2 was written by Bob 2 years ago, and line 4 was written by Alice yesterday. `git blame` is very useful for seeing the change in context, which can give a lot of insight into why it's written that way, but usually the author isn't very useful to know, unless you're planning to ask them about it. Sometimes it's useful if you happen to know that the author isn't very familiar with something when you're wondering why they didn't use it, but try to keep in mind what the actual benefits of your way are, whether they're especially pressing, and that the other person might have written it differently because they were thinking about other concerns that you forgot.

I agree that “who wrote this” is dangerous, and git blame is a terribad name. I will say though, if you can avoid value judgements, then knowing who wrote a block of code is super valuable in a legacy code base. I’ve found that every dev I’ve ever worked with has very real strengths and weaknesses. And knowing who wrote a piece of code can drastically reduce the time it takes me to find hard bugs. It often goes something like, so and so tends to forget certain kinds of edge cases, but they never seem to screw up this kind of logic... so I bet the problem is related to... ah found the problem. But never blame someone for creating bugs, unless it’s really egregious, and then, only if you can help them with better habits going forwards.

Yes, "blame" is not a good word.

Use "git annotate" instead.

I really like this approach of using git blame, it's original thinking and highlights how much human components there are in developing.

While lots of legacy code emerges organically the way you describe, there are in fact many people in the industry who I'd call "legacy coders." People who saw Dijkstra's "Goto considered harmful" and scoffed, "all these 'for' loops are much less readable than my 'goto loop1' solution." People who use global variables because parameter-based implementations are "needlessly complex."

Basically, not everyone works for Google.

You say that, but Golang has gotos, while being a very minimal language. Not everyone at Google is an amazing developer that's fully up to date with best practices and patterns.

Not that that needs to be said, no matter the company (if it's of any decent size.)

It’s often helpful to know who wrote a line of code, because then I can put myself into their shoes and try to figure out what was going on their mind when they wrote it.

I’ve always found the svn alias ‘svn praise’ pretty entertaining for this reason.

git has "git annotate"

Assuming those lines were getting out of hand, I think it would be a valid question as to why they were not tidied up during the review of the line 4 addition by Alice.

It’s Friday afternoon, you are exhausted after a busy week, the business is pushing for a fix before you leave and you have committed to be home by 6pm so your spouse can go out.

`git log -p` is vastly superior to `git blame` for determining why a file is the way it is.

That gives you all the history (or all the history of a file).

Git blame quickly gives you the commits you are likely interested in, then you can use them as a starting point for your git log digging.

I've had that happen several times, but once I actually did the inverse.

I was working on an extraordinarily bad codebase, and stumbled upon some modular, reusable code that made my life way easier. I wondered who wrote this rare gem in that pile of shit, and checked `svn praise` for a change.

It was me.

It would have been the highlight of my then short career, if not for the fact that it meant there were no other semi-competent people on that project.

This is really funny. So good. I ask all the time, "Who wrote this shit??" knowing it was probably me.

Honestly, this is usually a good sign. I'll code at the edge of my current skill. Six months from now, I hope I can look at that code and consider it primitive from where I hope to be then.

That is the only time I dare ask it. When else do I dare? Someone might take it the wrong way otherwise.

*genius