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.
and then give them back pointing out what was wrong and where.
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.
What would Linus Torvalds do?
And do your job the best you can.
Talking about quality code of seniors only can get you fired, or instead, more work.
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.
>> 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.
"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.
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
You will likely get promoted and earn the respect and admiration of your colleagues.
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.
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.
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.
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.
"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.
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?
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?
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.
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)...
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
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.
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
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.
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.
"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.
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.
ID: the nose did not occur naturally, how would we wear glasses otherwise? (apologies to Voltaire)
KInd of obvious isn't it?
Quit being a wus and address him about it or start circulating your resume and run away.
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.
Nice try, shill.
delete me
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 is the answer. Work collaboratively. That way you can clean up mistakes together before they get checked in.
"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.
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.
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.
>> 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.
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.
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.
with fire. Or just get over it.
delete me
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."
"Shipping is a feature", and IIRC he said it was the most important feature. Ordinarily I wouldn't agree that seniors are better; but in this case it's true. Your pretty diagrams and consistent naming convention will be ignored while customers use the actual product. If you want to write stuff that nobody reads, maybe you should be writing BBQ grill assembly instructions for guys or something...
Well, are you? Are you able to explain to yourself why this is a problem for the company? Does the code cause quality defects? Are the bits you commonly extend hard to extend?
If you can't answer these questions, you are either a prima donna or whining. From the reasons your post gives ("inelegant", "large diagram", and on the other hand "inconsistent", documentation errors) you look like you are mixing your makeup tips with your sound engineering. That might be one reason why you are not being listened to.
Whether it is or not learn to enjoy working working with people that have different development styles as you will, invariably, end up learning something from it and both be better developers in the long run. Beyond that talk about what bothers you and why, chances are he'll be open to constructive criticism and/or be able to tell you why he is doing thing a certain way.
"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.)
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/
If the code is working and being adequately maintained, there is no issue. Pull your head out of the ass of academia and get with the program son. Charlie don't surf
When these stories appear (and they're getting more frequent) we need to see examples of what is being done and an explanation of why it's so bad. I once had someone complain about the flowcharts I drew, because the arrow heads were in the middle of a line connecting two boxes rather than directly against the terminal box.
I think you aren't challenging him enough, he sounds like a real straight shooter with middle management written all over him.
Sounds like you are the new guy. Chances are that part of your job is to clean up his work. He is about getting it done, as it should be.
I do the same thing, I setup the backend servers, networking, design the system etc. But when it comes to plugging in the rest of the cables and making the network diagram pretty I have other engineers that take care of this.
Visual Studio with a refactoring plugin (for example ReSharper) 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.
We are ignoring a good point here though, a code re-format tool can mitigate the rage associated with many code format styles.
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.
If it's stupid but it works, then it isn't stupid.
Get over yourself, OP.
You sound like an irritating little shit more concerned with your interpretation of ivory tower BS than someone who actually gets work done, thus helping your employer. My solution would be to fire you.
Remember, hand writing is messy .. must be a DOCTOR's note.
looks like you are not an engineer or technical person.
pie charts, colors and ppt are reserved for VPs and Directors.
you complaining here, so you are not a VP or Director! are you a tech writer or what?
Most Technical ppl care for data and careless how is it presented. ( except few OCDs ).
1) move to the UK and work for some IT services company where they care about this stuff. Hope they dont go bankrupt (they all do!)
2) complain to his boss so you can get fired and stop worrying about it
3) drop the attitude and do some work
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.
Did you actually mean Visio?
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.
This doesn't sound like code but rather design documents. UML documents produced by a designer. Primary purpose is a communication between the customer and the development team. Secondary purpose is documentation for future development. Possible also used to generate some code. Designer A thinks Designer B charts are messy. Messy charts just slow development down a little and embarrass managers when they are shown to executives.
see a doctor and get some medication
1) Does it work? Yes
2) Is it done on time? Yes
3) Is it done on or under budget? Yes
The answer to all three is "Yes," so it's time for you to STFU and understand that practice is not theory, and that while in theory there is no difference between the two, in practice there is.
In the real world, solutions seldom resemble the ideal solutions you learned about in your elementary college textbooks. A junior engineer looks at those sloppy diagrams and doesn't understand what's going on. A senior engineer looks at those sloppy diagrams and knows EXACTLY what's going on, despite the occasional trivial error in the engineering equivalent of spelling and grammar.
That's why you are a junior and he is a senior.
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.
I was thinking OP should get help for his OCD. I'm not very OCD but have worked with a bunch. It goes like this.
Multiple returns from the body of a function that works.
Fred: Aiiiiggghhhh! Refactor refactor refactor, debug debug
Me: Ick okay goes and does something else productive.
Inconsistent tabs and spaces
Fred: Aiiiiggghhhh! Refactor refactor refactor, debug debug
Me: Ick okay goes and does something else productive.
Variables names that are misspelled, punctuation and spelling errors in comments
Fred: Aiiiiggghhhh! Refactor refactor refactor, debug debug
Me: doesn't notice, does something else productive.
Variables names that are misspelled, punctuation and spelling errors in comments
Fred: Aiiiiggghhhh! Refactor refactor refactor, debug debug
Me: doesn't notice, does something else productive.
Variables names that are misspelled, punctuation and spelling errors in comments
Fred: Aiiiiggghhhh! Refactor refactor refactor, debug debug
Me: doesn't notice, does something else productive.
Variables names that are misspelled, punctuation and spelling errors in comments
Fred: Aiiiiggghhhh! Refactor refactor refactor, debug debug
Me: doesn't notice, does something else productive.
Continue statement in a while loop
Fred: Aiiiiggghhhh! Refactor refactor refactor, debug debug
Me: doesn't notice, does something else productive.
Module is a nightmare but works
Fred: Aiiiiggghhhh! Refactor refactor refactor, debug debug
Me: Ick, does something else productive.
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?
If the software doesn't rise to this level: http://www.king5.com/news/investigators/series/Hanford-Dirty-Secrets-series-radiation-nuclear-waste-205308821.html
Then enjoy the ride and move on. Nobody ever got anywhere grumbling about sloppy work. You get somewhere by torpedoing the guy by company treachery, not by pointing out flaws in his work.
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.
Their web page has a cool effect where the top bar locks to follow you when you scroll down and at the same time the R# logo fades in to the left side of the bar. I'm scrolling up and down, up and down, weeee...
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.
Just stay an extra 8 hours after he leaves and redo all of his work to your standards. Sure you'll be working 16+ hours a day, but the code will be elegant and well documented. What else matters.
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.
Remember? handwriting is bad.. must be DOCTORs'!!
Engineers and technical people care more about data and not how it is presented.
Pie charts, color and ppt are for VPs and Directors.
you are here complaining, so you are not a VP or a Director!
are you a technical writer or what?
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
The number one goal is to ship functioning software. If it works the way he does it, you are only increasing expenses by making it pretty.
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)
"Help, save me from bad UML..." How whiny can you get??? I noticed you didn't complain about really bad stuff, like: did he start putting ad-hoc SQL inside HtmlHelper extensions, circumventing templates, views, controllers, service layer, repository and even ORM because he was stuck at "How does dependency injection work?" Did his ignorance of editor helpers cause him to implement editing functionality from organic scratch on top of the display functionality using javascript? Did his ignorance of form collections or json serialization cause him to resort to passing all AJAX parameters as "gz" (yes, that's right) delimited strings?
Be Grateful.
I had this issue at both of the programming jobs I held before leaving the industry. One was epically bad -- I could have written the OP in just the same words myself.
The problem is that this senior coder comes off as a hero and superman to the higher management. From where they sit, it looks like this guy just ships code and solves all their problems -- regardless of how much it holds the rest of the software staff back in the process (his bad code hygiene is effectively invisible to managers). Also, since he's been there longer he's likely also good buddies with managers on a personal basis. Also, he's just senior staff and so has that ahead of you as well.
There is no way you can change his slash-and-burn work process, and all the rest of the institution will be actively encouraging him for more of the same. You cannot win this one except by leaving some day. This could possibly be switching to a different project, or changing jobs to a different company. Get what you can out of this job and start look for a switch.
We know where leadership by an anti-intellectual "strongman" who scapegoats minorities and likes boisterous rallies goes
Analyze your own complaints: "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.
Diagrams are not code, they are documentation. I don't like having to flip pages when reading documentation. If it can fit on one page instead of five or six, that may be the better way. Unless you've got a specific example we can look at that would show otherwise, I'd say you're wasting your time on this one.
The names of structures, variables, and functions in a body of code can be chosen elegantly, poorly, or somewhere in between. It is almost always somewhere in between. By declaring the naming to be "totally inconsistent" without giving examples, you are saying that all of the names are poor. That is, quite honestly, a little hard to believe and I suspect you're exaggerating a bit because you're having a hard time just accepting some of the naming conventions that are good enough.
Arrows point the wrong way (without affecting functionality). What does that mean? Are you saying that you feel you must insist that all flowcharts only have arrows that point either down or to the right, even if that means expanding a flowchart from a single page to five or six?
I've been programming for 30 years and I've worked with a lot of people. When I was a young buck, I was lot more adamant and pedantic than today, and I would get incensed about trivial stuff. I didn't know shit. Over the years, I have made an effort to constantly challenge myself, to learn, to grow, to be a better programmer, to do the things that I always envisioned that someone who had dedicated their life to computer programming would do. I still don't know shit, but at least now I have a deeper understanding of what I don't know, and most importantly, a deeper sense of priority. My advice is to focus on data structures, algorithms, and producing working systems quickly with an acceptable level of quality. Force yourself to stop obsessing about things like what other coders pick for variable names or where they put whitespace (I'm assuming certain languages there of course) and don't even think about "refactoring" other's work until you understand all aspects of it forward and backward and could take on their responsibilities (and would) if they were to walk away from it. Good luck.
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.
Am I really the only one that remembers these two articles from last year?
http://ask.slashdot.org/story/13/01/03/1859210/ask-slashdot-how-can-i-explain-to-a-coworker-that-he-writes-bad-code The rebuttal http://ask.slashdot.org/story/13/01/03/2255204/ask-slashdot-how-to-react-to-coworker-who-says-my-code-is-bad
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
Rather than spending so much time obsessing about what to do, make corrections to the errors
There sure are a lot of people on this forum defending the "senior guy" and his poor work habits. Sure he knows how to get stuff to work and get it out the door, but he appears to have little regard for those who have to collaborate with him, or those who have to clean up the mess behind him in the maintenance phase. As a software engineer with 18 years in experience in companies large and small, with subject matter both technical and commercial, maybe my gripes against lazy "senior" co-workers will carry a little more weight. Here are my best suggestions, ones I think are far from anal:
1. Name identifiers meaningfully! You aren't just programming in some language defined by its keywords and syntax, you are BUILDING the language in which you will have to think about and discuss the software you are writing.
2. Go ahead and use long names. Short, obscure names don't save any keystrokes when you have auto-complete. Call a thing what it is. But if your names get too long, it probably means your code is exposing too much detail.
3. Use indentation and white space as they were meant to be used -- to provide a visual representation of the structure of your program logic.
4. Strive to write code that doesn't need comments. When comments are needed, explain clearly in complete sentences (or at least in phrases that will mean something to someone who is not you).
5. Don't make me scroll horizontally.
6. Don't make me have to hunt all over the place to find where some key action occurs.
7. Make your code do exactly what it says it does, with no side effects and no surprises.
8. Take a few minutes to research things rather than write dumb code. That's all it takes these days -- a few minutes.
I was going for a "Ten Commandments", but I think this is sufficient. If you do these 8 simple things, you will see that (a) they pay for themselves, and (b) your job just got easier.
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
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
Pissant.
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'm not in IT (offshore engineer) so I'm answering from my own perspective:
- Do the "little errors" put your company in a disadvantage should there be some form of dispute with your client?
- Do you have chargable hours to work on those "little errors"?
If the answer's no to both, then don't spend your chargable hours whining online. If the answer to the first qn is yes, then gently remind your colleague / QC guys about correcting them. If it's "yes" to both qns, then work on them and stop whining!
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
Good for them. They have to compete with any other solution suggested, and they're subject to moderation.
If they game the moderation, then fuck 'em. All bets are off. Until then, it's pretty brilliant, and hopefully it will keep the doors open here.
Essentially the way that it will be worthwhile to all concerned is if the product being advertised fills a need. What's going to be best is if they keep that need general, like this one, so it's not an obvious ad. This guy isn't necessarily asking for a product, even if there is one to solve his problem.
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