|
OK, so you've got "enemies" -- but they're not really enemies, they're just people doing their jobs who don't want headaches, like the rest of us, so make an effort not to hate them.
What you have to do (or maybe you think they have to do it, but at least someone has to do it, so why not you?) is take away the "enemy" thing. They're your colleagues, after all, and want the best for the company as much as you do (one would hope).
Try talking to them honestly, in private -- not the "Hey, your work is cr@p!" honestly, but the "OK, I've been a bit brusque, but we're all under pressure and maybe I went too far, so I'm sorry" honestly, and work outward from there.
Someone has to light the peace pipe, and you might be pleasantly surprised at the results -- co-operation works a Hell of a lot better than combat, so make an effort to be on the same side as the people you're (stuck) working with.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Well, the good news is, I'm about to switch projects, so the person in particular I've been working with in the past months will no longer be a concern (I hope) in about a week. That being said, you are right about someone being the bigger person, but I don't think that means apologizing since I've never once told them directly their code was crap. But he (the main person responsible) has insulted me to my face more than once.
That being said, your points are great. I'll keep them in mind for the next project for sure.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: I'm about to switch projects That is good news, because things sounded pretty bad (been there, done hated that).
It's easier (and a lot less work!) to start fresh than to dig your way out of a hole, so all the best and good luck!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Thanks man, and thanks again for the advice.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: But he (the main person responsible) has insulted me to my face more than once. Sounds to me like your manager has told him that you were complaining about his code and this is his way of saying "Fork you".
It's not enough to complain that something is wrong. You have to be prepared to show them why something is wrong - but, before you do that, why not take them to one side and say something like:
"Hey, I'm just looking at this piece of code here and I was wondering why you implemented it this way. I know I must be missing something because I'm sure you will have considered doing x first, and I don't want to change something elsewhere that's going to break this, so I was hoping you could walk me through this and any touch-points that could impact it."
This space for rent
|
|
|
|
|
Pete O'Hanlon wrote: Sounds to me like your manager has told him that you were complaining about his code and this is his way of saying "Fork you". That may be the case, but I do know that this guy in particular doesn't really get along with any dev. So, I think I was just the next in line to deal with him. Yay!
Jeremy Falcon
|
|
|
|
|
Yes. All that worked well for me. Better to jump overboard and watch them going full speed into the iceberg. Be diplomatic or fight it out, it does not matter. The only difference will be what's left of you when you finally get out.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Hating seems easy and right when you're doing it, but it makes your life so much harder, and you're usually in the wrong to do so.
We all work with people who are less talented than ourselves (and, if we're lucky, we also realise it when we work with people who are more talented).
Do you give the receptionist sh1t? Or the cleaning lady?
If you don't, then that implies that you value them more highly than a developer who is marginally less talented than you.
That's a pretty sucky attitude, no? But it makes you willing to make receptionists/cleaning ladies feel happy in their work, but your actual peers (even if only slightly less talented/knowledgeable than you) have to suffer your vengeful ire.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Simply because those poor dears do exactly what you accuse me of doing. They pat themselves on the back for der ingenious ideas that nobody else came up with without ever asking themselves why that could be. The fall flat on their noses each and every time and can be grateful that some customers don't stand in front of their door with torches and pitchforks. One of them is a real star among the car manufacturers and I will never buy one of their cars if it has been produced with that particular software I had the geat fun to work on. Pushing the blame for the current desaster onto the guy who says 'I told you so' is convenient and eases their pain. Being blamed for their clever ideas then banned from all 'important' activities actually makes me feel less ashamed to have worked there.
The cleaning lady at least never claimed it's somehow my fault that there still was dirt lying around and the receptonist was occasionally moved to tears by the way she was treated.
There is more and others have had less patience and left for the same reasons. If you ask me, they have a very weak grip on reality by now. You want to know their latest grand plan? Now that the n*ggers on the field have deserted them, it can't be that the guys left over are responsible for any of the still abundant errors or downright embarrasments. It's the fault of the testers who did not find everything. And that's why I valued the receptionist, the cleaning lady, the testers and all who fled from this place more than those who crated the whole mess.
If anything at all, I was an idiot for putting up with this as long as I did. In other places I finished projects all by myself and had customers who praised the results. The poor dears you are protecting can't claim very much in that direction, but that does not keep them from anything.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
We've all had to work with @rseholes, there's no getting away from that, but most of them can be handled very easily if you just sit down and think of how to handle the situation (and them), rather than lose your temper and quietly simmer.
None of us here is stupid; we just have to use our major assets to find intelligent solutions to problems -- use your head to think, not for butting.
Think of whom you need to talk to, and what you need to say -- but remember my dear ol' granny's tenet: If you can't say something nice, don't say anything.
If you get angry and butt heads with @rseholes, you're as much a part of the problem as they are -- but you make it a problem that someone else will resolve, without consulting you.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
My father always told me (don't know whose quote is though):
Don't fight with an idiot. Discussions will drop you to his level and he will win due to more experience.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Much less the entire idiot world headquarters. There is absolutely nothing to be gained and there is no point riding against windmills with them.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Mark, I know you mean well and I mostly agree, but they were not the peaceful compromising types. I knew there was nothing to be gained by being stubborn. That's why, while I began to look for a way out of there, I had a little fun with them. I agreed to every crazy idea, did what they wanted me to and when the boomerang came back I left it to them to blame each other. Tuned out that they actually liked me more before. Still, in the long term I expect more from a job than keeping such idiots busy with each other.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
CDP1802 wrote: I agreed to every crazy idea, did what they wanted me to and when the boomerang came back I left it to them to blame each other.
I have made this one or two times as well. It is priceless when they come to you, swallowing their pride and asking for help / guidance for the needed changes.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
My former colleagues would have died before they did that. Their game was more like leadership by handwaving. There was as good as no documentation amd the 'task assignment' usually was a single, not always very informative sentence. They had been doing that this way for 20 years and the resulting 'application' had the architecture of an anthill. In the rare case that this somehow led to results, they were quick to claim the praise, but usually any code change led to massive side effects and then it was, of course, the developer's fault. So it was me who pestered them with questions and let them make the decisions how to proceed. When it came to blaming someone for the next cascade of side effects which had (mildly said) angered the customer, I just pointed at the guy who told me how to do it and then enjoy the show when they turned on each other. Being treatd like an idiot can be amusing, but only for a while.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
I know what you mean.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Feelings shmeelings!
|
|
|
|
|
Totally agree with this - you will need to get others on board if you want to solve this problem. That means winning them over to your side, rather than creating the impression that it is you vs them.
In addition to adopting a more encouraging tone, I would suggest that you tackle the issue not from the point of view of "what is wrong" but "how can we improve". Telling someone that the work they performed is crap will always feel personal, whether it is true or not. Creating the feeling that we are working together for a common good will be much more productive and also resolves the you vs them feeling: make it us vs the problems instead.
At the end of the day, the easiest way to sell things to organisations, is by selling the benefit. If someone has had a frustrating time fighting through poorly documented spaghetti code, they really shouldn't need much convincing that there has to be a better way. The same goes for management; they might not know what refactoring is or what the benefits are. They might think that spending time on code that already exists is a waste of resources. It is your task to open their eyes to the efficiency and cost savings that proper engineering brings with it. If you can convince people of the benefits of changing their work habits and make it in their own interest to do so, you will probably have much more success. After all, nobody likes doing work that is a PITA or unnecessary.
|
|
|
|
|
I agree with this 100%. I suppose being constructive is a skill set I've yet to master. Thanks for the post though.
Jeremy Falcon
|
|
|
|
|
Well written, Mr. Wallace!
Are you hiring?
|
|
|
|
|
Only if you'll accept ironing my shirts in your job description.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
In my (limited) experience you have to show rather than tell - make your code as excellent and readable as it can be and then, as people interact with it they will feel pulled toward making their code likewise. Also have an ethic of adding comments and fixing method names to aid readability whenever you address a defect.
|
|
|
|
|
I totally agree with that when it comes to marketing, and I do that with the comments-ish... I usually don't over comment but for these projects I may.
Jeremy Falcon
|
|
|
|
|
No. That will infuriate them. First he does not only call them idiots, now he proves it to them by holding something under their noses of which they don't even have an idea what the words he keeps ranting about mean.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Write better code is a must, and the easiest test for whether there's any appetite for improvement. if there is, their changes to your better code will be less bad than the changes to the other stuff. If they plough on and throw equally bad code all over your changes (or even refactor your stuff to their idea of 'good'), they probably won't ever agree with you.
Not so sure about comments - too easy to come across as a lecture, given the usual problems conveying tone in writing. If you've done something non-obvious, then sure, leave a brief note explaining the improvement.
But the main thing is to try to work out what's in it for the people you're trying to convince. How does it benefit them? Unless you're in a management position, you have to show them how it makes *their* job easier, overall.
And yeah, if they just don't get it, polish your CV.
|
|
|
|
|