3 ms·

I don't believe he's a good dev. Sorry.. If he's been re-writing large swaths of code he sucks, and he will cost you way more than you can afford. I worked w

I don't believe he's a good dev. Sorry.. If he's been re-writing large swaths of code he sucks, and he will cost you way more than you can afford. I worked with a dev who convinced the boss to let him and rewrite a large bit of our app. While he did this new features for the existing app were on hold and bugs were on hold. We pissed off clients and management. Eventually a few devs went behind the upper managements back and fixed bugs in the old system, and added minor features. 6 months later he had finally finished.. It was loaded with bugs, and the best part he was the only one "smart enough" to maintain it. Then one Wednesday at 10:30 am he closed his laptop and walked out. None of the other devs who knew his chosen stack would touch his steaming pile of Not_made_here code. Not willingly at least. A year later the original app was once again "the app", and we had a party when we finally killed the project. He's a shite dev. A good dev makes the least amount of changes they can get away with. A good dev makes the customer happy because they pay his/her wages. My suggestion. Get rid of him, before you lose other devs.

john_the_writer 4y ago
Oh.. it was demoralising as hell working with him. I and a few other devs almost left. My recruiter tipped me off that he was likely leaving (when I told the recruiter why I was leaving). I stayed. It was close.
LordGrey 4y ago
You may be right. The developer does, objectively, write good code. Was it so much better than the old code that it was a worthwhile endeavor? That is debatable. Some of it was style change, some of it was idiomatic changes. There was, as far as I know, no performance change or refactoring that eased code maintenance or anything like that. Rather than being a "bad dev" he may be simply a "bad value" -- good, but not worth the pain.
- clintonwoo 4y ago
  Structural change for performance improvement or making the code less error prone are the 2 big reasons I can see for rewriting code. 3rd being if the codebase is just legacy and needs to be updated. There's nothing wrong with an experienced dev improving code structure (at the expense of working on more tickets) but it needs at least an engineering or business justification generally.
blablabla123 4y ago
Rewriting is quite an effort. It's a no-brainer when the existing code is buggy, slow and it's acknowledged by everyone that it needs to be done. On the other hand, not rewriting might mean nobody wants (or is even able) to work on a particular code base. Postponing it too much in the future can mean the project fails and if management doesn't understand in time there's a problematic code base that means devs have no support for what they do. From OP's description it's not possible to see if there are any objective points for the quality of the code (e.g. linting, test to code ratio, uptime)

john_the_writer 4y ago

Oh.. it was demoralising as hell working with him. I and a few other devs almost left. My recruiter tipped me off that he was likely leaving (when I told the recruiter why I was leaving). I stayed. It was close.

LordGrey 4y ago

You may be right. The developer does, objectively, write good code. Was it so much better than the old code that it was a worthwhile endeavor? That is debatable. Some of it was style change, some of it was idiomatic changes. There was, as far as I know, no performance change or refactoring that eased code maintenance or anything like that. Rather than being a "bad dev" he may be simply a "bad value" -- good, but not worth the pain.

clintonwoo 4y ago
Structural change for performance improvement or making the code less error prone are the 2 big reasons I can see for rewriting code. 3rd being if the codebase is just legacy and needs to be updated. There's nothing wrong with an experienced dev improving code structure (at the expense of working on more tickets) but it needs at least an engineering or business justification generally.

blablabla123 4y ago

Rewriting is quite an effort. It's a no-brainer when the existing code is buggy, slow and it's acknowledged by everyone that it needs to be done. On the other hand, not rewriting might mean nobody wants (or is even able) to work on a particular code base. Postponing it too much in the future can mean the project fails and if management doesn't understand in time there's a problematic code base that means devs have no support for what they do. From OP's description it's not possible to see if there are any objective points for the quality of the code (e.g. linting, test to code ratio, uptime)