Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Sounds like it could be a him problem or a you problem, depending on what he's actually doing.
All the illusory stuff though, like claiming he's going to act on a story and then not doing it but just refactoring, that's shitty. He should allot time for refactoring and argue for that and then refactor.
He also shouldn't be removing unit tests unless he's replacing them with other unit tests.
But "adding layers" isn't innately bad. I have co-workers that are fine with our Active Record models being hundreds of lines long. Approaching a thousand. Without the want to separate the domain entity embedded in the AR object from the data object that an AR object should be.
Adding that layer (the domain layer) adds more clarity, allows for quicker unit tests, and removes tightly coupled dependencies on AR, allowing your business logic to be free and allowing you to change implementations if you want.
That all being said, priorities. If it's not a business priority, he shouldn't do it. -
I think it's easier to ask for forgiveness than permission, so i understand why he just does it. In the daily business it's just unlikely that someone gets told to reduce software rot, and i think that it's important to keep reused components clean.
That however does not sound like he is doing work that benefits the overall development.
I have a co-worker who won’t stop “refactoring” our codebase. He will go on a long tangent — under the guise of working on a proper story — and then reveal proudly after a few days that he now introduced a new middle-layer into the code which will help us such and such.
I have never seen any benefit from this. I think sometimes cleaning up variable names is nice, but a lot of the things just add noise and complexity. He’s a junior dev, I’m a senior dev. My progressional opinion is that he is doing a bad job. Management doesn’t know the full extent and the lead programmer scolds him every now and then but in the end let’s the code changes pass code review. “It has already been implemented so what’s the harm”.
Then the rest of us are stuck with horrible merge conflicts. I recently noticed that some new business-important unit tests that I wrote were mysteriously gone. Oops — lost in some misguided refactoring I guess. I’m assuming they were failing after the refactor, so clearly they had to go... Fortunately the underlying logic still works I think.
His main tactic in all of this seems to be to just use argumentative stamina. He will lose discussion after discussion but doesn’t seem to care. He’ll just talk and talk. And the in the end the lead tech gives in. And/or doesn’t have the energy to catch the error introduced.
I swear, the company would be better off without him. Maybe even better if we keep paying him but he just cleans the toilets instead. Sometimes I almost believes he gets up in the morning to come to work and just fuck with people all day.
rant