Hacker News Reader

Comment by bikingbismuth | Hacker News Reader

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 great deal of humility and compassion in that moment.

View on HN

I experienced this same moment when I was ~24 years old and digging through a codebase I'd written a few years prior after returning to a former employer. Once you've hit rock-bottom there's no place to go but up :P.

I've subsequently noticed that those who are quickest to talk trash about nuanced engineering decisions and minor bugs are often the ones with the most fundamentally-indefensible coding practices (5000-line source files that throw innumerable compiler warnings, using deprecated frameworks, explicit silent failure modes, etc). Latent insecurity is a very real phenomenon.

My approach is to just do what I can to unfuck the code without wasting my life on it and then reflect on what went wrong so I can catch the pattern before it gets committed again. I just managed to stop a co-worker from making a mistake that cost my previous company an entire dev's full time attention for years.

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

This is standard development policy at every corporation I've worked at.

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.

... as a service... ;)

You should check out GitLens for VSCode, it makes the process of working with git blame seamless.

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

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

If you want to take that to the next level, accidently address an email to yourself and then complain that the "response" is all but helpful.

I mean... that could happen... hypothetically... to... someone.

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.

On the flip side, I've found my own question a couple times...

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

git checkout BLAME_COMMIT~ && git blame should take care of that.

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.

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

Yeah a "why didn't I" thought occurred to me while I was writing the comment above. All I can say is that it was a long time ago now (15 years), and the notion of leaving notes in the code for future versions of myself (and others) is a much bigger part of my way of working these days.

Well anyone would be pissed if the only documentation was written by some asshole on his first week.

Completely agree. My manager at the time thought it was a brilliant idea to have new people write the wiki when they started, because “they just learned the right way to do it from a senior person!”. This is not something I took with me into my own transition to management.

I’m currently rewriting the first application I wrote on my own.

So much code to do pretty simple stuff… but it worked…

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

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

Technically, a define is the same as hard-coding the string. Practically, at the point of use a define looks like a variable which might suggest it's ok to use another variable. Now it could take something from untrusted user input and you wouldn't notice.

The only thing I could think of is a centralized location of all the format strings could make things easier to translate to another language. But as I stated in my post, it's an internal tool; we don't offer it to other customers as something to install, all our developers speak English, and there are other ways to mark strings for translation (at least on Linux, which this currently requires).

Reply on news.ycombinator.com