Hacker News Reader

Hacker News

Comment by snockerton | Hacker News Reader

Parent Full thread

snockerton

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...

View on HN

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.

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

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.

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.

Nothing...

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

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.

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

>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 :)

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

> 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.

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."

I too want to get paid for being irresponsible.

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.

Reply on news.ycombinator.com