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

Comments

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

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.

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

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