3 ms·

Everyone wants to talk about the bad hire that can’t “program their way out of a paper bag but I want to talk about another kind of animal. The one who seems to

by zcw100 6y ago

Everyone wants to talk about the bad hire that can’t “program their way out of a paper bag but I want to talk about another kind of animal. The one who seems to know what their doing on all the coding tests. You hire him thinking he’s great. Gets right to work , cranks out a ton of code, is working weekends etc. Then you look at the code and it’s a crap ton of idiomatic garbage, seemingly clever hacks, etc. The rest of the teams productivity goes to shit because no one can understand Glen’s weird code. I worked with a guy who spent weeks writing a CSV parser. Firstly there are a ton of libraries to choose from. Secondly while CSV is simple it can be surprisingly difficult to handle all possible options. When we got a look at his code it was filled with really odd usage of reflections and dynamic code generation. This was supposed to process huge files so performance was supposed to be a priority. Or the other guy who complained daily about maven then one day he comes in on Monday right before a major deadline with a big shit eating grin on his face and when someone finally asked what he was grinning about he said he spent the weekend replacing maven with ant. I’ll take someone who can’t program their way out of a paper bag over one of these guys any day. At least when they’re in the paper bag they can’t destroy anything.

dilyevsky 6y ago
Do you not have coding style guidelines and code reviews? Unlike incompetence this behavior can be corrected easily.
theamk 6y ago
We've had a case like that in one of previous jobs. It was not very bad. The key is correct procedure. We've had required code reviews for every bit of code written. Those are always harder for the new people, but exactly how hard depends on the person. I have seen PR reviews which require major things like "let's refactor those changes into separate class with proper interfaces". And the good old "this code is too hard to understand, let's simplify" As for CSV story -- if you new people can go off for weeks and work on new project without talking to anyone, there is something wrong with your org. You want to have status meetings periodically (weekly? every sprint?) where everyone talks what they are working on, and what difficulties are they facing. Those are really great -- they let the team feel together, they let people whom to ask for help, and they may help discover hidden talents. And we did have people who would spend time doing integration with their favorite IDE's build system. It is not quite "maven vs ant" -- but if this helps them be more productive, why not! Of course this would be still optional, so other people would not have to use this, and it is up to them to maintain the integration.

by zcw100 6y ago

dilyevsky 6y ago

Do you not have coding style guidelines and code reviews? Unlike incompetence this behavior can be corrected easily.

theamk 6y ago

We've had a case like that in one of previous jobs. It was not very bad. The key is correct procedure. We've had required code reviews for every bit of code written. Those are always harder for the new people, but exactly how hard depends on the person. I have seen PR reviews which require major things like "let's refactor those changes into separate class with proper interfaces". And the good old "this code is too hard to understand, let's simplify" As for CSV story -- if you new people can go off for weeks and work on new project without talking to anyone, there is something wrong with your org. You want to have status meetings periodically (weekly? every sprint?) where everyone talks what they are working on, and what difficulties are they facing. Those are really great -- they let the team feel together, they let people whom to ask for help, and they may help discover hidden talents. And we did have people who would spend time doing integration with their favorite IDE's build system. It is not quite "maven vs ant" -- but if this helps them be more productive, why not! Of course this would be still optional, so other people would not have to use this, and it is up to them to maintain the integration.