this post was submitted on 10 Feb 2024
1391 points (98.1% liked)
Microblog Memes
5754 readers
2841 users here now
A place to share screenshots of Microblog posts, whether from Mastodon, tumblr, ~~Twitter~~ X, KBin, Threads or elsewhere.
Created as an evolution of White People Twitter and other tweet-capture subreddits.
Rules:
- Please put at least one word relevant to the post in the post title.
- Be nice.
- No advertising, brand promotion or guerilla marketing.
- Posters are encouraged to link to the toot or tweet etc in the description of posts.
Related communities:
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
This is also generally true for software engineers.
In my own experience, the difficulty is that you basically have to teach someone software engineering before they even kind of understand what youre saying before they believe you.
Which is basically 99% of people, especially in a work setting.
The very rare 1% of people will usually give up and go, well, youre the expert, probably you know what youre talking about.
The rest will be angered by their own dunning-krueger effect and/or ego and be abusive.
EDIT: This is 100% true when talking to a video game player, unless they are somehow also a programmer.
There are 0 exceptions to the category of someone who has only played video games. None of them anything about programming, and they will be more angry and rude than the general public.
The art in this is to know/guess where you have to dumb down things how far to get your point across.
For example, I'm often explaining Kubernetes to business people as "a layer on top of our servers, so we can define which apps we want to run and how, k8s then sorts itself out, how exactly to deploy everything". That's wildly simplified, but usually gives them a rough idea of what they're dealing with.
I've had to endure a coworker explaining k8s by starting with manifests, then switching over to volume claims, finally something about ingresses... He was talking to a guy from a government office, whose job it was to do administrative tasks. That guy had no idea what my coworker was talking about and left the meeting more confused than before.
Unfortunately for myself at least I seem to be faaar too autistic to be able to do this.
I am good at writing code, writing queries, solving interoperability problems, analyzing large data sets, and I can even manage to present reports in ways that are statistically valid but summarized to narratives.
What I cannot handle is my bosses bosses boss insisting I use an entirely new software I have never used before to solve a problem that we can already solve with software we have, for a problem that would not be a problem if she had listened to either my boss, my bosses boss, or the leads of all the other teams who have all been saying the same thing for months.
This kind of thing has happened to me at every single tech role I have ever worked.
Logic means nothing. What matters is the high up thinks something is 'neat' and theres no way they can be told, directly, or indirectly, that they have no clue what theyre talking about.
Maybe it's lame and old fashioned... but I've had success with explaining things with flow charts. Make some boxes to represent APIs, make some cylinders to represent DBs, etc, draw some lines to show how things connect. Pick some pretty colours, managers like that. Think more on the lines of explaining to a child how things work.
Once you have that picture you can point to things on it and say "we can add some code here, and a few tables here to provide the feature." You can add more boxes and lines on another version to represent the new software they want to add to the flow, and they will be able to visualize how that makes things more complicated. Then talk in terms of time to maintain this new software that makes the process more complex... "My estimate is it will take 200 hours to implement this and an additional 100 hours per year to maintain it." Yeah, it's mostly going to be numbers you pulled out of your ass, but if your boss is the kind of person that pulls ideas from their ass, they really can't dispute what you're saying. And they will hopefully be capable of converting the time estimate into a money estimate themself and they will come to the conclusion on their own that your preferred approach is better on their own.
The trick is to make them think it was their idea.
Those are different problems, though. Or at least only slightly related.
Business people operate on a different plane. Not necessarily a bad one, just different. Not, that there's no stupidity involved, but if you dig a bit (they're often surprisingly incapable of expressing their own motivation), you'll often find that in their reality tunnel, their decision makes total sense. And from their perspective, we are just a bunch of semi-autistic nerds who can't even explain what they're doing and cost ungodly amounts of money. If we complain about a decision in technical terms, they don't understand that.
So, assuming the decision makers in your organization don't act in bad faith or are really just stupid, try to think from their standpoint. If that helps you, think about it like an RPG. If you're talking to a character whose entire motivation is money, you wouldn't choose the dialog option about what a great warrior your paladin is.
For business people the relevant metrics are costs, time to market, risks. If they come around with a new software that is objectively bad, you don't argue that you can already do that, you only need to deploy the Operator with the AbstractBusinessFactoryBuilder configured differently, etc etc. Instead, you argue, that this poses immense risks, since you'd have to redo a lot of work, which of course costs a lot of resources. Also, you could argue, that such a vendor lock in poses immense risks, since you can't really extend the software. And so on.
Don't start as being the hysterical autist they see us as. Try to ask, why this is relevant. What exactly do they think is the benefit? If they can't explain it to you, say that. You're the expert, after all. And then, give the software a chance, so your objections have a basis.
Finally, don't forget the magic of the word "no". There's a good chance, that simply downright rejecting work on a change/project will actually make some people think.
This is very true. I work with a lot of software developers and most of them have huge egos. I started in a business role and moved to software engineer and am really gold at not letting my ego take over. I always take criticism and try to get better.
In my experience I have learned as much as I could from other software engineers and rarely had problems with them.
Of course their absolutely are software engineers with huge egos.
In my own experience at least, I worked with many who were very humble, and higher ups walked all over us and abused us and refused to listen to huge problems with plans we were instructed to carry out, and then we were blamed for not doing the thing that would never work in the first place.
As an engineer who plays games, it drives me fucking nuts how much influence forum users and streamers are given when it comes to ongoing game design. It very clearly has ruined many games, and there are times when the user base just need to be ignored. Or at least managed better.
If you can't explain a concept to a five year old, then you're not an expert on that concept.