How I spend my days at work working with legacy code:

* Writing tests before I do anything
* Noticing that i cannot write tests because of antipatterns. Lots of them.
* Refactoring to make at least a tiny bit testable.
* Then writing tests.
* More rewriting and refactoring
* Finally adding that one feature my boss asked me for
* Writing tests for that new feature (my do that before implementing)
* Explaining to my boss why it took me so long and agreeing on stopping writing tests.
* 2 days later: explaining why i still broke something.

But in the end my code works just fine.
my colleagues handle things differently. They just ignore problems as long as at least one feature works a bit.

Last week our department drama queen was showing off Visual Studio’s ability to create a visual code map.
He focused on one “ball of mud”, vilifying the number of references, naming, etc and bragging he’s been cleaning up the code. Typical “Oooohhh…this code is such a mess…good thing I’m fixing it all..” nonsense. Drama queen forgot I wrote that ‘ball of mud’

Me: “So, what exactly are you changing?”
DK: “Everything. It’s a mess”
Me: “OK, are any of the references changing? What exactly is the improvement?”
DK: “There are methods that accept Lists. They should take IEnumerables.”
Me: “How is that an improvement?”
<in a somewhat condescending tone>
DK: “Uh…testability. Took me almost two weeks to make all the changes. It was a lot of work, but now the code is at least readable now.”
Me: “Did you write any tests?”
DK: “Um…no…I have no idea what uses these projects.”
Me: “Yes you do, you showed me map.”
DK: “Yes, but I don’t know how they are being used. All the map shows are the dependencies.”
Me: “Do you know where the changes are being deployed?”
DK: “I suppose the support team knows. Not really our problem.”
Me: “You’re kinda right. It’s not anyone’s problem.”
DK: “Wha…huh…what do you mean?”
Me: “That code has been depreciated ever since the business process changed over 4 years ago.”
DK: “Nooo…are you sure? The references were everywhere.”
Me: “Not according to your map. Looks like just one solution. It can be deleted, let me do that real quick”
<I delete the solution+code from source control>
Me: “Man, sorry you wasted all that time.”

I could tell he was kinda’ pissed and I wasn’t really sorry. :)

You know what's fucking horrible?

Implementing new features to an Android app in production that another dev wrote...

...which has no architecture, no documentation, no modularity, no testability, everything runs on the UI thread, filled with spaghetti code and it somehow works smoothely so I have to not fuck it up.

Oh and I'm also a junior. So fuck me, right?

So in our last retros some of my colleagues suggested to (forced) limit the number of lines per method in order to "maximize our code quality".

In the one hand I can see the benefits of this, such as easier testability when having more sperate testable blocks of logic.

But on the other side their code contains lots of such one or two lines private methods which get most of the cases not more than one time called. (And which I then can't even test separately)

I don't understand how this should help...
Is this really a thing? Am I just not "clean" enough?
(it's c# btw)

Someone else had to work with that turd of WSO2 Enterprise Service Bus?
I hate everything of it: its fucking buggy IDE (a lazy fork of Eclipse in which they didn't even bothered to replace the Eclipse icon), its cryptic XML language which makes basic operations such as accessing a JSON field a complete PITA, its fragility (often syntax errors doesn't get caught by the compiler but causes runtime errors which are hard to diagnose) its shitty testability...