This is getting way off topic of the original project, but as an older (40) programmer, I've learned that even if code is objectively bad you generally shouldn't call it out unless you have the full context of how it got that way.
I write code every day, some of it is great, most of it is good, some of it is shit (working shit, but shit nonetheless). The reason some of it is shit varies: time constraints don't allow for the proper solution, working around a crappy abstraction that I can't control, etc, but if you decide to focus on some snippit of the shitty code I wrote and extrapolate that to assess my skill as a programmer I reserve the right to extrapolate that your experience doing real world programming is pretty limited, because otherwise you wouldn't be so naive.
exactly. I am in the same era as you and unfortunately haven't managed to hook facebook or google to hire me so my day consists of making the most out of the shit I am served each and every day. You know that 3 line shell script that accounts only needed to run once a year ? Yes that migrated into an 20,000 line perl module that HAS TO run every night without fail but nooooo do they want to (pay to) re-engineer it ? No. Because the customer would not benefit.
The most fun I have at work now is "try to get the most audacious python module through the firewall and then get it approved by the project manager as they have absolutely no clue about what I do".
Sorry kids but unless you make it (and make it big)... that's you in ten years time.
If I am honest, I have got over the "OMG what's it written in?" stage. If it works and if the (time saving per run * the times I need to run it ) > time it would take to write it myself, then .. that's a success. Then.. move onto the next issue to get some project tasks done, contract renewed, kids fed, mortgage paid etc etc etc.
I stopped worrying much about so-called bad code a long time ago. Reading eye-watering, mind-numbing code is practically a pre-requisite for working on any non-trivial enterprise system at a business of any reasonable size. In many ways, you come to enjoy the challenge of it. I've had to read code written in an almost obfuscated manner in languages I'd never previously worked with before. You get used to it. You learn to read and grok just about anything.
On the topic of massive Perl scripts, I once worked on implementing a system that was an unholy maze of Perl, Pro-C, Pro-COBOL, Oracle Forms, Java, and PL/SQL. It was the first time I'd ever had to read and write Perl and Pro-C. I even remember reading Pro-COBOL at one point to debug a problem. Good times.
Since the above is somewhat tongue-in-cheek, I'll clarify that I certainly think we should strive to write excellent code and constructively help each other to that end. We should probably be very slow to dispense judgement but quick to share carefully considered, contextually relevant advice. You really do need to understand the context under which something was written to make any useful statements about goodness or badness (which is still probably not that helpful a measure). Something that looks bad at first may be fantastic work considering the circumstances under which it was written.
I write code every day, some of it is great, most of it is good, some of it is shit (working shit, but shit nonetheless). The reason some of it is shit varies: time constraints don't allow for the proper solution, working around a crappy abstraction that I can't control, etc, but if you decide to focus on some snippit of the shitty code I wrote and extrapolate that to assess my skill as a programmer I reserve the right to extrapolate that your experience doing real world programming is pretty limited, because otherwise you wouldn't be so naive.