It Could Always Have Been Done Better! (In Hindsight)

Written by dieswaytoofast | Published 2019/10/29
Tech Story Tags: software-engineering | product-management | toxic-culture | hindsight | software-development | personal-improvement | latest-tech-stories | software-engineering-metrics

TLDR Software Engineering is rife with situations where there is ample scope for back-stabbing - especially when dealing with people who don't understand the complexities of the field. The art of teasing out requirements is really that - an art. If you see it, and have agency, fix it. Or leave it. But, whatever you do, don't play the game... You need to learn to recognize the above behavior - it's the sure sign of a toxic person or culture. It's not a game-changer.via the TL;DR App

This is one of the hardest lessons to learn in the Software Engineering business. It doesn't matter how good you were at doing something, or how much you accomplished, there will always be something that didn't go right.

There was that feature you hacked to meet a deadline, or that bug that took 4 days to diagnose, or that weird edge-case that flaked out, or ...
And even when you didn't have any of those issues, there are the things you didn't do - the features you didn't put in, or the customer types that you didn't support, or whatever.
The thing is, so much of what we do in this field is utterly obvious in hindsight. You can try to obsessively piece together customer requirements, but it's only when you're actually shipping do you discover the difference between what the customer wants and what they need (not to mention, what they're willing to pay for!). And the same goes for bugs - if you knew where they were up-front, they wouldn't exist in the first place!
That said, for folks who aren't in Software Engineering, this is really not so obvious. Take requirements for example. Given a large enough group of folks who are not on the product team, at least one of them is sure to have thought of the particular requirement that you didn't get right.
"Of course you should have made it green - I've always known it should be green!"
The issue, of course, being that this person quite likely would have got everything else wrong. And the art of teasing out requirements is really that - an art.
The point here is that, more so than in most other fields, software engineering is rife with situations where there is ample scope for back-stabbing - especially when dealing with people who don't quite understand the complexities of the field.
Need to take out your competitors out for that hotly contested promotion? Read up on Julius Caesar Act 3 Scene 2, and Brutus the heck out of your competition using the above. Everything they did can be - oh so subtly - Swift-Boated.
"It's amazing that we got that app into production, isn't it? And it's already generating revenue! Too bad that we didn't get it in a few weeks earlier, but hey, Alice will eventually figure out how to be better at time-management!"

"Looks like Bob is going to meet his deadline, but Boy Howdy, it would have been so much more smooth-sailing if he hadn't spent that week tracking down a bug. Which ended up being nothing more than a missing semi-colon!"

And so on...
OK, I'm not suggesting that you actually do the above. But, but, you need to learn to recognize the above behavior - it's the sure sign of a toxic person or culture. If you see it, and have agency, fix it. Or leave.
But, whatever you do, don't play the game...

Written by dieswaytoofast | That Tall Bald Indian Guy...
Published by HackerNoon on 2019/10/29