I’m also coming at this as a coworker, not a manager, plus I’m a grad student now so I deal with these types as students. JMHO but you be firm and drill home the point that the goal is not to write code that demos what a smart little hacker he is, the goal is to deliver code that works efficiently and can be read and maintained by other people. Because other people is who will be maintaining it 1,3,5+ years down the line. Also I often find these guys like to get into long arguments about why X is stupid and Y is Obviously Correct. It’s recreational for them, and competitive so they’re not going to give in. Eventually you have to say “Well, this is what we’re doing.” and walk away and get back to your own work.
Also you say that he “got away” with rewriting a whole bunch of code, but if you supervise him then how did he “get away” with it? He’s not a customer, the requirements docs don’t give him legal rights to do what he wants to the code base. You can go over the paperwork and stop him if he is making an obviously bad decision. If he’s reporting to someone else for some particular project then you can go to that person and raise your concerns.
We used to call programmers machines that converted caffeine, nicotine, and sugar into code. Maybe adding other drugs affects the quality of the product.:rolleyes:
Didn’t necessarily mean you, but management’s fault. And you are addressing the problem, where your predecessors didn’t. You have identified the big problem though, the effect on other personnel. Man, firing people sucks! But the lasting effects of not doing so when justified can be worse. Like maybe you getting fired. That probably sucks more.
By the way, do you have other clues about this person’s personality? Sometimes it works better to address the non-technical aspects of a problem. For instance, I’d guess he needs a date.
If you don’t have process documents that all team members have to follow its time you wrote some. This can be a really big deal if you have nothing to start with. Better late than never.
The SOAP handler thing is very weird. How long has he been working at your place? Maybe he’s looking for another job and wants to be able to say he wrote all of this special bizarre stuff. One of the earlier posters made a good point in that you ought to tell the guy “Look, we don’t want a custom SOAP handler and we’re not paying you to write one and we’re not putting it into our product. Talk with me BEFORE you do anything like this. If you’re not sure if you need to talk first, then you DO need to talk first.”
Also – Maybe he’s working on the side? Is he using your company’s resources to produce code for a third party?
Can you implement code walk-through policy? I’ve worked in a lot of different shops, the ones that put out the best code were the ones that took the time to have a peer to peer code walk-through. The walk-through team included a regular peer and either team lead or sr. programmer.
Part of good code IS readability. It’s not just weather it works or not. Therefore he is writing bad code even if it works. Khadaji does a great job of how to handle him after a code walk-through. Be positive; but if he’s obfuscating the code; it’s wrong.
So if he were producing good code, but working so much that he was outdistancing all the other team members, your response would be to sit him down and say, “Slow down, you’re making everyone else feel bad?”
Well to be fair there’s more to releasing a product than producing good code. When you need to rewrite sub-systems, you need to choose the appropriate time. If a team-member goes off an re-writes a component it can have impact on other teams.
For example:
The component might have been inferior designed, but well-tested. His re-write made it superior designed, but lightly-tested.
I am an IT manager. I have been in the industry since 1979 and been a manager since 1988.
You need to discuss this with your manager. Who writes his performance appraisals? If I were your manager, I would fire him. This behavior is counterproductive. He is not following direction, his work is not meeting standards. He is not providing value, regardless of the endless extra hours. If HR won’t let your manager can him immediately, then your manager needs to give him a performance appraisal saying exactly what you said in your post.
I understand you don’t have direct firing authority but you need to escalate this. This is not a situation you can massage on your own and just hope everything works out.
In my neck of the woods its important to flag this with higher levels of managements before it gets to the firing stage. Partly so you can be sure you’ll be supported through the performance management process, and partly so the person in question gets the message that this is serious stuff.
If you cant do that without risking him being fired, then you’ve got serious problems already either structurally or with his performance and you’re risking yourself for his sake.
This. Only make it a formal code review. If you don’t know what is involved, look it up and use what works for you.
Manager are not supposed to attend, but I think you are sufficiently non-managerial enough to do so. And it sounds like his co-workers will be eager to give him suggestions.
But a few things. He may not be covering his ass, he may actually not know how to program any differently. I bet he is coding and not planning, and thus finding cases he had not thought of while writing, which can create ugly and apparently over-engineered code. He also sounds like a compulsive programmer - check out Weinberg’s “The Psychology of Computer Programming” which is a classic. He might be working those hours because that gives him maximal enjoyment. Hell, hours I spend coding are a lot more fun than hours I spend in meetings.
It also sounds like you need some sort of source code control process which would have kept him from ripping up the application with no one knowing. It sounds to me like you need a process where no one is allowed to code (or at least check anything in) until his plan is reviewed. No 20 page formal documents, just some ppt slides showing the problem and proposed solution, which would allow others to tell him things he hadn’t thought of.
He sounds like he was very under-managed before. Maybe he intimidated his old boss. You have a great opportunity to turn things around.
Actually I’d fire the old manager before I’d fire this guy. He was allowed to run wild, there were no controls or reviews on the code that he wrote, and as far as I can tell there was no development process enforced. This guy might be a great programmer with some proper training and feedback. When you never tell a kid “no” they run wild - and that means enforcing the “no”, not feebly saying it while they tear around a restaurant. Yes, theoretically this guy is an adult - but he’s not acting like one, is he?
I’ve also dealt with people like this as a coworker.
The long hours are demoralizing for the rest of the team because it makes them look bad for not working as long. I don’t care if my coworkers code every minute of their lives, but work on your personal projects outside of work. Tell him this is what he needs to do - it isn’t going to make management think he’s a better worker if he’s spending time x 2 but not producing quality code.
I also wonder if he is self-taught. When you’re dropped into a programming environment without having gone through school, you teach yourself bad habits. I’m only an HTML/CSS monkey, but I was self-taught and decided to go to school partly to get my bad habits beaten out of me. When you don’t know Microsoft has their own SOAP handler or don’t understand the documentation, then you build your own.
Maybe a quick team meeting talking about how we don’t want to rewrite existing things and asking for detailed SVN commit comments so rollbacks can be made if the team agrees on it.
Work life balance. It’s starting a dangerous precedent, either you work time off the clock or you may get fired, which is ridiculous. I think dmatsch is describing a situation where the workload isn’t to the degree that they need to work overtime.
I’m just really biased here though. I worked with a guy who would come to work at 8:30am, work in the office till 6pm, go home and play with his infant son until he went to sleep at 8pm and then program until midnight. He had to do this, because management was messed up and didn’t give any maintenance time to the product so it would have fallen apart otherwise.
Set him to writing unit tests. This should also help improve his design skills. “Working Effectively with Legacy Code” is a must-read.
Gather some code quality metrics on his (and probably everyone’s) work. Of particular interest would be the cyclomatic complexity numbers. Set team goals on keeping that complexity down.
From a distance, it seems like both of these exercises would be valuable for your entire team as well as him.
Unless he is wearing an “S” on his chest, even if he were writing good code he’d crash and burn eventually. But the chances of him writing good code working those hours is pretty slim. It is kind of like the difference between writing and typing. If you were working on a book, you could type for 18 hours a day, but what you’d produce would be crap. (Universal you.) If you give yourself enough time to write and edit in your head, your first words will be a lot better. Will still need rewriting, of course, but better.
I do lots of weird and abstruse stuff, and I force myself to write down how I am going to address it, in English, before I code character one. What I get is a stream of conscious narrative - with lots of twists and turns as I realize I had forgotten something. If that was in my code (as it probably is in this guy’s code) it would be a disaster. My stuff works pretty much the first time except for stupid typos. If I didn’t think first, I’d have to throw lots of stuff away.
You guys get paid based on the number of hours you work. We don’t. Good code is not a linear function of hours put in. Barry Boehm, a famous software engineering researcher, found orders of magnitude difference in the quality of programmers. This guy sounds like he is low on the scale trying to look high by lots of hours - or he might just be compulsive.
I have zero personell management skills, so I won’t try to address that aspect of the problem. However, I will share a lesson I just learned on a project that I’m winding down now.
You should have written coding standards and peer reviews that use those standards as part of their criteria. You should keep a record (minutes, if you will) of the reviews.
If he/she in sincere in wanting to do a good job, the written standards give them a ‘checklist’ to follow and they will feel good about meeting the criteria.
If he/she is not sincere or has a hidden agenda, which is what happened on my project, you have a record of their performance and evidence that they were not following direction. I failed to do this and I realized it too late.
I would emphasize that one goal of solid production code is that it can be maintained by someone else two years later.
Anyone who has enough time in a company eventually finds themselves looking at their own code five years later—code they never imagined they would see again.
This is a humbling experience and helps underscore the importance of maintainability.
A second point to emphasize: in architecture design, simpler is often better. There is strength in fewer points of failure and increased transparency. Point his tuning and tweaking efforts in the direction of making the simplest solution possible that gets the job done, with as few failure points as possible.
There is a certain elegance in creating such a design.
By making it a challenge and emphasizing his strengths, hopefully you can redirect them.
If you seriously think he is consciously creating “job protection code” then there are other issues to address, but I am not sure he is doing this intentionally.
I used to write all kinds of hacks and put lots of bells and whistles in my apps, and over time I have shed some of those habits. These days I aim for following whatever standards others have laid out before me and not touching what isn’t broke. It’s hard though—how can one ignore seriously jacked up code when you’re going in to make a few modest changes?