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
-
To avoid poorly tested code in prod, code should reviewed and tested before going to production...
I hear you about no concern for quality and a need of ownership but ordering someone to fix their code when broken is the wrong way to go.
Firstly, it's a "too little too late" kind of approach as it won't solve anything. Shitheads will be shitheads...
Second, a code you wrote really well might break another not so good component you did not change. Who should fix it then? You right? Your code broke it! It was working before...
So, it seems you need to consider your unit testing stack and deployment pipeline. Add more efficient and comprehensive automated and regression tests...
Also, there is no shame on fixing production bugs, and no glory on creating new features over an outdated architecture... Be glad your boss thrusts you and your skills. And remember "incompetent people always believe they are the best because they lack the skills to know that they are incompetent" -
@mmcorreia ""incompetent people always believe they are the best because they lack the skills to know that they are incompetent"
Also known as the Dunning–Kruger effect. -
@mmcorreia well part of the problem is my boss is the Approver and well when deadlines are tight (always) anything that seems to work goes. Just attach a screenshot or some simple tests showing it works.
But once it blows up in PROD, the guy that wrote it is not the one that has to clean it up.
It doesn't matter the design is bad or if its O(N^3) as long as it seems to be good enough at the time of release.
And the code is never commented. I'm basically the only guy that comments my code. Most of the time I need to understand the big idea/picture to figure out what the hell a piece of code is doing... or i gotta ask whoever wrote it, what the hell is this doing cuz its got huge functions and if ( if ( if ( ...)
So I'm assigned once again to fix a new someone else created and that seems to be the case whenever there's an issue...
Boss just assigns it to whoever is most likely to be able to investigate it... which is basically me. Other than the little time I can use to develop stuff, I'm usually cleaning up other people's messes.
And these other people are to busy working on new crap to properly explain how their existing code/processes/changes works.
And well the fact that anything breaks in production (that's not due to upstream one off issues) whoever does not think he needs to take responsibility for it.
So everyone else and especially me has to spend time understanding the shit they wrote and fixing it for them.
How do I tell my boss this nicely that we need clearly definitely ownership and whenever a component blows up in prod, the guy that wrote the code fixes it no matter what? Thereby incentivizing him to not write shit code in the first place and be more proactive in making sure it doesn't in the first place since he knows otherwise he's doing overtime to fix it?
Is it just me or is there really no such thing as a dev job where something doesn't blow up due to poorly tested and designed code every other day?
rant
getting tired of this shit