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?"
Passive-aggressive complaints in a public forum looks like a good choice.
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.
find some of the more fun things from his code, and submit submit submit....
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
>> 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.
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.
Might you be complaining about this gentleman? http://ask.slashdot.org/story/13/01/03/2255204/ask-slashdot-how-to-react-to-coworker-who-says-my-code-is-bad
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
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.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
With cruel sarcastic insults.
Science is all about firing a drunk pig out of a cannon just to see what happens.
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.
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.
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.
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.
My God can beat up your God. Just kidding...don't take offense. I know there's no God.
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.
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.
"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.
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"
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
This. If it's your job to go and fix his mess, do it without complaining. And document all the effort you put into it, to avoid being labeled as someone that just rewrites code without adding anything.
If you are not responsible for cleaning after the senior, then don't do it, let it all rot until somebody (your boss, or even your colleague) makes the decision it's time to clean the mess.
There is a senior developer submitting a Ask Slashdot article about what to do with a know-it-all junior developer wasting time "refactoring" all of his code.
How on earth did that happen?
Build your own energy sources from scratch. http://otherpower.com/
Is it possible the OP is already the junior developer hired for this purpose? :)
While the first poster's comment might have been intended as snide or humorous, there's a grain of truth in it. Not about whining, necessarily, but about his behavior at work.
The thing is, there is probably no future in doing what he is doing: somebody else's work, without credit.
I can appreciate that he wants to make sure things are done right, but he's doing work that should have been done by somebody else, and not making sure that it's being noticed. That's a great formula for failure. I know because I have been there.
If it's just charts and diagrams, then I'd mark each change with a colored * (asterisk), then at the bottom put:
* change by [blah] on [today's date here]
And if it's code, I'd make sure to comment any such changes I made.
Then, at least, he's taking credit for getting it done, and subtly calling attention to the fact that somebody else did NOT get it done right.
If doing it right and taking credit for the changes will get him in trouble, then he's in a toxic workplace and should start looking for another right away.
it's often better to do your own tasks and focus on your own productivity than cleaning up code that already works.
Unless a project is completely waterfall model, with the smallest changes billed at the same rate as creating a new system from the ground up, increasing the ability of the company to respond to requirement changes for an existing product increases the productivity of all the company's employees. Is it the fact that a particular person's contribution to such an increase is hard to measure?
Are you kidding? This is how dice is selling marketing on /. nowadays .. put up a phony "ask slashdot" question, and put the shill at the top of the queue.
---jstlook ---For that is the way of Elves, for they say both yes AND no, and mean every word of it. --- J.R.R.T.
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).
Is it possible - maybe not likely, just possible - that the submitter is in the right? The following is completely fictional and I'm making it up entirely for illustrative purposes. None of it ever really happened. Honest. Ahem.
I transferred from one department in a previous company to another, and was assigned to help a Principal Software Engineer polish up some code for release. When I first looked at the code, I thought maybe I was in over my head. I felt stupid. I couldn't understand a thing. I brought this up to my manager, who chided me for nitpicking about coding styles.
So I slaved away to understand how the project worked and how all the pieces fit together. I'd ask questions like "why are we monkey patching standard library classes to alter their behavior" and be told "it's easier this way". I'd ask why we had 9 levels of inheritance and be told it was to keep the abstractions clean (although I couldn't understand why 7 of those 9 layers only had one child class that derived from them). Why are chunks of server code in the client? Because that's how the design diagram works. Why did we invent our own unit test framework? Because the others weren't good enough for us.
The whole mess came crashing down when our boss asked me to add a data validation check on a certain input. It was a stupidly simple check like "if value < 0: raise ValueError('value must be >= 0')" - that kind of thing. It turned out to be impossible. There was a hell's brew of code that handled errors by returning None, code that returned a string with the error message, and code that used exception handling. There was not one single clean codepath between the API layer and the database model.
My boss had been more concerned with my questions over the weeks, but it wasn't until I showed him the code that he really "got it". He flipped. Meetings were called. VPs were summoned. Design and code reviews were scheduled. The original coder became so frustrated with what he saw as "micromanagement" - things like "unit tests must actually pass before deployment" and "don't monkeypatch everything" - that he quit and I was given ownership of the ball of mess. Since then, I've managed to make reliable, vastly simpler (seriously, I've probably reduced line count by 2/3 and call stack depth by 3/4), and understandable. It no longer uses ML for a templating language. You can read a method's code to see how it works instead of running "git grep methodname" to see if another module patches it at runtime. I'm no longer ashamed to be associated with it.
Sorry, submitter, but I don't have any advice for you. I do have advice for the rest of the readers, though: consider the possibility that the submitter was telling the truth. There are silly code style differences that shouldn't get in the way of getting your work done. You like studly capped method names and your coworker likes_under_scores? The sun will still rise tomorrow. But just because someone is senior doesn't mean that their code isn't a fetid ball of fail.
Dewey, what part of this looks like authorities should be involved?
People would probably still be using if it were fast, efficient, and secure. Those three things are tend to be a lot easier to achieve with a highly maintainable code base.
I've seen this happen more often in small companies than in large. When that's the case, I don't think there's a thing you can do about it. If they helped save the company's skin once, ten years ago, then they've been Teflon coated. Nothing you can say or do will stick to them. Regardless of whether their code is poor, or they never bathe, or they demand their own way...they're beyond reproach at that point. Big companies, otoh, have a large enough talent pool on which to draw that they can say "adios muchacho" and replace the annoying staffer with one who's more of a team player.