6 ms·

This is the same CYA attitude that I have been assuming the last 2 years because it's such a frequent occurrence. The only issue is that I still get blamed. I

This is the same CYA attitude that I have been assuming the last 2 years because it's such a frequent occurrence. The only issue is that I still get blamed. I don't know how many times I've repeated this scenario: 1. I highlight gap / issue in code. 2. Team says, "Need to ship; we'll accept the risk" 3. During go-live, fecal matter hits fan because of aforementioned gap in code. 4. Everyone acts surprised. 5. I point out that I mentioned it 2 months ago. 6. Everyone makes excuses / claims they don't remember it that way / moves on to burn down another project. 7. I'm left to clean up a mess / have taken a hit to my reputation. Not sure what I'm doing wrong...

ScottBurson 10y ago
Next time you raise an issue, point out what happened last time. Then fix it.
neffy 10y ago
Nothing... In the country of the blind, the one eyed man gets locked up in a lunatic asylum.
rhapsodic 10y ago
> Not sure what I'm doing wrong... Perhaps you failed to build a paper trail (i.e. an email trail) to document the fact that you predicted the disaster, and who it was that decided to ignore your warnings. If you do that, when the fingers start pointing in your direction, you can send everyone copies of the emails that prove who is responsible for the mess.
- st3v3r 10y ago
  No, that's not it, because usually management doesn't give a shit about that. Even if you have the paper trail, they're still going to say, "Quit whining; it's 3 AM and stuff doesn't work. Fix it."
  - Pica_soO 10y ago
    I too want to get paid for being irresponsible.
    - st3v3r 10y ago
      If they want us to be responsible, then they need to give us what we need when we say we need it. You're saying they should be able to make us cut corners and then support it. You don't get to have your cake and eat it, too.
sopooneo 10y ago
You have to win people over by making their lives easier or by making them look good. This does not necessarily have to be related to code or technology in any way. Then, after people have a visceral positive feeling about you, make some tiny suggestion for improvement. Make the improvement, and whoever approved it, do something to make sure they associate your suggestion with a positive experience. Slowly repeat. It is a slight selling of your soul. It is effective.
wccrawford 10y ago
IMO there's nothing you can do to fix this culture. They're determined to ignore the inconvenient problems and then conveniently forget they were told about them. Even if you attempt to document these things, you'll just be labeled some negative name like "whistler blower" or "anal" and the same reputation problems will exist. FWIW, 2 things mitigate this. First, some companies do actually remember people who fix things and get things done, so that's on your side. The other is that it's not likely you'll be there long-term anyhow. Companies that do this also generally fail in other departments, like paying you what you're worth as your worth increases. So you'll probably look for a new job eventually anyhow. I know it's hard to see from where you're standing, but I wouldn't fret about it. Just keep doing your job the best you can and warning them, and let the chips fall where they may.
bpyne 10y ago
Perhaps you're doing what I'm about to recommend already, but I can't be sure based on what you wrote. It's in regard to "2. Team says, "Need to ship; we'll accept the risk". If the Business Unit, for whom the software is being written, has a representative on your team, then make sure you explain the risk in purely business terms, not technical ones. A BU rep's ears are going to perk up with statements like "invalid posts may get written to the general ledger" or "1 in every 20 orders may get dropped" rather than "universally scoped variables are being overwritten by invalid data in some cases" or "uncommitted nested transactions may cause a core dump." If your team doesn't include a BU rep, then you could always get friendly with one and explain the potential risks over coffee or lunch. Perhaps even suggest some questions the rep should ask the team before the mod goes live. In my situation, a BU rep is always part of the team and I rarely have other developers on the team. The reps and I have lunch together regularly anyway, so they get my opinions and recommendations that way.
- flukus 10y ago
  9 times out of 10 it's the "BU rep" that's responsible for rushing things out the door yesterday.
ljw1001 10y ago
The only thing you're doing wrong is pointing out that you mentioned it two months ago. That's the last thing an organization faced with a problem wants to hear. What they want is for everyone to act like the problem was entirely unpredictable and have everyone make 'heroic efforts' to make the fix.
- AnimalMuppet 10y ago
  Thereby perpetuating the culture that ignored the issue, and providing no downside to the individuals that ignored it.
trhway 10y ago
>1. I highlight gap / issue in code. >Not sure what I'm doing wrong... probably you're doing it too serious and taking it too personal. After 20+ years in the industry, I got desensitiveized enough to bother that much about small things, and when i point to the issue i usually do it in the "constructive" "spirit-sharing" and "team-building" way - "Ha! Just imagine how those suckers - customers or downstream devs - would be hitting that bug, completely lost at what to do, they would have no chances to make it work so we should give out a Grand Prize to the unlikely one who would make it through... " I noticed that various leaders/management/etc. have hard time to full-heartedly subscribe to that vision of future. Not that that gets the thing fixed or anything like this, mind you. Yet it helps with the blame part if/when it still comes my way - "Wow! when _we_ (me and you, the manager/etc.) were laughing at it _we_ did look into the crystal ball! _We_ are that smart!" The management somehow don't enjoy sharing in on that smartness :)

