Slashdot Mirror
Ask Slashdot: How To Handle a Colleague's Sloppy Work?
An anonymous reader writes "I'm working on a new product with one of the more senior guys at our company. To be blunt: his work is sloppy. It works and gets the job done, but it's far from elegant and there are numerous little (some might say trivial) mistakes everywhere. Diagrams that should be spread over five or six pages are crammed onto one, naming is totally inconsistent, arrows point the wrong way (without affecting functionality) and so forth. Much of this is because he is so busy and just wants to get everything out the door. What is the best way to handle this? I spent a lot of time refactoring some of it, but as soon as he makes any changes it needs doing again, and I have my own work to be getting on with. I submit bug reports and feature requests, but they are ignored. I don't want to create bad feelings, as I have to work with him. Am I obsessing over small stuff, or is this kind of internal quality worth worrying about?"
If he's the senior guy and he's getting the job done, then I suspect he knows what he's doing and knows which aspects of the job to focus on and which to ignore because they are useless trivialities. Just stay out of his way.
SIGSEGV caught, terminating
wait... not that kind of sig.
Elegant is supposed to be readable. They're supposed to be the same. If you write code no one understands, it's not elegant, it's obtuse.
It works and gets the job done, but it's far from elegant and there are numerous little (some might say trivial) mistakes everywhere.
If there are functional mistakes, then it shouldn't be working and the best way to complain would be to make bug reports and document your fixes to the code.
However, if it's not buggy and you are refactoring because it's not "elegant" that's much harder to justify or document. Because it kind of sounds like you are complaining about his coding style while he is being productive and writing a ton of less than perfectly styled code that "works and gets the job done".
Don't send him bug reports and feature requests. If he's in charge of something you care about, ask him if he would give it to you (completely!). Then you can fix whatever you want. You will see that there'll be a new guy soon who thinks that your work is sloppy, sending bug reports and feature requests to YOU!
To follow up on the other part of your question (what do I do), here are my suggestions.
Cynical Idealist
Unfortunately, elegant has been re-defined by many a geek as being the shortest possible line of code, regardless of how obtuse it is to read and understand. You can still see people spouting shell scripts or C statements designed solely to show how clever they are, at the expense of readability or maintainability.
Sig Battery depleted. Reverting to safe mode.
VERY few people have the luxury of the time to spend to tweak and get everything perfect and "just so".
Light travels faster than sound. This is why some people appear bright until you hear them speak.........
This sounds like some old waterfall-model guy complaining about a modern "agile" programmer. If you're just doing web crap, quality doesn't matter. Time to market does.
I like working with people who get the job done, quickly and simply, and focus on functional completeness and minimizing defects. People who I can count on to tell them "here's what it needs to do" and I can know that I'll get something out that does what we need.
I don't like working with people who obsess about every line of code they produce and who worry more about documenting things internally than about getting working code out the door.
Sure, given the choice I prefer clean, maintainable code to shitty, sloppy code. But complaining about diagram quality in internal documentation? Unless you are making components for NASA or MRI machines, I think you're obsessing about things that don't matter that much.
The reason the guy in question is senior to you is because management likes people they can count on to get shit done.
I've found that those 'internal demos' pretty much always become production systems if they work. There is rarely such a thing as 'throw-away code', so I've stopped writing stuff like there is.
Exactly. If you want to be that anal about the product you should look for a job in aerospace. You'll fit right in.
-- I have a private email server in my basement.
Is it possible the OP is already the junior developer hired for this purpose? :)
Just do as much as it takes to get the job done successfully, and move on to the next thing.
VERY few people have the luxury of the time to spend to tweak and get everything perfect and "just so".
I'm like the OP in that most of what I turn out is correct and consistent in all details. It doesn't take me any longer than the people that turn out "it works, but it's not pretty (especially if it has to be modified later)," and takes less time later since it's understandable and maintainable.
Cleaning up crappy work, however, takes way longer than doing it neatly or sloppily the first time through.
I find that the cause of this is usually people that don't bother to think any farther ahead than just finishing the job at hand, while I think about what's going to happen in 6 months when this needs to be changed.
Everything we do has to be peer-reviewed, so the way I deal with it is to simply not approve anything that doesn't meet my standards, and help the person to understand why. Usually, if the person in question has half a brain, they'll catch on eventually.
For many of us, doing things right in the first place is actually faster.
Look at Adobe. Their Flash code base 'got the job done'.
and people used it for years. We can complain, but they beat competitors by getting there first (rather than pretty under the hood).
I had an intern try to optimize and clean up my code on his own initiative. It was pretty irritating. (...) OTOH, if I had tasked him to clean up my code and optimize, I might have been happy with his work.
You have an intern that can actually clean and optimize your code and you're complaining? Clearly he feels undervalued and wanted to show his skills or is just eager to learn and want to sharpen his skills, in either case just give him a proper assignment and be grateful.
Live today, because you never know what tomorrow brings