Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
mmcorreia102710dTo 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"
billgates1876510d@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 ( ...)
Your Job Suck?
Take a quick quiz from Triplebyte to skip the job search hassles and jump to final interviews at hot tech firms
Get a Better Job