Communication is a 2way street. If this was my manager I'd never try and help them make decisions again.
The futility of “I told you so” in software engineering teams
61–70 of 84 posts
Re: The futility of “I told you so” in software engineering teams
#62Earlier quoted context omitted.
The real trick is that caring about anything in the modern corporate workplace is a mistake. Unless you hold equity and board position in the company, then you are completely replaceable at any time for any reason. The only thing you should be doing is ensuring that the chain of decision making is documented so blame flows upwards. And exercise some discretion in ensuring you get away from managers with a track histo…
> The real trick is that caring about anything in the modern corporate workplace is a mistake If I could go back 20 years and give myself one piece of mental health advice, this would be it.
This is an "I told you so" to myself. For all of my carreer I avoided big corporate companies because I just assumed I would hate it, even though at least in the past it maybe sounded more glamorous and I could probably make a lot more money. Recently, through no action of my own, my company was sold to a much larger company. Well I was right.
And you have nailed the essential heart of it I think. You just have to not care about what you're doing, how well it could be done, or what tools you're using to do it.
Which is just no way to live.
But you still have to excel and look good somehow, even with no freedom of movement to excel IN. All you can do is do the pre-scribed wrong things, well.
Re: The futility of “I told you so” in software engineering teams
#63Earlier quoted context omitted.
The faster it fails, the faster you might have an opportunity to point out the failure points and suggest the correct solution.
Sometimes the solution is 'not to do that bad thing' and quite often there's no going back from that.
Agree, but if you are the person to say "I told you so", you aren't in a position to influence avoiding that condition. Also, the individuals in the project have the potential to learn from the failure even if the project/company doesn't survive.
Obviously there are life critical systems where this shouldn't even be possible, but hopefully there are tests and trials that filter broken products/services before life is put in harm's way.
Re: The futility of “I told you so” in software engineering teams
#64> Your “I told you so” only highlights that you need to construct stronger arguments. Most of the time I'm not been listened to and should have been, I feel like it is out of apathy or laziness, not out of whether the argument was sufficiently strong. My request "this will not work for X reasons" is almost always followed by "and Y is what we need to do", but Y implies … additional work. The culture of current corpor…
The version of this that continually bites me is when someone is designing what is essentially a distributed system but doesn't know that's what they are designing. System W -> System X -> System Y -> System Z are connected with the assumption no guarantees or coherency checks are needed. Might as well just email spreadsheets...
Isn't the usual assumption that team w is responsible for system W to work, team x for system X, etc? And you can figure out who needs to fix a problem when it comes up?
Re: The futility of “I told you so” in software engineering teams
#65Earlier quoted context omitted.
> The real trick is that caring about anything in the modern corporate workplace is a mistake If I could go back 20 years and give myself one piece of mental health advice, this would be it.
This is an "I told you so" to myself. For all of my carreer I avoided big corporate companies because I just assumed I would hate it, even though at least in the past it maybe sounded more glamorous and I could probably make a lot more money. Recently, through no action of my own, my company was sold to a much larger company. Well I was right. And you have nailed the essential heart of it I think. You just have to no…
> You just have to not care about what you're doing
You do have to care, you're just mistaken about what it is people in big corporate companies are actually doing. What they're doing is advancing their own careers and those of their network.
> how well it could be done
Reflected in the rate of advancement, which can be actively maximized through effort and attention.
> what tools you're using to do it.
The "work" is in fact one of several tools used to advance the career. This is why it is so frequently performed with little care or love. Often it only matters to the career to the extent that it can be declared "done." Most companies lack mechanisms to tie what happens later back to the original doer, so the marginal benefits of care and quality to the career are low.
If you care about the actual "work" and craft it's best to find a place with little to no concept of advancement, in my opinion.
EDIT: Some people really are just phoning it in for a paycheck, and who can really blame them? Others who may appear to be lazy or careless simply have a different set of priorities. If those priorities offend you but the person is nevertheless succeeding, probably a good idea to move away from that environment.
Re: The futility of “I told you so” in software engineering teams
#66Earlier quoted context omitted.
> The real trick is that caring about anything in the modern corporate workplace is a mistake If I could go back 20 years and give myself one piece of mental health advice, this would be it.
This is an "I told you so" to myself. For all of my carreer I avoided big corporate companies because I just assumed I would hate it, even though at least in the past it maybe sounded more glamorous and I could probably make a lot more money. Recently, through no action of my own, my company was sold to a much larger company. Well I was right. And you have nailed the essential heart of it I think. You just have to no…
This has not been my experience at a big tech company(well, amazon)
There's plenty of leeway for choosing solutions and who's responsible for what kind of failures.
I for one have spent a while trying to make sure I just have to throw an exception(with increasingly better messages), and somebody else needs to solve the problem
Re: The futility of “I told you so” in software engineering teams
#67> If your past warnings were ignored and you do not feel that there are any politics / biases / prejudices in active play, it is time to introspect, reflect, and ask:
> “How will I make my case differently next time?”
For me, this usually comes down to "Who will I make my case to next time?" - IE, if you aren't listening to me, making messes that I told you would happen, then expecting me to clean it up, it's time to go. And before someone asks, this has happened more times than I can count.
You can never fully discount politics / biases / prejudices and in general (not just personal bias, but technological bias), I find these are the most obvious answers to how a team makes decisions that are against its own best interest. It very rarely comes down to "I made my argument wrong." If anything, on a good team, even if you make your argument wrong, other people will pick up on it and help to correct the wrong parts, and keep the right parts.
Re: The futility of “I told you so” in software engineering teams
#68Personal problem? Maybe rethink your approach, but maybe it's a . . .
Systemic problem? Figure out how the team can collect and act on feedback better, then again is it . . .
The best of all possible worlds? Maybe you're not personally inadequate. Maybe the system works as well as it can given whatever constraints. Maybe this problem is not such a problem after all.
Re: The futility of “I told you so” in software engineering teams
#69Your “I told you so” only highlights that you need to construct stronger arguments. No, sorry. Most places don't allow people time to construct stronger arguments. Most experienced people have a gut feel for what is going to go wrong. We are pattern machines, and they are feeling the pattern. That would be part of the definition for experience. Decent decision makers have worked on the skills to ask questions when ex…
Re: The futility of “I told you so” in software engineering teams
#70Earlier quoted context omitted.
The version of this that continually bites me is when someone is designing what is essentially a distributed system but doesn't know that's what they are designing. System W -> System X -> System Y -> System Z are connected with the assumption no guarantees or coherency checks are needed. Might as well just email spreadsheets...
Isn't the usual assumption that team w is responsible for system W to work, team x for system X, etc? And you can figure out who needs to fix a problem when it comes up?
Yes, but a path of heartache if the interfaces between systems aren't robust.
Say W sends a message to Y but doesn't record the message was sent Y or wait for any sort of ack (say a process that drops a flat file to an FTP server that gets deleted after 7 days). Now someone finds out Y is missing a bunch of things. Who's fixing it and who should be fixing it?