lol yeah that guy should totally be fired.
lol yeah that guy should totally be fired.
Unfortunately, politically, the kind of shop which fires a dev for choosing another platform is unlikely to approve a PR which bypasses the ORM (maybe also a fireable offense!)
Writing initial version of the code is only a small part of it. Maintaining and enhancing it is much harder.
What is the company going to do if the new endpoint went down and the author is on vacation?
A dev ran up against the limitations of one platform and solved the problem by choosing a platform which didn't have those limitations. And management responded by banning the new platform.
How long do you think that dev is going to stick around in an environment like that?
Ultimately this comes down to what sort of environment you want to foster. One approach leads to an environment where devs have lots of freedom, and that creates certain problems. The other approach eventually leads to an environment where even the choice of editor / IDE is dictated, and that creates a different set of problems.
I'd favor attracting a bunch of smart folks and give them as much freedom as possible. I'd much rather deal with the kind of problems which that sort of environment creates.
Right now, I am responsible for maintaining one of our internal services. If someone tries to rewrite part of it in Clojure without extensive internal discussion first, I'll do all I can to stop it (and I am not "management" at all). And most people on the team will agree with me.
If the original dev would not want to stick around after that, good for them. If they do not care about teammates at all, they would likely be happier working alone anyway.
After all, single-handedly moving to a new technology and then forcing everyone else on the team to support it is impolite and annoying. Clojure is nice, but I don't want to be forced to learn it because the server went down on my shift.
(this is different if the service does not need to be up all the time, or the company is very small. But if you are talking about API endpoint being overloaded, the chances are, neither of this is true)
“single-handedly moving to a new technology and then forcing everyone else on the team to support it is impolite and annoying”
The dev you’re describing has indeed made some bad choices and I wouldn’t want to work with that guy either.
What I had in mind was more along the lines of “check out this thing I made, what do you think?”
Totally ok responses would include: “let’s just bypass the ORM here instead”, “let’s divert 5% of traffic to it and see what happens”, “this stays a prototype until you reach a bus factor of 2”, etc.
I see this a lot and I just don't get it. Is a mechanic who uses air tools trying to "prove how clever he is"?
Knowing more than one tool allows you to choose the right tool for the job. Assuming arrogance and a motive of "proving cleverness" sounds like a great way to pick a fight.
a mechanics' tools would be IDE, build tools etc- I'm not interested how every dev uses personal level tools.
But just writing a program with a new dev stack without thinking of the possible consequences is just plain unprofessional.
But if I give my car to mechanic for carb cleaning and tune-up, and get it back with fuel injection system and explanation "it is better anyway", I would be very unhappy.
Yeah, introducing a new ecosystem to mask bad DB design or bad queries because she is lacking basic SQL and relational foundations is how I envision the typical 10x programmer.