ScottBurson 10y ago

Next time you raise an issue, point out what happened last time. Then fix it.

neffy 10y ago

Nothing... In the country of the blind, the one eyed man gets locked up in a lunatic asylum.

rhapsodic 10y ago

> Not sure what I'm doing wrong... Perhaps you failed to build a paper trail (i.e. an email trail) to document the fact that you predicted the disaster, and who it was that decided to ignore your warnings. If you do that, when the fingers start pointing in your direction, you can send everyone copies of the emails that prove who is responsible for the mess.

st3v3r 10y ago
No, that's not it, because usually management doesn't give a shit about that. Even if you have the paper trail, they're still going to say, "Quit whining; it's 3 AM and stuff doesn't work. Fix it."
- Pica_soO 10y ago
  I too want to get paid for being irresponsible.
  - st3v3r 10y ago
    If they want us to be responsible, then they need to give us what we need when we say we need it. You're saying they should be able to make us cut corners and then support it. You don't get to have your cake and eat it, too.

sopooneo 10y ago

You have to win people over by making their lives easier or by making them look good. This does not necessarily have to be related to code or technology in any way. Then, after people have a visceral positive feeling about you, make some tiny suggestion for improvement. Make the improvement, and whoever approved it, do something to make sure they associate your suggestion with a positive experience. Slowly repeat. It is a slight selling of your soul. It is effective.

wccrawford 10y ago

IMO there's nothing you can do to fix this culture. They're determined to ignore the inconvenient problems and then conveniently forget they were told about them. Even if you attempt to document these things, you'll just be labeled some negative name like "whistler blower" or "anal" and the same reputation problems will exist. FWIW, 2 things mitigate this. First, some companies do actually remember people who fix things and get things done, so that's on your side. The other is that it's not likely you'll be there long-term anyhow. Companies that do this also generally fail in other departments, like paying you what you're worth as your worth increases. So you'll probably look for a new job eventually anyhow. I know it's hard to see from where you're standing, but I wouldn't fret about it. Just keep doing your job the best you can and warning them, and let the chips fall where they may.

bpyne 10y ago

Perhaps you're doing what I'm about to recommend already, but I can't be sure based on what you wrote. It's in regard to "2. Team says, "Need to ship; we'll accept the risk". If the Business Unit, for whom the software is being written, has a representative on your team, then make sure you explain the risk in purely business terms, not technical ones. A BU rep's ears are going to perk up with statements like "invalid posts may get written to the general ledger" or "1 in every 20 orders may get dropped" rather than "universally scoped variables are being overwritten by invalid data in some cases" or "uncommitted nested transactions may cause a core dump." If your team doesn't include a BU rep, then you could always get friendly with one and explain the potential risks over coffee or lunch. Perhaps even suggest some questions the rep should ask the team before the mod goes live. In my situation, a BU rep is always part of the team and I rarely have other developers on the team. The reps and I have lunch together regularly anyway, so they get my opinions and recommendations that way.

flukus 10y ago
9 times out of 10 it's the "BU rep" that's responsible for rushing things out the door yesterday.

ljw1001 10y ago

The only thing you're doing wrong is pointing out that you mentioned it two months ago. That's the last thing an organization faced with a problem wants to hear. What they want is for everyone to act like the problem was entirely unpredictable and have everyone make 'heroic efforts' to make the fix.

AnimalMuppet 10y ago
Thereby perpetuating the culture that ignored the issue, and providing no downside to the individuals that ignored it.

trhway 10y ago

>1. I highlight gap / issue in code. >Not sure what I'm doing wrong... probably you're doing it too serious and taking it too personal. After 20+ years in the industry, I got desensitiveized enough to bother that much about small things, and when i point to the issue i usually do it in the "constructive" "spirit-sharing" and "team-building" way - "Ha! Just imagine how those suckers - customers or downstream devs - would be hitting that bug, completely lost at what to do, they would have no chances to make it work so we should give out a Grand Prize to the unlikely one who would make it through... " I noticed that various leaders/management/etc. have hard time to full-heartedly subscribe to that vision of future. Not that that gets the thing fixed or anything like this, mind you. Yet it helps with the blame part if/when it still comes my way - "Wow! when _we_ (me and you, the manager/etc.) were laughing at it _we_ did look into the crystal ball! _We_ are that smart!" The management somehow don't enjoy sharing in on that smartness :)