Office politics and sh*tty code.
-
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:
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
-
I'm very meticulous about the code I write. I always use regions, and I use the same regions in the same order in every class. This way I know exactly where code parts are. Also, all of my class members are listed alphabetically in their regions. When I see bad code, I schedule it for a refactor. I'm actually sitting here right now refactoring some offshore code. These guys just throw code in anywhere and its annoying and flat out lazy. Unlike you, my manager is totally on board with me cleaning up the code.
If it's not broken, fix it until it is
Kevin Marois wrote:
I always use regions
I really hate regions! :sigh: They obfuscate the code, you only get to see parts of it, but I want it all! If your code is really so properly written you shouldn't need regions. If you have regions in a single function then refactor that function so the regions now become functions. If you have regions in a single class then refactor that class so the regions now become classes. The only thing I usually put in a region is the Dispose function. Mostly because that's in the default Visual Studio snippet. And ordering alphabetically is just tedious and unnecessary, Visual Studio lists everything in an ordered list already. And huge big ass unwieldy functions and classes can still be ordered :rolleyes: I'm not complaining, I'm trying to make your code better ;p Also a nice examples how one programmers clean code is another programmers nightmare :)
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
You've got to work on how you complain. Taking the direct route ("This is cr@p!" or a paraphrase thereof) might seem the logical route, because it's the truth, but it's not the way to put the point across. You're working with people, not machines, so you have to take feelings into account, just as you'd like others to take your feelings into account. As you said, you (and you are not alone) have written shall we say "less than optimal" code, in the past, so before pointing out errors/problems, think about how you would like people to point out the errors/problems in your own code. Then think of someone you work with whom you don't particularly like, and imagine how you would react to their "negative analysis" of your errors. Take that into account when you want to tell someone that something is "less than optimal" -- e.g. phrase it "Hey, this was a good start, and I think we could build on it!", rather than "This needs to be rewritten!" If you've already developed the rep of being a moaner, you should work very hard on getting things done without making that rep worse. Treating people as you would like to be treated yourself costs nothing more than a little thought.
I wanna be a eunuchs developer! Pass me a bread knife!
Feelings shmeelings! :sigh:
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects. Now, I'll be the first to say in my day I've written crap, so who am I to judge right? But, over the decades of development I've done, I'd like to at least think I've learned what crap is and what's it's not. And as such, I find myself in a position at a job I've been at since mid February, where I tend to complain a lot - because the quality of code is so poor it's just sad. But, I complain because I want to see it improve. Seeing that nobody wants to be told their code sucks (even if it's true), I've been labeled a bit of a complainer unfortunately. And while I get that, the fact remains, the code is actually not that great. Which is pretty evident by virtue of the fact they always have problems with it. Well duh, I wonder why. But who wants to be the party pooper right? Whatever the case, my manager is getting fairly tired of hearing me complain, which is a bit of a downer since I've only been doing it because some things needs to be addressed to make our projects top quality. So, is there some fancy judo mind trick to get my point through, or must I accept you cannot fit a square peg into a round hole, and if people don't care about the quality of their work then you can't force them to?
Jeremy Falcon
Jeremy Falcon wrote:
I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects. Now, I'll be the first to say in my day I've written crap, so who am I to judge right? But, over the decades of development I've done, I'd like to at least think I've learned what crap is and what's it's not. And as such, I find myself in a position at a job I've been at since mid February, where I tend to complain a lot - because the quality of code is so poor it's just sad. But, I complain because I want to see it improve. Seeing that nobody wants to be told their code sucks (even if it's true), I've been labeled a bit of a complainer unfortunately. And while I get that, the fact remains, the code is actually not that great. Which is pretty evident by virtue of the fact they always have problems with it. Well duh, I wonder why. But who wants to be the party pooper right? Whatever the case, my manager is getting fairly tired of hearing me complain, which is a bit of a downer since I've only been doing it because some things needs to be addressed to make our projects top quality. So, is there some fancy judo mind trick to get my point through, or must I accept you cannot fit a square peg into a round hole, and if people don't care about the quality of their work then you can't force them to?
Jeremy Falcon
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 :laugh: All the best on your next project. Turn your reputation around :cool:
-
I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects. Now, I'll be the first to say in my day I've written crap, so who am I to judge right? But, over the decades of development I've done, I'd like to at least think I've learned what crap is and what's it's not. And as such, I find myself in a position at a job I've been at since mid February, where I tend to complain a lot - because the quality of code is so poor it's just sad. But, I complain because I want to see it improve. Seeing that nobody wants to be told their code sucks (even if it's true), I've been labeled a bit of a complainer unfortunately. And while I get that, the fact remains, the code is actually not that great. Which is pretty evident by virtue of the fact they always have problems with it. Well duh, I wonder why. But who wants to be the party pooper right? Whatever the case, my manager is getting fairly tired of hearing me complain, which is a bit of a downer since I've only been doing it because some things needs to be addressed to make our projects top quality. So, is there some fancy judo mind trick to get my point through, or must I accept you cannot fit a square peg into a round hole, and if people don't care about the quality of their work then you can't force them to?
Jeremy Falcon
In my past position I managed a team. My rule of thumb was to give the job of fixing stuff to the person that most loudly complained that it was broken. It's a win-win. :)
-
Kevin Marois wrote:
I schedule it for a refactor.
Let me put it to you like this, the people running this show have probably never refactored anything in their life. And I seriously doubt they know what that is without googling it.
Jeremy Falcon
-
I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects. Now, I'll be the first to say in my day I've written crap, so who am I to judge right? But, over the decades of development I've done, I'd like to at least think I've learned what crap is and what's it's not. And as such, I find myself in a position at a job I've been at since mid February, where I tend to complain a lot - because the quality of code is so poor it's just sad. But, I complain because I want to see it improve. Seeing that nobody wants to be told their code sucks (even if it's true), I've been labeled a bit of a complainer unfortunately. And while I get that, the fact remains, the code is actually not that great. Which is pretty evident by virtue of the fact they always have problems with it. Well duh, I wonder why. But who wants to be the party pooper right? Whatever the case, my manager is getting fairly tired of hearing me complain, which is a bit of a downer since I've only been doing it because some things needs to be addressed to make our projects top quality. So, is there some fancy judo mind trick to get my point through, or must I accept you cannot fit a square peg into a round hole, and if people don't care about the quality of their work then you can't force them to?
Jeremy Falcon
There are some fancy judo mind tricks, but they only work on clever people. In your situation, it is impossible to get your points through. Forget about them. Leave. Actually, if you want, before you leave, you might prepare a detailed document, explaining the shortcomings and the ways that they can be fixed. And hand the document to them, in an email. This way, they will think twice before saying anything negative about you in the future. You see, the written word has power and ability to persist over the years. Later on, you might need proof that you did make your points and arguments. Please read the following, to understand the importance of documenting your views for the future: Your Software is Never Perfect
-
I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects. Now, I'll be the first to say in my day I've written crap, so who am I to judge right? But, over the decades of development I've done, I'd like to at least think I've learned what crap is and what's it's not. And as such, I find myself in a position at a job I've been at since mid February, where I tend to complain a lot - because the quality of code is so poor it's just sad. But, I complain because I want to see it improve. Seeing that nobody wants to be told their code sucks (even if it's true), I've been labeled a bit of a complainer unfortunately. And while I get that, the fact remains, the code is actually not that great. Which is pretty evident by virtue of the fact they always have problems with it. Well duh, I wonder why. But who wants to be the party pooper right? Whatever the case, my manager is getting fairly tired of hearing me complain, which is a bit of a downer since I've only been doing it because some things needs to be addressed to make our projects top quality. So, is there some fancy judo mind trick to get my point through, or must I accept you cannot fit a square peg into a round hole, and if people don't care about the quality of their work then you can't force them to?
Jeremy Falcon
I read your post with interest. While our situations are not the same (I'm not a software writer by trade) they are similar. I work for a small, family run, engineering company, and I have never seen such a disorganised, run down place in all my life. It belongs in the Victorian era! I have complained about the state of the equipment (donkey's years old), the building (leaking roof, filthy, dark and dingey), the working practices (it's a health & safety hazard) and the business processes (or, rather lack of them). There's no emphasis on actually making a profit yet the owners are tighter than Ebenezer Scrooge when it comes to spending any money - on anything. I have got that fed up complaining that I've come to the conclusion that the only way to deal with it is to just 'go with the flow'. If they want to run a sh*thole of a company, then who am I to make waves? Afterall, it's not MY company. What does elephant me off is if the place goes bust due to bad management, then I'm out of a job due to someone else's incompetence. In conclusion, my advice to you is to go with the flow too - you can't control what you don't own. As galling as it is, it's not worth getting annoyed, or making yourself unpopular because of other people's inability to do their job correctly. Life's too short, take a chill pill and bite your tongue.
-
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 fucking 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!
-
I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects. Now, I'll be the first to say in my day I've written crap, so who am I to judge right? But, over the decades of development I've done, I'd like to at least think I've learned what crap is and what's it's not. And as such, I find myself in a position at a job I've been at since mid February, where I tend to complain a lot - because the quality of code is so poor it's just sad. But, I complain because I want to see it improve. Seeing that nobody wants to be told their code sucks (even if it's true), I've been labeled a bit of a complainer unfortunately. And while I get that, the fact remains, the code is actually not that great. Which is pretty evident by virtue of the fact they always have problems with it. Well duh, I wonder why. But who wants to be the party pooper right? Whatever the case, my manager is getting fairly tired of hearing me complain, which is a bit of a downer since I've only been doing it because some things needs to be addressed to make our projects top quality. So, is there some fancy judo mind trick to get my point through, or must I accept you cannot fit a square peg into a round hole, and if people don't care about the quality of their work then you can't force them to?
Jeremy Falcon
I stopped complaining and caring. The codebase sucks, both changing it and working around require time. I present my points in the most objective way, stating very clearly that some things are impeded by the existing situation. If the company doesn't care about my efficiency, why should I? Also this way I can slow down when I feel like to and I have something to rightfully blame. It's a nice buffer for the downer periods.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
-
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.
-
I stopped complaining and caring. The codebase sucks, both changing it and working around require time. I present my points in the most objective way, stating very clearly that some things are impeded by the existing situation. If the company doesn't care about my efficiency, why should I? Also this way I can slow down when I feel like to and I have something to rightfully blame. It's a nice buffer for the downer periods.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
den2k88 wrote:
present my points in the most objective way, stating very clearly that some things are impeded by the existing situation.
We call that "things have grown historically" here. It is very frustrating to find out, you can't do anything about it because (even being cr@p suboptimal) it still works. Changing it is nearly impossible without starting over again due to so many years of additions / bypasses / workarounds.
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.
-
I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects. Now, I'll be the first to say in my day I've written crap, so who am I to judge right? But, over the decades of development I've done, I'd like to at least think I've learned what crap is and what's it's not. And as such, I find myself in a position at a job I've been at since mid February, where I tend to complain a lot - because the quality of code is so poor it's just sad. But, I complain because I want to see it improve. Seeing that nobody wants to be told their code sucks (even if it's true), I've been labeled a bit of a complainer unfortunately. And while I get that, the fact remains, the code is actually not that great. Which is pretty evident by virtue of the fact they always have problems with it. Well duh, I wonder why. But who wants to be the party pooper right? Whatever the case, my manager is getting fairly tired of hearing me complain, which is a bit of a downer since I've only been doing it because some things needs to be addressed to make our projects top quality. So, is there some fancy judo mind trick to get my point through, or must I accept you cannot fit a square peg into a round hole, and if people don't care about the quality of their work then you can't force them to?
Jeremy Falcon
"sucking" is not an objective property. You might want to restate your complaints more factually, by listing the use cases that the existing code fails to address, and offer a solution that does. Also, offering estimates to fix the code compared to the mid-term cost of doing nothing might get you more attention than just 'complaining'. Cost is always the relevant factor. Code looking nice isn't.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects. Now, I'll be the first to say in my day I've written crap, so who am I to judge right? But, over the decades of development I've done, I'd like to at least think I've learned what crap is and what's it's not. And as such, I find myself in a position at a job I've been at since mid February, where I tend to complain a lot - because the quality of code is so poor it's just sad. But, I complain because I want to see it improve. Seeing that nobody wants to be told their code sucks (even if it's true), I've been labeled a bit of a complainer unfortunately. And while I get that, the fact remains, the code is actually not that great. Which is pretty evident by virtue of the fact they always have problems with it. Well duh, I wonder why. But who wants to be the party pooper right? Whatever the case, my manager is getting fairly tired of hearing me complain, which is a bit of a downer since I've only been doing it because some things needs to be addressed to make our projects top quality. So, is there some fancy judo mind trick to get my point through, or must I accept you cannot fit a square peg into a round hole, and if people don't care about the quality of their work then you can't force them to?
Jeremy Falcon
Jeremy, instead of telling them about the 'bad code', try suggesting them an approach and a solution to get it improved, and the positive impact it might or will have on the issues they're having. try to come up with a top 10 of bad pieces or patterns, estimate the cost of fixing it, convince them of the positive impact it will have in some areas. If some knowledge is missing for some co-workers, try to identify it, and get them trained/skilled in some way. But anyway, try to split up the 'bad code' in manageable chunks of work. Perhaps even code analyzing tools like SonarQube/SonarLint, Resharper, FXCop,... might assist you in making your point with your mgmt, because sometimes data and pictures say more than a thousand words, right? Also try to find out WHY there is so much bad code, just to be able to avoid it in the future. Like said before, is it a lack of knowledge, get some training. But it can also be that they count too little time to get a feature implemented, resulting in messy code. Is it because they never had a 'big plan', a vision for their application, which resulted in always adding some piece of code without having a 'grand design', which again results in messy code and structure.
-
Jeremy, instead of telling them about the 'bad code', try suggesting them an approach and a solution to get it improved, and the positive impact it might or will have on the issues they're having. try to come up with a top 10 of bad pieces or patterns, estimate the cost of fixing it, convince them of the positive impact it will have in some areas. If some knowledge is missing for some co-workers, try to identify it, and get them trained/skilled in some way. But anyway, try to split up the 'bad code' in manageable chunks of work. Perhaps even code analyzing tools like SonarQube/SonarLint, Resharper, FXCop,... might assist you in making your point with your mgmt, because sometimes data and pictures say more than a thousand words, right? Also try to find out WHY there is so much bad code, just to be able to avoid it in the future. Like said before, is it a lack of knowledge, get some training. But it can also be that they count too little time to get a feature implemented, resulting in messy code. Is it because they never had a 'big plan', a vision for their application, which resulted in always adding some piece of code without having a 'grand design', which again results in messy code and structure.
ok, and if the company is aware of this situation, and they really truly don't care about it, they probably will have their reasons. Like a plan of decommissioning the software, or the costs of fixing it will cost more than the return will be. All valid reasons. Because sometimes a developer wants to show how good a programmer he is without taking notice of the context. Sometimes a company just wants a quick and dirty solution because they're not going to make a lot of money out of it. Which should only take like say 5 days to develop. You shouldn't be the super-professional and say : ok, but to get it perfect, I need 20 days, and I only want to deliver a perfect job. Well, if the company is asking for a 'draft' version, give them a draft version, if that's what they only can afford. Not everyone wants to buy a Porsche, most people just want a car that brings them from A to B.
-
I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects. Now, I'll be the first to say in my day I've written crap, so who am I to judge right? But, over the decades of development I've done, I'd like to at least think I've learned what crap is and what's it's not. And as such, I find myself in a position at a job I've been at since mid February, where I tend to complain a lot - because the quality of code is so poor it's just sad. But, I complain because I want to see it improve. Seeing that nobody wants to be told their code sucks (even if it's true), I've been labeled a bit of a complainer unfortunately. And while I get that, the fact remains, the code is actually not that great. Which is pretty evident by virtue of the fact they always have problems with it. Well duh, I wonder why. But who wants to be the party pooper right? Whatever the case, my manager is getting fairly tired of hearing me complain, which is a bit of a downer since I've only been doing it because some things needs to be addressed to make our projects top quality. So, is there some fancy judo mind trick to get my point through, or must I accept you cannot fit a square peg into a round hole, and if people don't care about the quality of their work then you can't force them to?
Jeremy Falcon
Every job, whether or not it is coding or something else like building industrial machinery (I do both), comes with this issue. The key is not to complain. Constructive criticism comes in many forms, but the way you do it will determine how you come across. Bear in mind, I often forget these tips myself
-
First don’t single out specific instances, but look for common practices that can be improved. “Each programmer does their class naming differently”
-
Rather than point out what’s wrong, provide systemic solutions. “Should we develop a common naming convention?”
-
State your solutions as a question whenever possible, “do you think this would work?”
-
Acknowledge what’s good about the problem code “This is great at consolidating the information, but if we restructure the data this way…, it would be easier to understand.”
-
Do the work to fix the problem, then share/explain what you did and why you did it.
-
-
You've got to work on how you complain. Taking the direct route ("This is cr@p!" or a paraphrase thereof) might seem the logical route, because it's the truth, but it's not the way to put the point across. You're working with people, not machines, so you have to take feelings into account, just as you'd like others to take your feelings into account. As you said, you (and you are not alone) have written shall we say "less than optimal" code, in the past, so before pointing out errors/problems, think about how you would like people to point out the errors/problems in your own code. Then think of someone you work with whom you don't particularly like, and imagine how you would react to their "negative analysis" of your errors. Take that into account when you want to tell someone that something is "less than optimal" -- e.g. phrase it "Hey, this was a good start, and I think we could build on it!", rather than "This needs to be rewritten!" If you've already developed the rep of being a moaner, you should work very hard on getting things done without making that rep worse. Treating people as you would like to be treated yourself costs nothing more than a little thought.
I wanna be a eunuchs developer! Pass me a bread knife!
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'm just curious to know how everyone else here deals with poorly written code in pre-existing projects. Now, I'll be the first to say in my day I've written crap, so who am I to judge right? But, over the decades of development I've done, I'd like to at least think I've learned what crap is and what's it's not. And as such, I find myself in a position at a job I've been at since mid February, where I tend to complain a lot - because the quality of code is so poor it's just sad. But, I complain because I want to see it improve. Seeing that nobody wants to be told their code sucks (even if it's true), I've been labeled a bit of a complainer unfortunately. And while I get that, the fact remains, the code is actually not that great. Which is pretty evident by virtue of the fact they always have problems with it. Well duh, I wonder why. But who wants to be the party pooper right? Whatever the case, my manager is getting fairly tired of hearing me complain, which is a bit of a downer since I've only been doing it because some things needs to be addressed to make our projects top quality. So, is there some fancy judo mind trick to get my point through, or must I accept you cannot fit a square peg into a round hole, and if people don't care about the quality of their work then you can't force them to?
Jeremy Falcon
If you complain, you must be willing and able to change it for the better, but once you do, you own the code and any problems or side-effects that might occur.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
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.
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.
