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?"

Get over it.

[The_Wilschon]

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.

Re:WTF does elegant mean?

[i kan reed]

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.

Re:Get over it.

[Nerdfest]

There's getting the job done, and there's getting the job done in a way that can be maintained by someone else in the future. The only way you should let someone continue developing an unmaintainable mess is when there is absolutely no chance it will ever need to be fixed or added to. I have yet to see that happen.

Functional or "Style" Mistakes

[adisakp]

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".

take responsibility

[bauerbob]

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!

Re:yes

[digitrev]

To follow up on the other part of your question (what do I do), here are my suggestions.

• See if there are any documents that back you up on this, e.g. style documents, and so on. Use them to your advantage.
• Find people he's worked with before and see if this is a chronic issue, or if they've ever made headway on getting him to clean things up.
• Get a feel of the culture there. If there's a culture of "get 'er done", you might be out of luck.
• Talk to him. Let him know that you're having a hard time following his work in the format he typically hands to you, and that you end up spending a great deal of time refactoring things so that you can properly implement it. Emphasize that the whole project will go much smoother and faster if he's willing to spend some of his time cleaning things up. If you're lucky, he cleans things up. If you're less lucky, maybe he'll at least acknowledge the extra overhead, and manage his expectations of you accordingly.
• Give up. If the guy is senior enough, or he's got an "in" with upper management, or he's just an asshole, then it might be better for you to just slog along and wait until the product launches.

Re:WTF does elegant mean?

[icebike]

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.

Re:Whining.

[cayenne8]

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".

That's "Agile"

[Animats]

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.

Learn from him

[Fnkmaster]

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.

Re:Get over it.

[Anonymous Coward]

Who said it's solely "hierarchical" seniority? This entire question smacks of a fresh-out-of-college kid (it is May 3... when's graduation?) being absolutely stunned to learn that the real world of software engineering isn't as pretty and glossy and anal-retentively-dotted-i's-and-crossed-t's as he was led to believe it would be in his college classes.

My guess is that the "senior guy" in question is a "senior guy" by virtue of the fact that he's been doing the work for years, and knows how to ship code.

When you're the new guy, it's always better to understand "why" somebody experienced is doing something a particular way before you obsess over changing it. Sounds like the submitter has walked in, doesn't like somebody else's code style, and is now freaking out about it without making any attempt to understand why the senior guy has chosen to work this way.

If it turns out the answer is "the senior guy is a shitty developer and actively harming the company," then you consider how to deal with that. But I'd be far more inclined to believe the answer is "the new guy is a whiny little bitch."

Re:Functional or "Style" Mistakes

[fermion]

I agree. First, let me be blunt and say it is not your job to make other people work the way you did or the way you learned in college. There are many different ways to get a job done, and often we benefit by adjusting and learning different ways of doing things.

Second, if you are refactoring simply to make it look like you want it, and those documents are not being put into general use("I spent a lot of time refactoring some of it, but as soon as he makes any changes it needs doing again") then you may be wasting firm resources. If you can't get the work done without reworking everything, there are really only two options available. Realize that you are doing to have to some of this on your own time, or learn to read what is clearly company standard documents. These are after all what you have been given.

Third, identify if there are actually any real issues with the current system. Base change on improvement that will result in significant efficiency, not just 'the way it should be done'. There has been many occasions where I have come in as the junior person and was allowed to make changes because those changes would result in real savings. There were other times where I was just trying to be clever or controlling. Know the difference.

Re:had an intern try to clean up my code...

[Nerdfest]

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.

Re:Get over it.

[Beardo the Bearded]

I'm not a drafter. I'm an electrical engineer. I can make drawings, I can follow the guidelines, but I'm not as good at drafting as our drafters are.

The drafters can understand what I'm trying to say and then make it pretty.

Let people be good at what they do and support them with staff that can hold up the spots where they don't shine quite so bright.

Re:Whining.

[Nethead]

Exactly. If you want to be that anal about the product you should look for a job in aerospace. You'll fit right in.

Re:Get over it.

[jythie]

Which, without details and context, we do not know which this is. I have met plenty of developers who fail to think about maintainability and plenty who prioritize idealogical artifacts over purpose. I have also known plenty of developers who consider anything they can not scan easily (meaning, the exact style they learned) to be 'sloppy', so from this limited context we do not even know how much is actual (reasonable or not) sloppyness vs aesthetic differences.

Re:yes

[Diss Champ]

Is it possible the OP is already the junior developer hired for this purpose? :)

Re:Whining.

[eth1]

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.

Re:Whining.

[tutufan]

For many of us, doing things right in the first place is actually faster.

Re:Subsequent changes in user requirements

[coyote_oww]

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).

Re:had an intern try to clean up my code...

[Kjella]

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.