×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: How To Handle a Colleague's Sloppy Work?

Soulskill posted about a year ago | from the eat-his-lunch dept.

Programming 332

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

332 comments

Visual Studio with ReSharper (-1, Offtopic)

Anonymous Coward | about a year ago | (#43621137)

Visual Studio with a refactoring plugin (for example ReSharper [jetbrains.com]) can mitigate this problem a lot. You should get licenses to the both and I can guarantee that working with your colleague will be much easier from that point on.

Re:Visual Studio with ReSharper (0)

Anonymous Coward | about a year ago | (#43621255)

I'm sure that's fine if it would have something to do with source code. But I doubt a Visual Studio can fix problems with text documents or diagrams...
Nice marketing effort though.

Whining. (4, Funny)

Anonymous Coward | about a year ago | (#43621157)

Passive-aggressive complaints in a public forum looks like a good choice.

Re:Whining. (1)

icebike (68054) | about a year ago | (#43621319)

Passive-aggressive complaints in a public forum looks like a good choice.

That more likely to bring fresh ideas than reply using the phrase "Passive-aggressive".
Seriously, every time I hear that phrase I want to grab the speaker by the wattles and slap them till they spit.

(And yes, this post is self referential.)

Re:Whining. (0)

Anonymous Coward | about a year ago | (#43621571)

Enjoy the waffles?

Re:Whining. (-1)

Anonymous Coward | about a year ago | (#43621703)

You're only fooling yourself. You haven't seen your feet in years. The only thing you could slap is your fat sausage like fingers against the enormous rolls of fat that constitute your sad excuse of a body. You're a tubby, a fatty boomba-latty, a lardo and worst of all you're proud of it.

Go sit in the corner and reflect on this fatty.

Re:Whining. (5, Insightful)

cayenne8 (626475) | about a year ago | (#43621393)

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

Re:Whining. (1)

Anonymous Coward | about a year ago | (#43621627)

A better choice:
- move his desk outside to a nice, sunny spot near (but not underneath) a tree.
- point a camera at his new, desirable location.
- upload the coordinates to a shark, in space, equipped with a laser.
- wait until you hear all the birds scramble out of the tree at once.
- post the video on YouTube as a "21 Bird Salute" to a former colleague.

Ask Slashdot: Which direction do you wipe? (-1, Offtopic)

Anonymous Coward | about a year ago | (#43621669)

Is it okay to drink milk out of the carton?

Swallow or spit out? Which do you prefer?

Does your vag smell? How about your feet?

Is Paul really dead?

yes (1)

Osgeld (1900440) | about a year ago | (#43621165)

you are obsessing, and yes internal quality counts a lot, cause if its sloppy internally, its sloppy externally as it sets the attitude

Re:yes (5, Insightful)

digitrev (989335) | about a year ago | (#43621305)

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.

Get over it. (4, Insightful)

The_Wilschon (782534) | about a year ago | (#43621171)

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:Get over it. (5, Insightful)

Nerdfest (867930) | about a year ago | (#43621257)

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.

Re:Get over it. (1)

ttucker (2884057) | about a year ago | (#43621317)

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.

We only know that his coworker is whiiiining about his diagrams. Odds are the diagrams are in the trash by the time the code works, so not much to do with a maintainer anyways. The code could be perfectly maintainable.

Re:Get over it. (0, Troll)

Anonymous Coward | about a year ago | (#43621489)

If the diagrams are for communication, and you can easily spot mistakes and what they should be then the diagrams work and you should move on with your life.

Re:Get over it. (5, Funny)

jeffmeden (135043) | about a year ago | (#43621575)

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 by you.

FTFY

Re:Get over it. (1)

pigiron (104729) | about a year ago | (#43621649)

Anyone who relies on the absolute accuracy of obsolete diagrams for system maintenance is an idiot. Early on in my career I decided not to work on maintenance projects. I either talked management into total re-writes or just worked on brand new apps. I got rich doing it. Sweating/complaining about co-workers skills is a waste of time and can be detrimental to your career.

If you aren't good enough politically or technically to always work on new stuff maybe you should think about changing careers.

Re:Get over it. (1)

Anonymous Coward | about a year ago | (#43621321)

not necessarily true - hierarchical seniority does not equate with knowing more, or knowing better. not in the real world.

Re:Get over it. (5, Insightful)

Anonymous Coward | about a year ago | (#43621493)

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

had an intern try to clean up my code... (4, Informative)

schlachter (862210) | about a year ago | (#43621559)

I had an intern try to optimize and clean up my code on his own initiative. It was pretty irritating.

It was an internal demo and I had written the code quick and simple to get the job done. It didn't need to be clean or optimal. I wanted the intern to spend his time doing better things.

OTOH, if I had tasked him to clean up my code and optimize, I might have been happy with his work.

Re:Get over it. (1)

Anonymous Coward | about a year ago | (#43621583)

People who get the job done quickly get promoted. Doesn't seem to matter that your code is sloppy, barely working shit. At least in my experience.

Re:Get over it. (1)

Anonymous Coward | about a year ago | (#43621605)

News flash. You get paid by what works not how it looks under the hood. All management will hear is the stuff brings money in the door isn't pretty under the covers. Try and do as much as he does the "pretty" way and you can make it as pretty as you want. Until then understand your company is a business not a classroom on the "right" way to do it.

Subsequent changes in user requirements (1)

tepples (727027) | about a year ago | (#43621707)

You get paid by what works not how it looks under the hood.

What you say is true of a product that meets all present and future user requirements. But if a product looks good under the hood, it may prove easier to adapt to subsequent changes in user requirements.

use the thedailywtf to your advantage (3, Funny)

Mahldcat (1129757) | about a year ago | (#43621179)

find some of the more fun things from his code, and submit submit submit....

yes, submit to his supervisor (-1)

Anonymous Coward | about a year ago | (#43621311)

and get him fired. worthless seniors make up 50% of the middle tiers in large, sprawling companies.

Re:yes, submit to his supervisor (2)

Score Whore (32328) | about a year ago | (#43621651)

"worthless" seniors created the company and keep it in business and likely solve the vast majority of the issues that come up. might want to keep that in mind.

if you don't believe this take a look at open source projects. the ones with longevity (linux, xorg, mysql, mozilla) are run and carried by "worthless" seniors.

Easy (1)

Anonymous Coward | about a year ago | (#43621185)

Make your work compatible with his: be sloppy as well.

Fix them (0)

Anonymous Coward | about a year ago | (#43621201)

and then give them back pointing out what was wrong and where.

WTF does elegant mean? (3, Interesting)

alen (225700) | about a year ago | (#43621203)

i see a lot of "elegant" SQL code that i end up fixing to make it simpler so it runs faster

Microsoft releases new versions of SQL Server every few years to make code simpler to read. and yet people still insist on "elegant" code that's a pain in the A$$ to figure out why its running so slow

Re:WTF does elegant mean? (4, Insightful)

i kan reed (749298) | about a year ago | (#43621229)

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:WTF does elegant mean? (1)

alen (225700) | about a year ago | (#43621351)

over here it seems to be to write hugely complicated SQL code with lots of temp tables and then complain that it runs too slow

instead of writing some CTE's, views or anything else MS has come out with in the last 5 years to make code easier to read

or one time i had a view loving dev go view crazy. he had his team write dozens and dozens of views that called other views and mostly did simple things. kind of like C++, but in SQL. and then complained why the SQL job was running too slow. he had a few stored procedures call dozens of other procedures, that were made up of views calling other views, etc.

Re:WTF does elegant mean? (2)

pigiron (104729) | about a year ago | (#43621685)

Temp tables can also make queries run faster especially when confronted with a single three pages long SQL statement.

Re:WTF does elegant mean? (0)

Anonymous Coward | about a year ago | (#43621365)

Elegant is readable. But easily human readable doesn't always mean easily machine readable.

Re:WTF does elegant mean? (5, Insightful)

icebike (68054) | about a year ago | (#43621383)

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:WTF does elegant mean? (1)

ttucker (2884057) | about a year ago | (#43621417)

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.

I think the word alen was looking for was "clever" code. This is where someone works the code down in to 3 lines, or uses an obtuse feature of the language to do something because it just packs everything into an "elegant" little package. Sure, it looks really good when you write it. When you explain it to people they say, wow that makes a lot of sense. Still, three years down the road maybe even the programmer looks at it and has no clue.

Re:WTF does elegant mean? (0)

Anonymous Coward | about a year ago | (#43621585)

"elegant" when it comes to code is code that uses the least amount of resources. That is what it has ALWAYS meant, fast and lean code that is not always easy to read or understand but very easy for the machine to work with.

"pretty" is the word that is used for beautiful and easy to read code.

Re:WTF does elegant mean? (1)

Anonymous Coward | about a year ago | (#43621277)

"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." - Antoine de Saint-Exupéry

Re:WTF does elegant mean? (0)

Anonymous Coward | about a year ago | (#43621435)

Yes, readable and maintainable code tends to be slower than hacks.

Senior? (1)

Anonymous Coward | about a year ago | (#43621221)

Save your refactoring efforts... odds are you will be maintianing his mess in a few years anyway. If you rock the boat, you may just be thrown overboard depending on how the "Good ol' boy network" works in your office.

formalize reviews (1)

Anonymous Coward | about a year ago | (#43621223)

So IMHO the best way is to get him to agree that a review process is best for the product. YOU define and create the process and do all the legwork, then once the process is in place it is the _process that is enforcing quality....not you.

Re:formalize reviews (0)

Anonymous Coward | about a year ago | (#43621339)

So IMHO the best way is to get him to agree that a review process is best for the product. YOU define and create the process and do all the legwork, then once the process is in place it is the _process that is enforcing quality....not you.

+1
this is the actual answer

If he's senior then sorry, no... (1)

Anonymous Coward | about a year ago | (#43621225)

From bitter experience if he is senior to you then you have no chance of effecting change yourself.

If you both report to a common manager then you can try raising it, but I don't think you will have any success if they haven't done anything already as they are likely happy with their view of his work.

WWLTD? (0)

Anonymous Coward | about a year ago | (#43621227)

What would Linus Torvalds do?

Re:WWLTD? (0)

Anonymous Coward | about a year ago | (#43621369)

Rant and rave and be correct from his point of view.

Re:WWLTD? (1)

ttucker (2884057) | about a year ago | (#43621433)

What would Linus Torvalds do?

He would probably be the old guy that the OP is complaining about, and the OP might just figure out EWTF Linus Torvalds would do....

Just play along... (0)

Anonymous Coward | about a year ago | (#43621231)

And do your job the best you can.
Talking about quality code of seniors only can get you fired, or instead, more work.

Re:Just play along... (1)

ttucker (2884057) | about a year ago | (#43621443)

And do your job the best you can. Talking about quality code of seniors only can get you fired, or instead, more work.

At the very least you are wasting yourself a lot of time cleaning up someone's functional mess.

Like code doc more than code? (4, Informative)

xxxJonBoyxxx (565205) | about a year ago | (#43621261)

>> Diagrams that should be spread over five or six pages are crammed onto one

And you still figured out what to do? Sounds like he knows what he's going then.

Re:Like code doc more than code? (0)

Anonymous Coward | about a year ago | (#43621633)

It might actually be better to have it all in one page than spread over 6 pages.

If stuff starts getting too small to read or see easily then start spreading it elsewhere.

Otherwise why waste time changing pages when you can stick with one.

It works and gets the job done (0)

Anonymous Coward | about a year ago | (#43621263)

"It works and gets the job done"

Well and truly understand this, and your life working with others will be much better. Exactly how much time one should put in to code is relative to the type of customer, expected code shelf life, and usage patterns (API vs. internal library.) Not all code is worth perfect design - most code, in fact, is not worth this trouble.

Different people have different programming styles (3)

cheesybagel (670288) | about a year ago | (#43621267)

If his code works and his methodology produces consistent results then his methodology is sound. Perhaps you shouldn't be less concerned that other people have different ways of working than your own.

Re:Different people have different programming sty (0)

Anonymous Coward | about a year ago | (#43621621)

Perhaps you shouldn't be less concerned that other people have different ways of working than your own.

So he should be more concerned about the different ways.

Andy, this is your boss (1)

Anonymous Coward | about a year ago | (#43621273)

Oh god, not this guy [slashdot.org] again!

might as well queue up this story [slashdot.org] again.

Functional or "Style" Mistakes (5, Insightful)

adisakp (705706) | about a year ago | (#43621293)

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 (5, Insightful)

bauerbob (1049344) | about a year ago | (#43621295)

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!

Easy (1)

Anonymous Coward | about a year ago | (#43621323)

Are you being paid to do that work? Nope. It may not even be work that people think is valuable or even good to have done.

If you really want to be QA, sell your boss on the idea that you should spend your time there. Otherwise, learn to let it go and do the things you are being paid to do.

Bring up his incompetence loudly at lunch. (0)

Anonymous Coward | about a year ago | (#43621345)

You will likely get promoted and earn the respect and admiration of your colleagues.

Deal with reality. (2)

Karmashock (2415832) | about a year ago | (#43621359)

I work with dozens of small companies many of whom have their own proprietary software and development. Consistency across these companies is nonexistent and consistency WITHIN the code any of the software packages is at best unpredictable.

I deal with this by writing comments into all their code for my own information. If and when there is an issue, I can typically find the problem area very quickly and correct it.

I make no effort to clean their code up if its operating acceptably. I get it so it works and don't waste anyone's time if it is already working.

It's absolutely NOT trivial (0)

slasher999 (513533) | about a year ago | (#43621375)

Your attention to detail is admirable and something I wish more people were interested in or even competent at. Unfortunately that is not the case. You could offer to take on some of that additional workload, but that means more work for you. I'd discuss it with your manager in your 1-on-1 meetings. Your manager DOES do 1-on-1 meetings with each of his or her team on a weekly basis, right? If not, maybe it's time to move on to somewhere your efforts will be better appreciated and rewarded. You can only fight the tide and try to effect change for so long. If it's not working, let it be someone else's problem.

Re:It's absolutely NOT trivial (0)

Anonymous Coward | about a year ago | (#43621525)

We don't even know that his criticisms are even valid. You only have his word that things are "sloppy". He sounds like some amateur who never ships anything because he keeps tweaking useless shit.

"quality" is hard to judge (2)

bbulkow (954499) | about a year ago | (#43621395)

I see several different kinds of quality in my co-workers' code.

I see problems that are called sloppiness, like bad variable names, and "ugly" looking loops. These are not worth worrying about. I find that many new programmers - programmers raised looking at open source code that is coded without comments with the fewest possible lines - find "ugly". Even the use of Gotos and similar, use of variables without accessor functions. The refactoring is to make functions shorter, to remove comments (since now the code is self-documenting). This kind of quality problem you should overlook, because it's more stylistic than you think.

From your description, I think you're horrified by this lack of "neatness", and if so, you should get over that. (You talk about needing to "clean up" constantly - making me think this is simply moving lines around).

There's another quality problem, which is incorrect modularization and abstraction. When I see code that is going around external provided APIs, not creating APIs but simply objects called "Object" and similar. PUtting functionality into a higher level module when a lower level module should be expanded so other people can use the same functionality - but it's "a pain" because you have to write test code and update documentation. Code that is incorrectly modularized is technical debit that will always be hard to remove.

This kind of quality problem needs to be discussed. In your situation, the answer is always to ask questions. If your partner is always busy or blows you off, you go to another senior person and say "Joe doesn't have time for me, and I don't understand X way he factored the code, can you give me 5 minutes to explain this style?" If it really is as bad as you say, another senior person will grimace in horror, and tell you he'll go deal with it. You should expect to get reassigned to a better project in a few weeks.

That's "Agile" (1, Insightful)

Animats (122034) | about a year ago | (#43621409)

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.

Hire somebody to help (1)

greywire (78262) | about a year ago | (#43621425)

You say he may be doing this because he's just too busy... Maybe these things are not things he should be doing in his job, maybe he's better suited to something else? Maybe you need to hire somebody to do these things so he can concentrate on the other things he might actually be good at, and would then have sufficient time to do a good job. I've seen this happen where people get pushed into doing too much, and doing things they aren't good at, and then they start looking like poor workers.. well what do you expect? I realize you are probably not his boss so I don't know how you'd approach this. But there could be a very positive way of handling this. Or, maybe he's just lazy and doesn't care. Talk to him with a positive approach.

Learn from him (5, Insightful)

Fnkmaster (89084) | about a year ago | (#43621441)

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.

Too busy? Offer help. (0)

Anonymous Coward | about a year ago | (#43621445)

"Much of this is because he is so busy and just wants to get everything out the door."

If he's busy and if that's the main cause of him being sloppy, you should be asking yourself as a team how to improve things.

What are you even using? (0)

Anonymous Coward | about a year ago | (#43621517)

1) Diagrams that should be spread over five or six pages are crammed onto one ->
First off, you have programming diagrams on pages. Why not use a text based language like actual programmers?

2) naming is totally inconsistent ->
right click, refactor, enter better name

3) arrows point the wrong way ->
Again with the visual programming language, why?

UML - designer not programmer (1)

ZombieBraintrust (1685608) | about a year ago | (#43621699)

Could be a system that generates code based on UML diagrams. Such as IBM Rational Software Architect. Basic idea is to flowchart important stuff. Get it approved by buisness. Then pass the generated code onto junior developers. Designed more for waterfall projects than agile projects.

Learn (2)

nazsco (695026) | about a year ago | (#43621533)

Lear all you can. how can he do less work and not create bugs? (if he creates bugs, stop fixing his work and let the problem fix itself)

All in all, he is you tomorrow. You will get like him. Maybe there's a reason for that. maybe it's just indifference that comes with age. either way, i'd recomend you to learn his ways and start sooner, for as soon as you start that, you will get better pay, more respect, and a youger idiot to clean up after you.

Lemmeguess.... (0)

Anonymous Coward | about a year ago | (#43621545)

He's a senior system admin with years to decades over you, you're an entrylevel CS-Bachelor and/or MBA, so you do rightfully ask for your place in the universe and tell everyone that they are doing their job the wrong way...?

If he has seniority, you can eighter stuff it, or complain to your/his boss. Best case scenario, you're getting fired. Worst case, he's getting fired (and you're gonna wish it would have been you)...

work with him (0)

Anonymous Coward | about a year ago | (#43621547)

Ask him if he minds that you tidy things up after him... Let him know why comments, variable names, and functions should be organized the way you see..
Get him on board with your style and maybe he'll adopt it. Use the critique sandwich-- praise that it was written quickly and under deadline, then suggest some changes, then praise that it worked well to begin with. Maybe he will get the point of the style changes when.. Good programmers can adapt to new styles that make sense. Of course, if you are nitpicking (you like "index" and he likes "x") then you should back off until you find a compromise.

- Brad

Stand Your Ground (0)

Anonymous Coward | about a year ago | (#43621549)

Be blunt with him without being confrontational. Don't back down. You'll earn his respect, and probably the respect of others. Conversely, you may get ostracized and/or fired. Either way, you'll come out ahead.

This is a clash of styles. (2)

doubledown00 (2767069) | about a year ago | (#43621561)

Nowhere in the parent post do I read that there are problems with his code not working. In fact the phrase "far from elegant" really does tell the tale. The true "problem" here is obvious: The product isn't being done the way *you* think it should. It is admirable that you have these standards, but in the "real world" one has to work on a continum between time and budget.

Also, the author complains that 1) the code is not up to his stanadards, yet 2) he doesn't feel he should have to make it so. If you wish for the coding to be done your way, then you will need to invest the extra time to do it. Otherwise accept that "functional = good enough" and drive on.

Leave him alone. (1)

gurps_npc (621217) | about a year ago | (#43621573)

The work gets done, and is good enough.

Anything else is your bosses concern, not yours.

Worse, any time you use trying to fix him directly and negatively affects his morale.

Sometimes it's better not to know what goes into the sausage.

What does it affect? (0)

Anonymous Coward | about a year ago | (#43621579)

The question it all boils down to is: What does it affect? If it negatively impacts the product or presents a significant risk, then it is worth addressing. If it's just not lining up with your coding style, then it's something that should be left alone. I have a few co-workers whose database queries look horribly sloppy to me, but they work without issue or slowness so it's not a problem. I could spend my time actually taking care of my own workload, or I could spend my time on making my co-workers' work look like mine. Sometimes it's better just to let someone be a bit sloppy. Conversely, sometimes it isn't. The trick is to find the line between the two. Also, sometimes people need to learn from their own mistakes, as they are too stubborn to listen to experienced advice. Perhaps letting him fail is what is needed.

You're doing the right thing (1)

ErichTheRed (39327) | about a year ago | (#43621597)

I'm a systems integration person, so I have actual real-world experience getting one steaming turd of enterprise software to coexist with another one. Even if it's just coding style, and nothing your team does shows up in the final product released to customers, sloppy work means that your customers are going to have longer waits for bug fixes in the future. They're also going to be cursing your company because your products are a pain in the butt to install, require 100% of a high-end server's resources for a simple client/server application, and other reasons. When was the last time you looked at an Oracle or CA or SAP product and said, "Wow, that product is amazing! Clear documentation, easy installation and plays nice with other things on the same system!" Yeah, I thought I knew the answer. :-)

One of the things that really gets me is over-reliance on the infinite hardware resource fairy to get an application to work. I've worked with tons of very expensive software that utilizes some of the worst, most inefficient SQL queries and procedures I've seen. The solution is always "add memory" or "buy a dedicated server." Admittedly, we're far from the days of hand-optimized assembler in most systems, but just reasonable hardware utilization still seems to be too much to ask.

So from a customer perspective, yes, you're doing the right thing by recognizing the problem. How to fix it is a very hard problem and depends on a lot of things. From your question it sounds like poor project management and resource allocation is a big part of this. Well, welcome to my world. :-) Project managers are an interesting lot. The best ones actually did the work previously and know how hard it is to estimate a software project. The worst take the PMP course and assume you're working on a construction project. I wish IT projects were like construction projects -- there's zero uncertainty in most of those. It takes X workers Y hours to drywall Z m^2 of studs. It takes X workers Y hours to rough in plumbing. Etc. Software is a whole different bag -- most construction projects don't get halfway down the track and require that you rip the whole thing down and start over, or even that you rip the last 3 floors out.

I guess I would try to see if the PMs on your project are the type that can be reasoned with and have a clue about what you're doing. That's going to be the way to solve the problem -- getting the pressure off the other guy so he can deliver decent stuff. I've rolled out stuff I hate to make artificial deadlines as well -- it's unprofessional and I hate doing it.

The Therapist's Couch (0)

Anonymous Coward | about a year ago | (#43621601)

"Ask Slashdot" should really be called "The Therapist's Couch", because that's what it always looks like. It's always some hapless, meek person who just can't seem to manage their daily job or the social interactions there, or the immense stress from seeing that someone is doing things in a different way, etc.

Code Reviews? (0)

bidule (173941) | about a year ago | (#43621609)

You don't do code reviews?

Speak with him, ask him if it's okay to fix the little inconsequential things he left behind. Say it's to make things easier for you, so you understand what he did and can fix minor issues without bothering him. Make it so he's the one helping you.

Then come up with a code review, tell him you fixed that link that was backward and to confirm what you did wasn't wrong. Ask him why he didn't write this code that way, if there are any reason. Don't butt heads.

Never frame it as him evolving, but as him making an extra effort to simplify your life, if only by allowing you to adjust his work.

Man up (1)

lintmint (539531) | about a year ago | (#43621615)

KInd of obvious isn't it?
Quit being a wus and address him about it or start circulating your resume and run away.

Love your colleague. (5, Interesting)

galexand (151650) | about a year ago | (#43621625)

My boss is like that, he abuses cut-and-paste to the exclusion of proper factoring. The code is sometimes comical. He does it for the exact same reason, he wants to move on to testing/fixing/improving, rather than spending a lot of time dreaming-about-how-it-ought-to-be.

Sometimes, maybe 3 or 4 times in the decade that I've worked with him, I have needed to do a major re-factoring just to be able to shoe-horn in a new feature. He is glad I'm here to do that, because he doesn't enjoy re-factoring. I'm glad he's there to do his part, though, because a lot of times he can throw out a big *working* piece of garbage in just a few days, while I would still be arguing with myself about where to start.

The machine works. Therefore, I cannot point to any component that is broken. The machine works.

So I enjoy this, I look at all of the numerous insurmountable customer problems that we have dispatched over the years together, and it is beautiful to me. I love my boss.

That's my advice to you: learn to love this guy, to think of his foolish shortcuts and disorder as unique tools that a unique person uses to solve the problems in front of him. Consider it "local flavor." If you're being hauled up in front of management and they're blaming you for his bugs, that's one thing. But if the machine works, learn to love it. If you can't love it, quit programming and go into a less creative field.

Pair Programming (0)

Anonymous Coward | about a year ago | (#43621629)

Pair programming is the answer. Work collaboratively. That way you can clean up mistakes together before they get checked in.

Passive agressive troll (1)

gnupun (752725) | about a year ago | (#43621653)

OP is a troll or passive aggressive against his coworker. Most in-house software I've seen is sub-par but it gets the job done. You're only going to see elegant in code in popular commercial software (and even some of that is not quite elegant).

Elegance has long term benefits but high upfront costs in quality of programmer, time and effort... things most managers don't seem to value beyond a certain threshold.

Insist delegate coding changes to you (1)

kawabago (551139) | about a year ago | (#43621657)

Insist this senior doesn't have time to do the coding himself, let you handle all of it. Insist it will be more efficient if you code the changes, that should sway him.

Focus on the significant (1)

Arawak (98728) | about a year ago | (#43621663)

...and not the trivial.

Presumably you are developing something to make money. You need to learn where the balance between purity and practicality lies. In the real world there are always tradeoffs and experience helps you learn which which ones to make.

My guess is that your senior co-worker is probably closer to the correct balance than you are.

What is the customer paying for? (0)

Anonymous Coward | about a year ago | (#43621667)

There are projects that are "one-off", to scratch an itch if you will. The customer in that case is not paying for internal quality therefore a "good enough" strategy is optimal. If the customer is paying for a long-term project then your collegue is pushing the real cost further ahead (which in some cases can also be a good strategy - i.e. needing to score early victories).

I used to be a perfectionist to the point that I never considered a non-trivial piece of code "done" (the joke with my collegues then was that I wouldn't be satisfied till I had an object model of the universe down to the subatomic level and build every application up from there). Back then I was even dangerous for a project's success. Later in life I found I had to teach myself to value "good enough", performance and simplicity instead of overengineered object models with abstraction layers over abstraction layers in order to fit some pattern or whatnot. As always the truth is somewhere in between.

Tell him (1)

Murdoch5 (1563847) | about a year ago | (#43621677)

I would be honest, tell him his work sucks. I had a similar issue with a classmate last year, I couldn't use any of his code or hardware. Every time I hinted at his work being bad but in a nice way he laughed and disregarded it. Finally after my prof saw his work and asked me to explain it to him I couldn't, I called my co student aside before he left and was blunt. "Your work is worse then a child playing in a coloring book, clean it up or get off my project", he yelled at me and walked away, the next week when he handed his work to me it was 300% better and by the end of the term it was finally decent. I would just be honest.

Question Answered Itself, I think (0)

Anonymous Coward | about a year ago | (#43621681)

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

From your description and question, certainly sounds like (borderline) obsession. I personally don't have enough time to do all of MY work, let alone 'fix' someone else's. If I do, then it's not because I have a bunch of free-time (so it must be *really* important to me somehow). If it is because I have a bunch of free-time, I would see what I can do to offload something from the busy-old-guy-who-just-needs-to-get stuff-the-door. That, or I might want to be spiffing up my resume (with something other than obsessed over someone else's non-elegant [IMO] code).

There's a difference between 'concern' and 'worry'. If you're concerned, it's something you see that may be an issue (e.g. data loss, train wreck or security breach) ... BUT you *can* and are trying to affect the outcome. If it's not in your court or your direct responsibility (i.e. someone else's work), then you can 'worry' about it, but you have no real way to affect it.

I would err on the side of 'concern' (things that are your actual responsibility/that you can do something about) and keeping a good relationship with someone else at work. The quota for crappy relationships at workplaces has long since been filled.

FTFY: Rewritten the question correctly... (5, Funny)

maroberts (15852) | about a year ago | (#43621697)

I'm working on a new product with one of the more junior guys at our company. To be blunt: his work is sloppy. Because he obsesses over details, whilst his work is elegant and has few mistakes, he never completes any work. It never gets to the stage where It works and gets the job done, but there are numerous incomplete (some might say major) sections everywhere.

Diagrams that could fit in one page are spread over five or six pages, he's anal over naming convention and minor details like whether arrows point the right way (whether it affects functionality or not) and so forth. He spends lots of time refactoring code instead of making progress and never gets anything out of the door, costing us money. What is the best way to handle this? Whenever I make necessary improvements he goes over my changes with a fine toothcomb, instead of getting on with his own work he spent a lot of time refactoring some of mine. The annoying little tyke then submits bug reports and feature requests, but which my fellow senior peole read with condescending amusement. I don't want to create bad feelings, as I have to work with him. Is he obsessing over small stuff, and should he see the Bigger Picture"

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...