And I answered that - yes, because no human being can keep that up very long. I also doubted the possibility of stellar code and long hours mixing - not for long.
But the long hours are the least of his problems - lots of people write bad code working 9 - 5.
Based on what the guy said, yes, it is a problem. Re-writing entire systems that don’t need to be re-written is not just bad for morale, it’s also bad for maintenance purposes, and uses up a lot of costly QA resources. Writing the code is only the first half of the actual process of deploying production code. Finally, I don’t think it is possible to separate good software engineering skills from having the ability to prioritize work efficiently. If a mechanic sees that everything is broken, when it isn’t, is it likely that he going to be a good mechanic or one that you want to hire?
The question itself is a bit of a contradiction. On real-world projects, with very few exceptions, stellar code does not come from loners or rock stars – because what makes code good is not just that it works, or is fast, or is a particularly clever solution to any problem. Good code must also be engineered according to process and in concord with the rest of the project. Communication is vital for code quality in a non-trivial project.
One other question: I’m not a lawyer, but my understanding is that writing a good brief for a case which isn’t standard is a creative exercise in logic. Would you want someone to write one on two hours of sleep and present it to a judge? Do you think someone working 18 hours a day, day in and day out, will be able to write good briefs?
I think the situations are somewhat similar.
Meth isn’t unheard of. An acquaintance of mine used to do some coding on meth, to make rough deadlines and such, since he had a roommate who was using and then selling the stuff, and he started experimenting with it.
Been there, seen that. I once took over a project from a man who had spent long hours specialty coding his (rather simple) project to make it so that no one but him could run it. I spent about 40 hours yanking out completely pointless ‘check this file and do x’ code and got the thing down to 15% of it’s former length and 10% of it’s former run-time. Instead of him spending all day running and tweaking it, I submitted it at the beginning of my day and gave it to the guy who needed it an hour later, with no other work.
The bottom line is the quality of the code and number of defects. If his code isn’t maintainable by other people, and if it contains a higher number of defects than acceptable, then his code isn’t worth shit. Which means HE isn’t worth shit.
Having once been a Project Leader, I would say that you need to address his coding quality and work on getting clean, maintainable, working code out of him. Address this as your first and (initially) only priority in dealing with him. If you can’t get this, then you need to take it up the food chain.
3 times the code produced each day may impress some managers above you, but if it’s all unmaintainable garbage that doesn’t work, then he’s not actually producing anything of value.
That is what happened to me on the project I mentioned upthread. Management was happy that he was making the “percent complete” line go up on their powerpoint charts. I realized the gentleman had made a long career out of telling management exactly what they wanted to hear.
I got behind on reviews and I didn’t have written coding standards at the beginning of the project, so I didn’t have a metric to show management that demonstrated the number of defects or the amount of rework we did on his code. I don’t think it would have mattered much, anyway.
I’m a developer, and the situation seems kinda bizaare. I gather that you’re using C#. Is he doing things like over-using design patterns, using abstract factories and dependance injection for everything?
“Yeah, what happens if we want to transition to a new DateTime type? With DI, all we do is change the registration of IDateTime from my DateTime (which inherits from System’s DateTime), to ExtraLongGeologicDateTime.”
The personality type described in the OP isn’t common, but it isn’t unique, either. I’ve ran into it before. It’s not so much design pattern abuse as it is… overengineering. Hard to explain. Perhaps a real-life example would be better:
A script for running a simple command – that most programmers would do in a simple shell script – would turn into a monstrosity with one file containing all the constants, another file containing the “grammar” to validate the output of commands, another file with a carefully written parser for the input, another carefully written parser for the output, a very thorough inspection of stderr to make sure errors are caught, and so on – to execute the same fucking system command on a cron job everyday. And it frequently failed when slight updates to the underlying command broke all his carefully reasoned assumptions.
Yup. You got it. This describes the guy to a T.
He’s created abstract and delegate classes, and has a – bizarre – dependence structure. I spent the weekend going through the code, and consistently met with “WTF is that”, and “where the hell is this value coming from”. His code is loaded with compiler directives. I fucking hate compiler directives.
And we all agree that documentation is a good thing, right? I have never seen so much documented code in my life. Paragraphs! I guess if I praise him for anything, I’d praise him for his copious text-book like documentation.
Take this:
You have a simple read/write boolean property of a class. Simple, right?
bool bProp {get;set;}
This guy created an entirely separate class to define the property. This looks like C code structure.
He’s got to be OCD!