Have you ever argue with a developer who:
+ have the same level as you
+ on the same position in the company
+ in the same team
+ OLDER than you
+ thinks their code is the best

A few years back, a coworker and I argue about how to implement a feature. I proposed an approach. He proposed a different one. I immediately saw some problems and told him. But hell no, he defended his idea so strongly that I just gave up since I will leave the company soon.

2 weeks later, when the sprint was about to end, the whole team had to work overtime to fix the mess because of his terrible approach.

Did he acknowledge his mistake and tried to fix it at least?

If not, he sucks.

Yeah.. i have the same guy in my team... Unfortunately he negotiated the title "Senior solution architect" in his last "staff interview". Unfortunately this leads to the fact that every decision he makes on our product is taken for granted. No one dares to take those decisions into question. Well i did a few times which lead to a big discussion why a senior software engineer is able to invalidate the decision of an architect. But once I showed the flaws i the decision it became very silent and the issue was never discussed again. Well nevertheless the decision he made went live, failed and everyone asked how this could have happen.
You know: i just do my ground work, get good money because, well.. i am a senior dev, wait for an opportunity to get a better job with at least the same salary and that's it. This company showed me that even stupid people can make clever peoples live bad or even break them, when they have the suitable title

Yeah I have, same guy more than once. He wanted to use the database for everything because “it’s faster than code”.
It took all the energy out of me having to justify and prove basic things that at our level shouldn’t have needed explaining once let alone over and over again.

@TrevorTheRat db is faster than code as in Stored Procedures?

@TrevorTheRat i mean sometimes, but the time spent moving data across the network is always the determining factor unless your app server code is atrociously slow. So if moving more processing onto the database side significantly reduces the amount of data transmitted over the network, then that would probably be faster albeit less easily maintainable. But even then it would be faster primarily because less data is travelling over the network.

I remember a few years ago i was implementing velocity controls at one point and made use of stored procedures because otherwise every request would be fetching a bunch of records only to reduce them to a summary statistic on the app side. I didnt benchmark the two possible approaches at the time since it seemed obvious to me which would win.

@brittle yeah it wasn’t just one thing that was slow and could be done in the database instead.
It was more that the entire app was made up of just dumb anaemic objects. All the logic for the app was in stored procs. They were already afraid to make changes to any of it but still kept following the same pattern.

@PepeTheFrog, of course he didn't. He didn't realize it is a problem, and working overtime with him is a joy.