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.<p>One year you need to use gulp to build, the next babel and an NPM script.<p>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.<p>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.
I wouldn't go about fixing the messages/symptoms, but after "software engineers" doing things wrong.<p>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.<p>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.<p>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.<p>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".<p>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.
Oh and most of the org can only barely abstractly relate to the challenges & difficulties you face.<p>Really good short article. This is valuable like heck & grounds the whole experience, shares & makes known one of it's widest aspects.<p>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.<p>It's not that the engineer is wrong. It's that the engineer is told they are wrong.<p>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.
> P.S. If you enjoyed this article, please follow me on Medium or subscribe via email.<p>Um, what? I honestly appreciated the insight that the article offers, but this was unnecessary.