3 ms·

This is a terrible attitude and I hope I never have the displeasure of working with you. "What goes around comes around" is a horrible attempt at justifying do

by ramses0 13y ago

This is a terrible attitude and I hope I never have the displeasure of working with you. "What goes around comes around" is a horrible attempt at justifying doing poor work. Please see the following wikipedia entries: http://en.wikipedia.org/wiki/Abuse_defense http://en.wikipedia.org/wiki/Abuse_defense """it also refers more generally to any attempt by the defense to use a syndrome or societal condition to deflect responsibility away from the defendant. Sometimes the concept is referred to as the abuse excuse, in particular by the critics of the idea that guilty people may use past victimization to diminish the responsibility for their crimes.""" http://en.wikipedia.org/wiki/Learned_helplessness http://en.wikipedia.org/wiki/Learned_helplessness """Learned helplessness is a mental state in which an organism forced to endure aversive stimuli, or stimuli that are painful or otherwise unpleasant, becomes unable or unwilling to avoid subsequent encounters with those stimuli, even if they are escapable, presumably because it has learned that it cannot control the situation.""" http://en.wikipedia.org/wiki/Rationalization_(making_excuses) http://en.wikipedia.org/wiki/Rationalization_(making_excuses... """In psychology and logic, rationalization (also known as making excuses[1]) is a defense mechanism in which perceived controversial behaviors or feelings are logically justified and explained in a rational or logical manner in order to avoid any true explanation, and are made consciously tolerable – or even admirable and superior – by plausible means.""" Please grow up and learn to do the right thing, or at least make an attempt at doing the right thing instead of rationalizing "there was no other option, they made me suffer now you suffer, appeal to authority: but the CTO did it".

kohanz 13y ago
I don't think it's an attitude that anyone takes pride in. I can very much relate to the parent. You join a company, find out that their code-base is in an abysmal state (I would wager this is the case at most enterprise outfits with aging code) and go to work. Initially, you try to sound the alarm to your superiors, put in overtime to try and improve the code-base "bit by bit". However, over time you find out that those who are calling the shots (driven by business priorities) absolutely do not care, because the code does, more or less, what they say it will. Your co-workers have either always written poor quality code or have long-since resigned themselves to doing so. Remember, you can be in situations where "technical debt" can take months, even years to culminate into stuff hitting the fan, so management can remain blissfully unaware of what is brewing for long periods of time. I've been in these situations before, where your pride for writing good code is eventually beaten down by your surroundings and the conflicting priorities of management. I've always been uncomfortable in these situations and found a way to leave, but I don't think that means that I have a "terrible attitude".
- GFischer 13y ago
  Thank you. Yes, I work for a subsidiary of a large corporation, the main system is built on a 20-year old deprecated development environment called Forte 4GL ( http://en.wikipedia.org/wiki/Forte_4GL http://en.wikipedia.org/wiki/Forte_4GL ) with more than a million lines of code. Technical debt is humungous, but nobody cares since they just put more programmers to work (it's indescribably inefficient). I did manage to migrate one of the core subsystems (policy issuance and data entry) to .NET, and I'm pretty proud of that, but my work wasn't recognized by management, which spends all the time in politics (and advancement is only a function of office politics, etc.). Management is pretty short-sighted, prioritizing short-term shiny new things over fixing problems that will blow up long term. So after 5 years I'm leaving, I should have left much earlier but well paying, stable jobs are not so easy to get in my country, and I didn't want to emigrate and was afraid of change. My prediction is that the mismanagement will blow in managements' face when the next economic crisis hits (currently my country is in an economic bonanza which masks bad decisions and mismanagement).
GFischer 13y ago
I'm not proud of what I did. I was making light of the situation a bit, though. I know intent doesn't carry through the Internet, so I apologize.
- ramses0 13y ago
  Yeah, I debated on whether to post the comment or not, but I felt it was an important point to make, and an opportunity to self-reflect on whether you're proud / happy of your work and how to move forward. I'm also working on a 10+ year old code-base and while I can't always make things "perfect", I always aspire to make things better, and there is no excuse for not documenting (absolutely none, here!), or not writing (unit) tests. In the future: Documentation is CHEAP! Document your functions at least, there is no excuse, and it is helpful to do "README.txt/DESIGN.txt" style documentation / notes and check it in. Unit tests can be expensive, but even simply (1 == expected("input1", "input2") || print "FAIL";) is a 100% valid unit test framework in a pinch. These are very valid techniques to internalize and much better than "but the CTO did it to me first" rationalization.

by ramses0 13y ago

kohanz 13y ago

I don't think it's an attitude that anyone takes pride in. I can very much relate to the parent. You join a company, find out that their code-base is in an abysmal state (I would wager this is the case at most enterprise outfits with aging code) and go to work. Initially, you try to sound the alarm to your superiors, put in overtime to try and improve the code-base "bit by bit". However, over time you find out that those who are calling the shots (driven by business priorities) absolutely do not care, because the code does, more or less, what they say it will. Your co-workers have either always written poor quality code or have long-since resigned themselves to doing so. Remember, you can be in situations where "technical debt" can take months, even years to culminate into stuff hitting the fan, so management can remain blissfully unaware of what is brewing for long periods of time. I've been in these situations before, where your pride for writing good code is eventually beaten down by your surroundings and the conflicting priorities of management. I've always been uncomfortable in these situations and found a way to leave, but I don't think that means that I have a "terrible attitude".

GFischer 13y ago
Thank you. Yes, I work for a subsidiary of a large corporation, the main system is built on a 20-year old deprecated development environment called Forte 4GL ( http://en.wikipedia.org/wiki/Forte_4GL http://en.wikipedia.org/wiki/Forte_4GL ) with more than a million lines of code. Technical debt is humungous, but nobody cares since they just put more programmers to work (it's indescribably inefficient). I did manage to migrate one of the core subsystems (policy issuance and data entry) to .NET, and I'm pretty proud of that, but my work wasn't recognized by management, which spends all the time in politics (and advancement is only a function of office politics, etc.). Management is pretty short-sighted, prioritizing short-term shiny new things over fixing problems that will blow up long term. So after 5 years I'm leaving, I should have left much earlier but well paying, stable jobs are not so easy to get in my country, and I didn't want to emigrate and was afraid of change. My prediction is that the mismanagement will blow in managements' face when the next economic crisis hits (currently my country is in an economic bonanza which masks bad decisions and mismanagement).

GFischer 13y ago

I'm not proud of what I did. I was making light of the situation a bit, though. I know intent doesn't carry through the Internet, so I apologize.

ramses0 13y ago
Yeah, I debated on whether to post the comment or not, but I felt it was an important point to make, and an opportunity to self-reflect on whether you're proud / happy of your work and how to move forward. I'm also working on a 10+ year old code-base and while I can't always make things "perfect", I always aspire to make things better, and there is no excuse for not documenting (absolutely none, here!), or not writing (unit) tests. In the future: Documentation is CHEAP! Document your functions at least, there is no excuse, and it is helpful to do "README.txt/DESIGN.txt" style documentation / notes and check it in. Unit tests can be expensive, but even simply (1 == expected("input1", "input2") || print "FAIL";) is a 100% valid unit test framework in a pinch. These are very valid techniques to internalize and much better than "but the CTO did it to me first" rationalization.