|
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.
|
|
|
|
|
Duncan Edwards Jones wrote: In my (limited) experience you have to show rather than tell
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: how everyone else here deals with poorly written code in pre-existing projects Ctrl+A - DEL
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
OI! Don't give CODZ in the Lounge!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Congratulation. They obviously gave you my job after I left a few months ago. Get out of there as fast as you can, they will not thank you, much less actually do something worth any time or money for the first time ever.
Look for a place where they actually want to have your skills and give you an opportunity to use 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.
|
|
|
|
|
It's not only you. I'm bbq-ed here with a bad code grill.
|
|
|
|
|
Good times!
Jeremy Falcon
|
|
|
|
|
Sanford and son.
|
|
|
|
|
Nice!
Jeremy Falcon
|
|
|
|
|
Gawd!
It's "Steptoe", OK? "Steptoe and Son".
Don't accept cheap Chinese American knock-offs, Harold.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Some sage advice in the responses, I'll have to keep them in mind as I often respond with "this is crap".
However my current problem is not that the code is lousy it is that the data source is Excel. Who in their right mind builds a mission critical database system based on a spreadhseet as a data source. The boss has got sick of me telling him that we are building a support nightmare.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
|
(If that is possible!)
[Edit]
I do not mean that, in one way, because this world is founded upon such ideas, and that has made money for organizations (people) like you work in. Hopefully, you can point them towards responses such as this, and they will see more clearly that the tools they are using are not appropriate for the job. Yes, they may be working, but, having worked with a $20 million a year company that also used spreadsheets, I can say for certain that they are FAR from optimal!!!!! Hopefully, more members can chime in, and give you more ammunition to work with.
modified 21-Jun-16 1:50am.
|
|
|
|
|
After 12 years contracting to the one bank, I will put up with it till the end of the year then I'm out of here. I can almost taste leaving and it is still 6 months away.
Never underestimate the power of human stupidity
RAH
|
|
|
|