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 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 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.
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.
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
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.
Is it possible the OP is already the junior developer hired for this purpose? :)
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?