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

241–250 of 300 posts

Re: Who wrote this shit?

#241

Post by czhu12 »

When I was a junior engineer a long time ago. I wrote a change that someone approved, and merged.

A few weeks later a senior engineer saw the code in passing, proceeded to rewrite all of it, submitted a PR with a 2 page description tearing into the original code. Explaining why it was terrible and unacceptable and then posted the PR into our it into our team's slack channel with some comment like:

"@here everyone please read this PR as an example of terrible engineering"

The code was indeed quite poor, and the lessons were valuable, and I took them to heart. I also spent the next 18 months actively avoiding requesting feedback, in fear of this happening again.

I think as a senior, this kind of behavior tends to really leave a lasting impact on starry eyed juniors.

Something to keep in mind.

Re: Who wrote this shit?

#242

Post by EdwardDiego »

Something I've always tried to drill into ambitious intermediate devs - you're writing the legacy shit of tomorrow, today! And when you're a senior, the next generation of ambitious intermediate devs will wonder aloud at wtf you were thinking when you wrote it, and it's just part of the software developer maturity cycle.

Code-bases grow through different phases along with the company - there's the "we need to ship the MVP, so just comment that out" codebase, then there's the "we're starting to understand the problem domain better" phase, followed by the "I just read a book by Martin Fowler/Uncle Bob, and I'm going to fix all the things", then the "wait, the problem domain is hairier than we thought, let's iterate on this", then perhaps, depending on company dynamics, the "a charismatic senior developer convinced enough people to use , so we started moving towards it" followed somewhat later by "well, the senior dev left, and everyone decided that X was bollocks" moving away...

Or perhaps the entire model of the system changed. Your batch ETL pipeline delivered yesterday's data in time for start of today's business, and that was fine for a few years, but now the sales team want today's data refreshed twice a day, hang on actually, we want it updated every hour, now we want it updated within five minutes.

Code written for old paradigms always look crap when all you know is the new paradigm.

Re: Who wrote this shit?

#243

Post by jimohalloranau »

Seb-C wrote: post #231
jimohalloranau wrote: post #224

Earlier quoted context omitted.

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.

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.

Re: Who wrote this shit?

#244

Post by bumby »

shkkmo wrote: post #220
bumby wrote: post #173

Earlier quoted context omitted.

I suppose, but by that same token standards would be the definition of pre-defined "good enough". In my experience, the nebulous nature of the term is usually a means of rationalizing a sub-standard effort. The benefit of defining that threshold upfront is that it's hopefully more objective, before you let cognitive biases influence your decision making. It really comes down to understanding why the goalposts have mo…

The point is that there is no one predefined "good enough", but rather the level of quality that code needs to reach is context dependent. That is why you end up constantly refactoring a little each time you touch the code as that context has usually shifted.

I disagree. There are lots of examples of standards that define what is "good enough."

For example, NASA has different standards depending on risk categorization and the predefined threshold of quality gradually gets higher as the use gets riskier. A business application is held to a much lower level of quality than software for a robotic mission which is lower than a human rated development effort.

Re: Who wrote this shit?

#245

Post by teaearlgraycold »

alexjplant wrote: post #117
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 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-l…

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.

Re: Who wrote this shit?

#246

Post by teaearlgraycold »

czhu12 wrote: post #241

When I was a junior engineer a long time ago. I wrote a change that someone approved, and merged. A few weeks later a senior engineer saw the code in passing, proceeded to rewrite all of it, submitted a PR with a 2 page description tearing into the original code. Explaining why it was terrible and unacceptable and then posted the PR into our it into our team's slack channel with some comment like: "@here everyone ple…

Sounds like an incredibly toxic work culture. A manager should have stepped in to shut that senior engineer down once that got posted to Slack.

Re: Who wrote this shit?

#247

Post by physicles »

KronisLV wrote: post #138
kgeist wrote: post #133

We have a rule that if you have to leave shit code as it is for a serious reason (time constraints, shifting requirements) you must leave a TODO in the code which poins to a freshly created issue in the tracker which explains what's wrong with the code and how it can be fixed. The ideal is that these issues eventually get fixed, which is often not the case (new features are prioritized over tech debt etc.), but at le…

> We have a rule that if you have to leave shit code as it is for a serious reason (time constraints, shifting requirements) you must leave a TODO in the code which poins to a freshly created issue in the tracker which explains what's wrong with the code and how it can be fixed. This seems like a really sane thing to do! In addition, if you want to keep track of the commits and the context behind them, i've found tha…

Staying close to the code where possible always wins, I think. One code base I worked in had a particularly complex state machine, and right above its main function was a giant ascii art diagram of said state machine. It was perfect documentation.

Re: Who wrote this shit?

#248

Post by JKCalhoun »

sillysaurusx wrote: post #235
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…

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.

A team I worked with had a fun little habit I have since borrowed: you add a "BOGUS" comment next to the offending line. Sort of like:

// BOGUS: assuming 'x' will never be greater than 1024.

Sort of tells future engineers, yeah, I know it's shit.

Re: Who wrote this shit?

#249

Post by Mandatum »

teaearlgraycold wrote: post #246
czhu12 wrote: post #241

When I was a junior engineer a long time ago. I wrote a change that someone approved, and merged. A few weeks later a senior engineer saw the code in passing, proceeded to rewrite all of it, submitted a PR with a 2 page description tearing into the original code. Explaining why it was terrible and unacceptable and then posted the PR into our it into our team's slack channel with some comment like: "@here everyone ple…

Sounds like an incredibly toxic work culture. A manager should have stepped in to shut that senior engineer down once that got posted to Slack.

If someone did this on my team, I'd publicly tear into them if I wasn't their manager for being not just unprofessional, but cruel.

If I was their manager, they'd be forced to apologize for how it was handled to the person with myself and HR on the call, and then I'd force them to read a productive feedback book.

I'd also expect they quit. I usually find people overly cruel at work are especially insecure and in need of counseling. Usually something else driving that behaviour. Most people aren't just assholes.

Re: Who wrote this shit?

#250

Post by Izkata »

jraph wrote: 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"…

I have both experiences. Very broadly speaking, it's code I write for work where I have the "this is terrible" experience (twice something has annoyed me so much I trash-talked it in the team chat, then ran "svn blame" and found I'd written it ~4 years prior), while code for personal projects in general I don't.

I suspect it's having to work around teammates' styles and integrate it my own into it that causes friction at the edges, but I'm not really sure.

Post reply on HN