Re^2: Is this OK?

My evil plan failed when the perpetrator was too lazy to respond.

While i'm not the original perpetrator, i might have something. If you really need some horrifying code to be happy, i happy to look into my own source code archives this evening and have a go at trying to dig something up from one of my very early perl projects(*). Can't promise anything, haven't touched those repos in nearly 18 years, but they should still be readable.

(*) In a movie, this would be the time to [Cut to black&white flashback with a swirly transition]
perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'
Comment on Re^2: Is this OK?
Select or Download Code

Replies are listed 'Best First'.
Re^3: Is this OK? by eyepopslikeamosquito (Archbishop) on Apr 12, 2022 at 21:02 UTC
> If you really need some horrifying code to be happy... Ha ha, it only makes me happy when I understand the root cause of how it happened in the first place. When I see truly horrifying code in production at work, I'm not interested in ridiculing the individual responsible, I feel profoundly curious as to how on Earth such code made it into production in the first place ... and feel an irresistible urge to uncover the root cause to make sure it doesn't happen again. One common cause of ridiculously bad code making it into production I've seen is when the non-technical manager (who never looks at the code) rates an individual's performance based on KPIs, such as productivity. Team-based KPIs produce higher quality and more maintainable code in my experience. These topics are touched upon in: Nobody Expects the Agile Imposition (Part III): People Organizational Culture (Part III): Spaceflight and Aviation Five Whys	[reply]

Replies are listed 'Best First'.

Re^3: Is this OK?
by eyepopslikeamosquito (Archbishop) on Apr 12, 2022 at 21:02 UTC

> If you really need some horrifying code to be happy...

Ha ha, it only makes me happy when I understand the root cause of how it happened in the first place. When I see truly horrifying code in production at work, I'm not interested in ridiculing the individual responsible, I feel profoundly curious as to how on Earth such code made it into production in the first place ... and feel an irresistible urge to uncover the root cause to make sure it doesn't happen again.

One common cause of ridiculously bad code making it into production I've seen is when the non-technical manager (who never looks at the code) rates an individual's performance based on KPIs, such as productivity. Team-based KPIs produce higher quality and more maintainable code in my experience. These topics are touched upon in:

[reply]