Hate to say it but I do not think so, and this is not a criticism of these people, it just is because based on my experience working with software developers, they are subject to pretty much the same psychological thinking traps as anyone else and sometimes even more so because of the confidence bias we give to skills in domains like engineering and overextend our confidence that these skills allow us to understand everything else

scholar.social/@Iris/112910605

But I think it could have an effect. It would be interesting to parse that effect out into what it really is. I would believe that people who have experienced a lot of systems failures might find media claims less credible. But media skepticism that's rooted in a sense of superiority to everyone else is going to be dangerous because it's going to lead you to not be skeptical of your own beliefs a lot of the time. Skepticism that's rooted in a more scientific process seems far more resilient.

That being said a value I often see as one that software engineering aspires to is a very scientific approach to the world, with observation and evidence over time, even though I have my doubts about whether software *cultures* reward people for doing that. It's never one thing of course. I think one really cool factor that's leaped out lately is whether people feel empowered or disempowered when it comes to the technology around them. One might be surprised this is not a given for developers

@grimalkina Alternative hypothesis (kindof a synthesis): in my experience working a dayjob where the majority of my coworkers are computer engineers, they most certainly do not understand on any fundamental level what computers can or cannot do, and neither the education provided to engineers nor the practice and culture of computer programming seems to have them exercise anything remotely akin to the scientific process. This was made especially clear to me in how my one coworker who this wasn't true of had a degree in computer *science*, rather than engineering.
Follow

@keithzg @grimalkina

Did you ever observe them debugging something they were unfamiliar with? (I'm asking because this is the ~everyday software engineer activity that requires IMO most evidence weighing, pruning of hypotheses, and choosing what evidence to try gathering.)

BTW I'm somewhat surprised by the ratio of compsci/compeng-graduated colleagues you have, but that might be just a bias caused by my personal circumstances.

@robryk @grimalkina I have seen them floundering when doing that, though most of them don't have to very often because many have been working on their little silos of our overall codebase for literally decades.

One silo has seen turnover over the years I've worked here and I have seen people just outright give up on fixing things on that (our most core!) program and resort to writing entirely new programs to replace that functionality rather than puzzle out how to fix up the existing code. *That* often results in stuff that can't actually be shipped until I puzzle out what the actual dependencies are because they haven't considered shipping to any machine that doesn't have their exact dev environment set up.

Several of them don't believe in documenting code, or are terse to the point of essentially the same result.

My boss, who is also the owner of the company, has an engineering degree (from before there was generally such a thing as a computer engineering degree!) which probably contributes to the degree skew. We also took advantage of engineering practicum programs from the university just down the road (though we are no longer doing that for reasons I have not been made privy to), and I think literally all the programmers and testers who haven't worked here for decades first came to us through that.
Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.