|
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
|
|
|
|
|
Mycroft Holmes wrote: Some sage advice in the responses, I'll have to keep them in mind as I often respond with "this is crap".
I'm glad I'm not alone here.
Jeremy Falcon
|
|
|
|
|
Often the biggest problem is being viewed as objective. I find myself often in a position of defending code from people who are upset that they couldn't join in, and pointing out bad code in projects (including my own) to get people to up their game.
The thing which I've found works best if to have tooling which can provide an objective view of the code. My two favourites being ReSharper and SonarQube, the first because it provides immediate feedback and helps fix a number of issues and the latter because it provides some great metrics that can be tracked (great if you can make it part of your build process).
Building these up to show the team and your manager gives you the ammunition to show that you know what you're talking about and helps the team measure themselves against an objective measure.
Of course there may be things like coding styles which people don't agree on (yourself included) but if everyone follows the same rules then things improve and it makes sure that everyone can read the code easily.
Once these are in place you can build up some internal guides on coding practice to help new starters and as refreshers for existing people.
It can be a long journey, but if you can present it as "it's not me complaining, look here's the proof" then it's an easier pill to swallow.
Eagles may soar, but weasels don't get sucked into jet engines
|
|
|
|
|
I used to be a real PIA about code quality and pissed of most of the department ... but as I was as hard on older, "less optimal" code written by myself and that I also listened to them and theirs complaint about my code, it worked out in the long run.
Nowadays I mostly preach "Code Complete" and lends my copy to anyone even remotely curious. As most programmers really wants to improve it usually ends with them keeping the copy -- "Ahh, I have a older copy at home, you just keep that one".
For "less optimal" code it's refactoring time wherever and whenever it's discovered 
|
|
|
|
|
Jeremy Falcon wrote: I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects.
Noooooo! Of course not! It's only you! You alone have been "blessed" with cow-orkers that write stupid code! 
Seriously, my suggestion would be as follows:
Everybody with half a mind would be able to understand that it is a huge advantage if code is written in the same way by all coders. There are several VS plugins that can enforce code standards available out there. Pick a standard and use it (all of you) - or tweak it to your common liking.
My personal recommendation is IDesign's Juwal Lowy's "C# Coding Standards", which can be downloaded freely from their web site[^]
As for existing code, it can be refactored and rewritten when it's practical and when time permits it...
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
I'd just like a chance to prove that money can't make me happy.
Me, all the time
|
|
|
|
|
Jeremy Falcon wrote: I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects
Like this[^]
|
|
|
|
|
I used to complain. I complained about bad working environments, because who wouldn't want to fix that?! Don't you want your devs to be ultra-productive? I'm still amazed people pay the dev salaries they pay, and then shove the devs into an open plan office next to Customer Support, give them old machines and small screens.
I used to complain that my co-workers, who I felt knew less than me in a particular area, weren't taking my very excellent advice. I complained about having to learn one platform when my skills lay elsewhere, and my skills going to waste. I complained about a lot of things. I meant well but I became toxic.
I had a great manager who sat me down and said: "You are not responsible for the ultimate success of the project. If your advice is not accepted, you can't force it. Just do your best." If they don't want to hear, stop complaining, because it comes across as negative, and causes negativity. Try to coach your advice in nice terms, but if it isn't accepted, then gracefully back off, and just do your best with your own code.
In a start-up environment, I learnt another great lesson - take ownership. So if it bothers you, and you can, take ownership and fix it. If you can't fix it, don't complain about it. Don't become a toxic co-worker who creates a negative work environment. We mean well, but that's not good enough. If you read enough work studies, you'll know that companies prefer an amiable, ambling, mediocre team over a super-productive but toxic genius any day.
The saying comes to mind: Be the change you want to see. So be positive, practical, and constructive, no complaining, no blame-storming. The headache goes away when you stop head-butting the wall 
All the best on your next project. Turn your reputation around
|
|
|
|
|
So true. Once you're labeled as a complainer, anything you say will be disregarded.
On the office politics end, one place I worked the IT department did chargebacks to the other departments. The programmers didn't realize it, but the sh*tty code was a goldmine for the department manager. One package messed up several times a day (cha ching!) and the programmers wanted to fix it once and for all. The manager bought an expensive code library system (for 4 programmers who sat in the same room) expressly to prevent them from fixing anything.
|
|
|
|
|
Ri_ wrote: I'm still amazed people pay the dev salaries they pay, and then shove the devs into an open plan office next to Customer Support, give them old machines and small screens.
Oh, I know what you mean. Some companies really don't think or get it, or really even have an understanding of what we do.
Ri_ wrote: I had a great manager who sat me down and said: "You are not responsible for the ultimate success of the project. If your advice is not accepted, you can't force it. Just do your best." If they don't want to hear, stop complaining, because it comes across as negative, and causes negativity. Try to coach your advice in nice terms, but if it isn't accepted, then gracefully back off, and just do your best with your own code.
I'll have to keep this in mind. Great point, just hard to remember sometimes.
Ri_ wrote: The saying comes to mind: Be the change you want to see. So be positive, practical, and constructive, no complaining, no blame-storming.
I agree. Even if I forget this one too at times. 
Ri_ wrote: All the best on your next project. Turn your reputation around
Thanks man!
Jeremy Falcon
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
