ARGH this triggered a bit of PTSD for me…
“We’re going to convert these COBOL applications to C#, and you need to test that the new application works exactly the same, including the same bugs as the old application.”
“Ok, where’s the specifications and test reports of the old COBOL applications?”
“They were lost to time, we don’t know where they are.”
“Ok, so how are the developers going to write the C# code?”
“They’re going to read the COBOL scripts and recreate them into C#, we advise you do the same.”Cue me spending a month trying to decypher the COBOL gobbledigook into inputs and outputs, and write testcases based on that. And after that month was up, and I had delivered my testcases, they told me that my services were no longer needed.
I had delivered my testcases, they told me that my services were no longer needed.
Gee, I wonder how all those specifications and test reports became “lost to time”…
Hey! This was my first real job. Is Matlab code written by physicists who just recently learned programming.
My first thought immediately was of academia also.
Ngl that’s like baby levels of nasty code. The real nasty shit is the stuff with pointless abstractions and call chains that make you question your sanity. Stuff that looks like it’s only purpose was to burn the clock and show off a niche language feature. Or worse than that even is when the project you inherit has decade old dependencies that have all been forked and patched by the old team
If all I had to worry about was organization and naming I’d be over the moon
My favorite was an abstract class that called 3 levels in to other classes that then called another implementation of said abstract class.
And people wonder why no one on our team ever got shit done.
And hard casting onto the wrong class because a neat function lives in there (who will detect you did that and treat you a little different because you don’t have all the resuired data in that class instance) as a “quick fix”
Former coworkers: “oh, these two lines are the same in function x and function y. TIME TO ABSTRACT”
Such DRY
Git commits with message saying “pushing changes” and there are over 50 files with unrelated code in it.
“stuff, lol”
Stuff1, stuff2 …
In the past I had commit messages with change numbers from a system, that was no longer in use.
So the commit just said “CH-12345“. It is the kind of annoying, where you can’t even really be mad at someone.
I put my ticket numbers in my tickets, but i also try to describe the change too (e.g. “Fix bug where xyz happens due to zyx action”). Also, atomic commits: commit only related changes.
Yes, it takes longer to commit large changes, BUT you can easily merge the commits, and rollback only what needs to be rolled back.
“fixed issue”
“Fix for critical issue.”
Followed by an equally large set of files in a commit with just the message:
“Fixup”
And then the actual fix turns out to be mixed in with “Start sprint 57 - AutoConfiguration Refactor” which follows “Fixup”
The real nasty stuff is not code it’s in proprietary blobs which can only be edited through proprietary software. The documentation is shit (because the editor also sells training) and there are no communities (because implementation specialists think having secrets is having an edge).
Even worse than there being no comments: the code is extensively commented, but its function has drifted from what the comments describe to the point where they are actively misleading.
The good old “signal left when switching to right lane.”
I mean sometimes you gotta trick the compiler to get a leg up in runtime.
The team lead has spend the last two months writing a permissions library that nobody understands how to use or debug. He wrote it with Cthulhu at his side. Soon not even Cthulhu will understand it.
Well, I’m the only maintainer for my project, so ha! (I only have myself to blame.)
That just means my boss will have to do all the work. Ha, what an idiot. Wait… aw. 🙁
There are no comments in the code
At my last job, I was assigned to a project being run by a straight-out-of-college developer who felt that not only were comments unnecessary, they were actually a “code smell”, a sign of professional incompetence on the part of whoever added them. It’s an insane philosophy that could only appeal to people who have never had to take over an old codebase.
I kind of get the idea that code should be self-documenting, but at the same time, there’s so many crazy business rules that comments are basically a necessity if nothing else other than to explain why in the hell the crazed mess that provides the required functionality for the business rules exists.
That’s typically what people who advocate for less/no comments really mean. The code should self explain “what” it does, but if the “why” isn’t obvious (i.e. confusing business logic) nobody argues that you shouldn’t comment it. That’s how I’ve worked in every company I’ve been at (and all developers around me) from 50 person start ups to >2k people. It’s really common mentality with Ruby developers
Anyone complaining about commenting should be forced to code in assembly for a while.
Yeah some comments are not useful
# returns the value as a string return str(user.id)Some comments are
# returns the user id as a string because ZenDesk's API throws errors if it gets a number. # See ticket RA-1037 # See ZenDesk docs: https://etc/ return str(user.id)
Or, it appeals to people that have had had to take over an old codebase where the comments were all lies.
“Code never lies. Comments sometimes do.”
It’s funny, the exact same logic applies to method and variable names. There’s no compiler that ensures that a method’s name accurately describes what the method does or ensures that a variable’s name accurately describes what the variable represents. Yet nobody ever says “you shouldn’t use descriptive method and variable names because they might be misleading”. And this is hardly academic: I can’t count the number of times I’ve run into methods that no longer do what the method name implies they do.
And yet method and variable names are exactly what people mean when they talk about “self-documenting” code.
That’s fair!
I don’t know that I could have stopped myself from asking whose nephew they are and I’m just a hobbyist
That time I started a new job and my first task was “fix bash”…and then I discovered a multi megabyte monstrosity called “bash.sh”
Time to go around commenting stuff yourself!
Be careful, you might delete the database if it was designed by Tom.
Could you post a link to what you’re referencing? I think I’ve read it before but I can’t seem to find it via web searches anymore.
https://thedailywtf.com/articles/the-inner-json-effect
“Tom is a genius”
I’ll get shit on for suggesting it but this is a great use case for AI: comment the code and generate some basic docs. Even if it’s wrong it’ll give you a sense of where to start looking for flows.
Problem is, you won’t know what the AI screwed up until someone breaks everything.
“Documenting the code base will be your first task for the next month to help show us how well you understand the codebase.”
Cursor please document this codebase
Translation: please help us understand our codebase. We’re paralyzed by fear.
Jesus i worked at exactly this kind of project once. The only other dev was also very hostile and protective of this position. He did not want me there in the slightest. Took about 6 months before we cancelled the contract since this dude was just actively harrassing me in Teams DMs on the daily and he just ignored all my concerns regarding maintainability since “he could understand the code” and i was probably just “not experienced enough”.
Don’t downplay what this does to your mental health. 5 years of workplaces like this and I’m now starting to see a therapist due to exhaustion disorder symptoms in my goddamn 20s. Take care our there!
So infuriating when you have some dickhead making themselves unfireable by intentionally convoluting the codebase and chasing out any other hire. And even worse when management bought into it and think the guy’s an actual irreplaceable genius.
Probably even believes it himself. I hate narcissists.
Reject merge.
Documentation is part of design.
Do it or die in obscurity.
Something that I’m disproportionately proud of is that my contributions to open source software are a few minor documentation improvements. One of those times, the docs were wrong and it took me ages to figure out how to do the thing I was trying to do. After I solved it, I was annoyed at the documentation being wrong, and fixed it before submitting a pull request.
I’ve not yet made any code contributions to open source, but there have been a few people on Lemmy who helped me to realise I shouldn’t diminish my contribution because good documentation is essential, but often neglected.
The fact that documentation and comments can’t “fail” if the underlying code changes is a real problem. I’ve even worked at places which dictated that comments had to go directly above or even beside (inline) with the code they were explaining, so they would show up in any patches changing the code.
What do you think happened? Yup, people would change code and leave the outdated (and wrong) comment untouched, directly to the right of the code they just changed.
Hell, I was one of those people, so I get how it can happen.
Code was written before git was invented.
Tell that to Linus.
Shit needs syntax and documentation.
Anything submitted needs to be reviewed before merge/push. Syntax and Documentation rejections don’t result in errors. Get your shit right first. You are trading on someone else’s rep with this.
If you want to push your own code do it with a separate pull. If you want it merged that carries responsibility to the person carrying it.
https://en.wikipedia.org/wiki/Git
Initial release 7 April 2005; 20 years ago
Oh ohThere was sccs (1973) and cvs (1986) before git.
Yeah but you merged as you wanted, usually anyway.
Oh merging was a total crap shoot with sccs. It was better with cvs, until it wasn’t and then it was very very bad.
I once worked with a guy who would actively remove everyone else’s comments any time he touched someone else’s code. Only comments he made during code reviews? “Does this comment need to be here?”. The code was a barren, commentless place.
I was part of project that scoffed at the idea documenting code. Comments were also few and far between. In retrospective, it really seemed like they wanted to give that elitist feel because everything reeked of wanting to keep things under wraps despite everything being done out in the freakin’ open.
