100%. even dead simple things. Going from a team where you're an idiot if you use more than one return function per method, to a team where you're an idiot if you don't return early to stop execution.
One year you need to use gulp to build, the next babel and an NPM script.
And most entrenched software engineers that rise through their companies because they simply haven't shifted around, are so sure that their way is the best way.
But still, it's better than any other job. And I'm convinced the humility you learn from programming is very valuable, if you can stomach it.
It's better than other jobs b because there is very little actual authority over what is considered correct. If software was more entrenched in academia then the story might have been very different.
As an aside, your return statement example made me chuckle. That's the exact kind of thing some people get their panties in a bunch over. But then you switch to another team and it's cool. lol I've experienced that kind of thing so many times. It's as if the field is designed so that you're constantly gaslit into thinking you're incompetent.
I find stuff like that is never an issue when you're coding with experienced contractors. But when you're coding with juniors they can get really militant over stuff like that
I wouldn't go about fixing the messages/symptoms, but after "software engineers" doing things wrong.
Also if it's really "always" one might consider the option that one goes about things the wrong way, and especially not implying that someone is mean spirited as the phrase "you are not good enough" seems to imply.
It could also hint at things like thinking software engineering is about quickly copy pasting stuff from Stack Overflow or tutorials and somehow making it "run", which at least isn't the only way to go about software engineering and in my opinion certainly isn't the best.
Given that the trend is to essentially create more of these (see Rust, Typescript, hinters, linters, etc.) to create better software I think more feedback is the way to go, because then one doesn't end up being scared that things will go wrong at the worst time.
As a software engineer I think feedback should be embraced, especially when it is direct, because it makes it more helpful than some vague "it's down", "feature X doesn't work".
I also don't think it's good to complain about neutral feedback, because the idea of "nice" error messages sounds scary, annoying and like it a waste of valuable time that people in general tend to have too little of. I'd rather spend that time NOT dealing with an error.
I saw a team of data scientists brought to their knees by
pip --user install some-package
because these packages would infect all of their venv's, including anaconda.
When they were just screwing around with Jupyter notebooks to make reports they did OK but when they were trying to create a factory that produced models that could be transplanted into production systems it was a constant struggle and we discovered so many ways you could screw up the configuration of a Python system such as having the output configured to UTF-8 and throwing errors when an invalid character is printed.
Engineering would say "just don't print uncontrolled text" but we had nearly 100 dependencies and some of them would print.
Engineering would say "just use Docker" but we found plenty of times people used Docker images that had broken Pythons, just now there is another layer of indirection to make problems harder to debug.
Then there are all the little things like
0.1 + 0.2 - 0.3 = 5.551115123125783e-17
The route to reliable quality is to make it easier to do things right than to do things wrong.
Oh and most of the org can only barely abstractly relate to the challenges & difficulties you face.
Really good short article. This is valuable like heck & grounds the whole experience, shares & makes known one of it's widest aspects.
Conversely all the challenges are part of why coding is fun too. Faced with a million rough & pointy ways for things to go wrong, for them to be difficult or to come together poorly, we often eek out something reasonably elegant and capable. We overcome. We make.
> It’s staggering how much negative feedback software engineers get from software (compiler, CI, tests), people, and the whole organization. And positive feedback often comes once a month when things miraculously go well.
It's not that the engineer is wrong. It's that the engineer is told they are wrong.
Positive feedback for doing things well, which go unnoticed, is unfortunately common. We could all train ourselves to recognize the small successes and thank each other when they occur.
One of the reasons I loved programming at first is the non-judgemental, objective, feedback from my interpreter or compiler. Also, that I could try to fix a coding issue and if I did not, nothing physical broke. I am so clumsy physically that I truly appreciated that the software profession existed in time for my professional growth.
One year you need to use gulp to build, the next babel and an NPM script.
And most entrenched software engineers that rise through their companies because they simply haven't shifted around, are so sure that their way is the best way.
But still, it's better than any other job. And I'm convinced the humility you learn from programming is very valuable, if you can stomach it.