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.
you are obsessing, and yes internal quality counts a lot, cause if its sloppy internally, its sloppy externally as it sets the attitude
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....
Make your work compatible with his: be sloppy as well.
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
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.
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.
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.
>> 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.
Oh god, not this guy again!
might as well queue up this story again.
This is the third time this question comes up.
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!
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.
http://ask.slashdot.org/story/13/01/03/1859210/ask-slashdot-how-can-i-explain-to-a-coworker-that-he-writes-bad-code
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.
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.
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.
-- Senior Software Engineer, Attorney appearance services, locallawyerapp.com.
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....
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.
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.
It works and gets the job done
In order for my coworkers to make anything that works, the planets have to align
What do I know, I'm just an idiot, right?
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.
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.
excitingthingstodo.blogspot.com
Recommend him for promotion - to another team.
bickerdyke
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.
KInd of obvious isn't it?
Quit being a wus and address him about it or start circulating your resume and run away.
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.
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 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.
...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.
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.
Boycott stupidity.
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
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.
Someone mod this up to funny!
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.
If it ain't broke don't "fix" it. Documentation is ALWAYS out of date.
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.
However, if it's not buggy and you are refactoring because it's not "elegant" that's much harder to justify or document.
It's all in how you phrase the change log entry: "Improved understandability of the code to allow easier implementation of future changes to user requirements."
"It works and gets the job done"
Yay! Always a vitally important thing to all projects.
"but it's far from elegant"
Define elegant. Also, is elegant a project requirement, or asset, or is it just a personal affection?
"numerous little (some might say trivial) mistakes everywhere"
Those are a problem. Mistakes are always problems, but they do occur.
"Diagrams that should be spread over five or six pages are crammed onto one, naming is totally inconsistent, and so forth"
If it is within your power, have a documenting standards and policies instituted and enforced for everyone.
(I removed the "arrows point the wrong way but doesn't affect anything" because that's an error thing.)
"Much of this is because he is so busy and just wants to get everything out the door."
Out the door is what everyone wants, but if the issue is because he has too high of a workload, either redistribute the workload, get more help so you can redistribute, or obtain more time for the project. It's well known that too much work in too short of a time with insufficient resources results in errors and a net loss of productivity. You can have it cheap, good, or fast, but you can't have all three.
"What is the best way to handle this?"
Not enough information to properly answer this, but please see previous comments and questions.
"I spent a lot of time refactoring some of it"
Is that necessary, or is it your personal choice? If it's necessary, there is a problem. If it's your personal choice, find out why are feel you need to do that, and re-assess the decisions you've been making. I know, it sucks, but it may have to be done when.
"as soon as he makes any changes it needs doing again and I have my own work to be getting on with."
Ok, earlier you said you don't like how he does it, but it works as intended and required. So why are you redoing it again? Does it not work, is it below the required standards, what? You need to justify why you are wasting time doing someone elses work. Are you just covering for him, or is there another reason? You really have to try and think about this one.
"I submit bug reports and feature requests, but they are ignored."
I'm sorry, but welcome to the modern practices of "if it's good enough, get it out the door and we'll fix it later, if we have to" attitude that infests most companies.anymore. And don't worry about the fact that when the customer base freaks out over a serous bug that was found and ignored by the higher ups during development, they will undoubtedly lay the blame on you, despite all the documents to the contrary. (Find a way to legally keep a copy of the bug reports or submissions where you can access them if some kind of legal repercussions occur due to such circumstances.)
Always use the letters i,j,k, and l as loop counters! These were always automatically typed as ints by the Fortran compiler back in 1965. It's a tradition worth keeping.
Death to Hungarian notation! In fact, Death to any capital letters at all in variable names!
Just post your work and we'll clean it up for you
It is by the juice of the coffee bean that thoughts acquire speed, the teeth acquire stains. The stains become a warning
Simply report at your meetings with your manager that a lot of bugs are appearing, being assigned to him and being ignored.
There is nothing more annoying than someone that ignores bug reports or that doesn't fix problems he just introduced when they are pointed out.
How on earth did that happen?
Build your own energy sources from scratch. http://otherpower.com/
Next time you want to refactor or "fix" something he's produced, ask his opinion of your proposed change. It's possible you are doing him and your team a favor, and it's possible you are wasting your time on pointless re-work and acting like a know-it-all. Find out which.
[Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
Said with 10+ years in a supervisory position, with my own superiors to deal with too, I know it's a careful path you have to walk when documenting someone in a senior position screwing up. And it's got to be stuff that's actually going to affect the bottom line, like missed deadlines or quality control that loses customers. Otherwise, you'll have to just put up and shut up.
If those feature requests and bug reports are encouraged within your company, keep doing them with a degree of discresion (ie - skip the trivial stuff), and keep copies somewhere safe in a CYA file.
The last thing you want to do is cover for him without letting your boss know that's where a percentage of your time is going, otherwise you will appear to be slow/unproductive on your own work.
Let your boss know how much effort you are putting into catching his mistakes.
It might not be a bad idea to make sure they know by letting a few of the bigger ones slip through, preferably timed to coincide with the time you take vacation and they will notice, so they actually feel the pain of you not being there to filter his crap.
We don't know what sort of development you're doing or diagrams you're talking about.
If they're design diagrams, why are you printing them? Spreading a diagram across "pages" is painful when you're trying to read online and have essentially infinite zoom capabilities. If he wants to do single-page diagrams in four-point font, click that little "+" or drag the slider and zoom in on the part you want to see.
Unless his code doesn't work, or someone assigned you the task of cleaning his code up, I'm not sure why you're complaining. Guess what - real world code, especially internal code, sucks.
I work on a C/Unix code base that dates back to 1986 - a time of 80286 processors and Xenix. It's grotesque. There are globals everywhere to deal with lack of stack space, it's K&R, and each programmer had their own idea of "correct" tab stops, so the first thing you do is play with that until things look like they line up in the function you're working in. It might be different elsewhere in the file.
There's code that hasn't been executed (we hope) since the early 90's, but we leave it unmolested until we're actually changing that file for other reasons. Then, and only then, do we consider carefully excising it - because if you change it, QA has to test it before it's deployed to roughly 15,000 systems scattered around the globe with poor network connectivity back to the main office.
Maybe you're not cut out for maintenance programming and dealing with someone else's code base. Most people fresh from school aren't very good at it and want to "fix" everything. I suspect that's who you are.
The preferred solution is to not have a problem.
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.
What is the push-back from the 'customer' using this data?
If it is an end customer who can't understand the diagrams or a subcontractor that can't implement the design, then get them in the loop with a customer feed back survey.
Anonymize the authors of the various components and ask them (the customers) to provide feedback. If they think the work is crap, let them say so. If they can deal with it, then OP is being too picky. Yes, there is an issue of professionalism. Neat work leaves a better impression with the customer. But a well structured customer survey can capture this aspect as well. And management can decide whether it is worth their investing in resources to polish the product beyond the minimum required to just make it work.
Have gnu, will travel.
So "plugging in cables" requires a degree now?
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
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.
Great idea! That way, you can get on with the process of interviewing for your next job so much faster.
Because, you know, being a self-righteous irritant to senior staff in the most obnoxious way possible is always a great way to terminate your current employment. You won't have to bother keeping track of any references, either, since you won't want future employers to talk to anyone you've already annoyed. It's win-win!
I can relate, and you have my sympathies.
The awful truth is that there is likely nothing you can do about this. Just as in the rest of life, slobs will win out over those who value order, following standards, lawful behavior, etc. every time.
Your best hope is to get your own little pasture (which might be an open source project) of code that you "own" (meaning that you have the power to exclude crap) and learn to satisfy your desire for order there. In the professional world, first to the finish line always wins, no matter how much of a radioactive stinking turd it is.
It would help with code styling issues (note: styling is important but not MOST important). For people who downvoted the OP for being slashvertisement, here are a few FOSS alternatives for other platforms:
JSHint (aka Crockford Enforcement Enforcer)
JSLint (aka Crockford-lite)
PyLint (PEP8 compliance tool)
I am sure there are loads of others, but I work with js and python, so that is what I know.
You sound like a kid fresh out of college that just hit the real world. You don't want to come across as a whiny brat as you'll sink your own career. Instead of taking an attitude that he is doing it wrong, take the attitude of there is something to learn here. Ask him why he does certain things the way that he does, are there reasons he doesn't do things the way you learned?
It's okay to say you've got a mismatch, admit your own ignorance and ask why someone does or doesn't do something. You'll get a lot more respect than if you passively aggressively file bug reports and do things 'behind' his back. Once you ask you may discover that he has good reasons for doing some things, but gets sloppy on other things for reasons such as a perceived lack of time. Ask him how you can help or do better and remember that reality and school almost never match.
I say this as a guy who works at a very large University that has a background in the private sector. I'm surrounded by student workers / interns that think they know how something ought to be done. Listen and learn and you can keep a good head about things you might gain a mentor out of the deal. Of course he might be deadwood whose blackmailed management into his position, but chances are he earned his position by knowing to make things work - even if they aren't pretty.
Not a bad idea at all, but in my environment, the real take away from a demo is usually a concept, algorithm, approach, or user interaction paradigm.
If people like it, funding increases by 1 to 2 orders of magnitude (i.e. going from $100K to $10M) and a ground up reimplementation and expansion of the idea ensues.
My God can beat up your God. Just kidding...don't take offense. I know there's no God.
I'm a bit like that chaotic guy too. If my colleagues wouldn't pay attention, naming conventions would go over board, documentation is so so. What I pay attention to is to not make mistakes regarding memory allocation and concurrent programming. Also making sure that loops run beyond array boundaries is important. I also make attempts to think about what happens "else" even if I end up just writing a comment down.
The obvious annoying stuff I leave to my colleagues who are way more anal retentive. What I also noticed is that criticisms rarely probe the depths of complex code so that I'm ultimately the only guy who spends enough time with the code and who will be able to fix issues quickly enough should they arise.
I also noticed that eclipse has this most useful tool where you can go to a declaration of a function or show the call graph. This is really dangerous if your colleagues don't have it since you have much less of a pain when navigating code compared to them. Your code will end up with deeper and possibly more distributed (across files) hierarchies and annoy your colleagues horribly.
Je me souviens.
1) Publish the issue on Slashdot (you did it, congrats!)
2) Send him the link to the post.
Mission accomplished.
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?
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.
Here is my story... I work as a web developer at a SME somewhere in far east. So far I have worked in couple of small to large scale Agile projects. And yes, I had company of college interns, developers, senior developers, consultants and architects alike. To be brutally honest, I abhorred my senior's work with a passion. I always pondered how this kind of incompetent, useless people end up handling multi-million dollar worth mission-critical projects.
Based on my so far analysis, this is how I see it:
1. Most of these seniors have survived simply because of a historical reason you might not know.
In my case, most my seniors survived during the 2008-2009 retrench season. Some survived totally through political clout; some by sacrificing their salary and other benefits. So in management's point of view, these are really valuable employees, and they should retain them at every cost.
2. They were there at the right time.
Around the time they were promoted, may be there weren't anybody to around to challenge them. After all the good crop leaves a firm, there is a window for all the sloppy bafoons to inflate their ego, convince management and climb the promotion ladder without much external challenge.
3. They know how to find scapegoats efficiently and effectively pass the buck.
How do I know about this ? I was a victim ! My firm practiced this 'Russian roulette' style of assigning task, such that everyone ends up get to work in every module of a project; or, bugs get assigned to you, even though you never worked on that module before. Most often, these experienced developer's work break down spectacularly, and I am the one brought in to clear their mess; and when I fail to fix, I end up in prison-cell meeting rooms to receive the brunt of senior management. Over the time, these seniors painted this nice picture of me as a lazy, unreliable, incompetent developer. And the funny thing is, most of these code bases, I didn't write a single line of code and I have absolutely no idea what's going inside. And these code bases are poorly documented/commented, making troubleshooting is a mini-IT project it self (call it "reverse engineering feature XYZ")
Sadly for most of us in junior positions, it is an arduous task to challenge the existing establishment. But at least you can dampen or insulate your self from the shocks from these stupidos. Here's what I do:
1. Don't volunteer to amend their codes.
I made this mistake many times as mentioned. Find who originally developed it in your team. If he/she is there, get him/her to work on it. If he is in a different team, ask project manager to bring him/her back. And importantly, if you are taking up these kind of responsibility, have a written understanding with your project manager that "You are doing your best effort to fix the issue, and if it fails, it is not your fault, it is due to poor implementation of the original developer". Stand up for your self ! in corporate world, nobody is there to stand up for you after all.
Trust me on this, "it is good a senior doing a bad patch that temporarily fix the problem and eventually breaks in future, than you failing to do a perfect job in fixing it for posterity"
2. Give seniors a chance !
Don't bother helping them out of your kindness. Let them shoot their own foot. You entering the picture is the biggest disservice you can do to your self, by becoming the dummy they can shoot.
In my current team, I have a tech lead, who was doing an important module. I had plenty of time to help him, as I finished my module early. Instead, I sat down and watched him failing brilliantly and had a silent laugh. Maybe I could have helped him in many ways, but I digressed and let him eat his own dog food.
3. Promote yourself often
I am not very good in this either. But in this world, hardly people pay attention to other individuals. So if there is an opportunity to shine, or talk about your work... just do it! And if management is still deaf and doesn't acknowledge/appreciate your contributions, move to another firm !
Then he went through years of canceled projects, changed requirements, the constant churn of new frameworks, and so on. Now he writes the most minimal code that will get the job done, because he knows it will be trashed or mutated quickly.
Posting on slashdot likely means that you don't have an open line of communication with him where you can easily make personal appeals. Invite him to lunch, get to know him. Soft people skills are very useful. If he considered you a friend, there is a chance that he would show you a great deal of consideration.
-Joe
Yeah there is software out there that will enforce things like tabs, naming conventions, whitespace and even comments.
Visual Studio and Netbeans both have built in "Code Analysis" tools. I'd imagine other IDEs have them as well.
Unfortunately there are plenty of bad programmers who write code that works but is on the whole unsupportable by anyone but them,
and no amount of formatting software is going to stop someone from writing crappy code.
Just stay at a company long enough and eventually you'll be supporting everyone else's code anyways
as your peers quit and move on to bigger and brighter futures. (i.e. places with free coffee)
I think you have your Hint and Lint mixed up... JSHint is Crockford-lite, and JSLint is the unforgiving beast.
This guy sounds just like my boss (and company co-owner), with whom I have worked for 20-odd years and find we make a great team. He's a great engineer, but we're polar opposites in some ways. In those 20 years I have taken time to appreciate some of his qualities like carelessness in a "glass half-full" kind of way, and even find myself becoming more like him, especially in the pragmatic ways you describe.
My advice is stick to what you do best - some people are best in the details, others in the broad sweep. Take time to understand, be patient and even humble if company culture allows it.
Anne, Sam, I'm sorry. I'm trying really hard to get this stuff out the door on time. We'll address the Technical Debt after The Deadline and after we've burnt the PHBs at the stake.
Stick Men
I've been on both sides of the fence on this over the years. I've had people rewrite my code without asking, and other times I've rewritten somebody else's code.
First of all, it just annoys people. It's not fixing a problem (at least not long term). I rewrote some code and fixed, perhaps, 10 problems but accidentally introduced a new problem. I was beaten up ad-nauseum in front of management over introducing that one problem into somebody else's code.
OTOH, a sloppy programmer might get used to you fixing their work. That can turn into a dangerous long term situation if people think it is normal for you to double your workload by cleaning up other people's work as well as doing your own.
As far as the business is concerned, they aren't paying two people to solve the same problem twice.
Make sure everyone knows where their responsibilities lie. Let everyone make their own mistakes. If somebody is 'sloppy' but there aren't any repercussions, then perhaps 'sloppy' really is good enough and you are the one wasting too much time and energy being nit picky.
If a coworker's sloppiness is actually really impacting your productivity, bring it up with the project manager in a pleasant way on specific issues. Keep the conversion focused on the work being done, not the individuals involved. Saying "Bob's work is sloppy" isn't going to help anybody. Say, "It would save me a lot of time if there were more consistent formatting and commenting in the code."
Don't criticize work that isn't intended for you. For example, those diagrams might only be intended for management, for example, and you might not know that there was a very good reason why they needed to be crammed all on one page (e.g. to be printed out large format to get hung up on a wall, say).
That said, it's good to have pride in your work and take the extra effort to polish it. Be the example. If nobody notices and appreciates your work, then perhaps you need to look for another job?
sounds like a passive aggressive Q from stackoverflows workplace discussion forum
There sure are a lot of people on this forum defending the "senior guy" and his poor work habits.
And you know for certain the senior guy actually has lazy habits, how, exactly? All we have is a post claiming this and nothing more.
January 2013 was last year? Are you posting from the future?
You make it sound like he's doing dangerously bad designs and implementations, but I suspect this is just a war over style. ... results speak volumes.
The way you describe your co-worker, it sounds like he is highly productive. Why are you against this?
Bottom line: does it work? I couldn't care less if it is ugly
Enforce it, if a .Net shop, with code analysis and StyleCop. StyleCop helps with code standards, which you should enforce. Nuff said, it's Friday, I want to be sedated after the kids go to bed...
BlameBillCosby.com
Did the company hire you to teach the senior guy or to learn from him?
When you send perfectionism up the ladder someone usually falls on you. Just hold the ladder.
Go to his manager, show him the pile o'crap and ask him to either light a motivational fire under the senior employee's sorry ass and demand better work or, if that's his best quality work, just fire his sorry ass, send him packing, and hire someone who knows how to code. Seniority does not equal quality.
I can certainly understand where the submitter is coming from, I like all the dots and crosses in place (oh, the luxury of lavishing time on dotting and crossing) but I also appreciate how this can slow things down, and trying to change people is just a world of pain. Talk to the guy; talk to the team; talk to your boss. Work out what the project's trying to achieve: a rock solid low-level bit of code, or a fast and dirty prototype, or something in between. Then try and find your place in amongst it where you can appreciate everyone's contribution ... or go work somewhere else.
I worked one place where the dotters and crossers got the OS code and the fast and dirty bunch got to write the apps, and we all rubbed along nicely.
Elegant? Sloppy? So you have a clue. It's not your fault, the Gods have given you the gift of pride. It's a hell of problem. Good luck.
[SOLVED] On your own dime, develope a solution demonstrating your point.
This complaint reminds me of the two sisters living in the same house. Both were in the same grade.
One sister was neat, her homework looked like a piece of art, but she never got marks into the 90's.
The second sister was sloppy, bedroom upside down, stuff under the bed and on the floor, and her work appeared very messy.
But the content was great, the marks based on content were rarely below 95%, and this sibling had time for tennis, and girls soccer.
So, one sister is the person who raised the question, the second victim is the guy that delivers. And does it within the 8 hours per day. And his stuff works.
Where can I find 5 of the second kind of developer. I am sure his mess is well organized, though the documentation may be missing a few dotted eyes and a few crossed tees .
Leslie Satenstein Montreal Quebec Canada
I would ask you: do you understand how the code works? Are you adding reasonable features, or fixing user-visible bugs? Are you restricting your changes to items that will achieve the project's goals, and meet the required deadlines?
If you are not doing these things, your changes are doomed to fail. If you are creating huge changesets that require additional review [time which could be spent making meaningful changes] but do not add (or fix) functionality, you are wasting the senior's time. Worse, if your changesets have bugs, you are actively hurting the development effort.
So what do you do? Add comments to help you find your way around; perhaps make suggestions as to how you think the code should go. Focus on how you can make a positive difference, and earn the senior's trust to rewrite the sections that bother you the most.
Change for the sake of change -- or to meet some irrelevant book's standards -- does not make production code work any better. And that's the usual goal. Be very aware of it.
Wait until they plug his mother into it.
Look for another job NOW, while you still are SANE.
ok you had me scrolling there