@ireneista @multioculate @emma I would argue that the problems these systems are solving are complicated, and so any system that solves them must also be complicated. To give just one example, one cannot understand software that flies an airplane with...

Demi Marie Obenour

@ireneista @multioculate @emma I would argue that the problems these systems are solving are complicated, and so any system that solves them must also be complicated. To give just one example, one cannot understand software that flies an airplane without first understanding how airplanes fly!

I suspect hiring difficulties are due to one of a few factors:

Not being willing to train software developers in the problem domain and/or being unwilling to train domain experts in software development. It is not realistic to expect someone to already have training in both software development and aerospace engineering. Employers need to be willing to train people in one or both of these.
Problem domains that are not attractive to potential employees. Lots of people simply are not interested in working in the finance or aerospace sectors, either because they do not find them interesting or because of personal ethics. (Remember that aerospace and the military have a lot of overlap.)
Employers are not willing to pay competitive salaries.

Irenes (many)

@alwayscurious @multioculate @emma we know somebody who has worked on the air traffic control system (the same one that was the subject of the failed multi-billion-dollar attempt to rewrite it from scratch)

Irenes (many)

@alwayscurious @multioculate @emma he was extremely well paid so it's not (3). we agree that (1) and (2) are relevant but at some point you also have to look at the amount of effort that's been spent on it, and trust the assessment of the people who've worked in it, and say that the code itself is at least partly to blame

Irenes (many)

@alwayscurious @multioculate @emma we specifically pointed out the overlap between aviation and military up-thread, so, thank you for pointing it out back to us we guess, but it doesn't make us feel like you're listening

Irenes (many)

@alwayscurious @multioculate @emma also the goal here, just to once again re-state the thing we started from, is to have code that can be put away and not a thing that needs active maintenance for a long period of time, decades

and then dusted off and maintained again when new needs arise that force that

Irenes (many)

@alwayscurious @multioculate @emma that fundamentally excludes large scale ongoing training programs as a solution

Demi Marie Obenour

@ireneista @multioculate @emma Do you mean training on the specific codebase, or training on software development and/or the underlying problem domain?

Irenes (many)

@alwayscurious @multioculate @emma the codebase and problem domain

Demi Marie Obenour

@ireneista @multioculate @emma Codebase I agree with, but how can someone jump into code without first understanding the problem the code is trying to solve?

My first programming internship involved writing simulations, and my main problem was not the programming (even though I was a very new programmer), but rather insufficient knowledge of numerical algorithms and the underlying problem domain.

Irenes (many)

@alwayscurious @multioculate @emma that's why this is an unsolved problem! we're trying to describe the problem, as a step towards the world maybe someday having a solution to it

Irenes (many)

@alwayscurious @multioculate @emma you know that thing where, when you try to turn an explanation from a textbook into code, you immediately discover a ton of decisions the textbook glossed over?

Irenes (many)

@alwayscurious @multioculate @emma doesn't matter what field the text is in; the knowledge that experts in the field have is still a strict subset of the knowledge that is needed to formalize it into code. it's honestly kind of impressive that code for difficult science and engineering tasks gets written at all.

Demi Marie Obenour

@ireneista @multioculate @emma Can you explain fruther? I haven’t dealt with textbooks since college, so my memory of that isn’t too great.

Irenes (many)

@alwayscurious @multioculate @emma for example, we once attempted to write some speech synthesis code that relied on doing an inverse Fourier transform, based on math references that described the Fourier algorithms and on a couple textbooks in phonetics (which is a branch of linguistics)

Irenes (many)

@alwayscurious @multioculate @emma a thing we discovered is that the math people are very clear that a Fourier transform of a sound-like signal involves some sampling function that's applied in a sliding window over time, and that you get considerably different-looking spectrograms from the same signal depending on that function

Irenes (many)

@alwayscurious @multioculate @emma the linguistics people don't seem to know that's a thing at all. like we're sure if you talked to grad students who'd have to do it, they'd tell you oh you have to put about 15 milliseconds as the parameter into the sound editing program or you don't get a spectrogram that looks good and shows the formants clearly.... but the textbooks and even research papers in that field don't discuss it at all

Asta [AMP]

@[email protected] @[email protected] @[email protected] @[email protected] One of my biggest blockers from ever finishing a certain paper (other than my ADHD, which, in hindsight, was a huge one) was the amount of detail I felt it needed vs. the amount of detail the corresponding author thought it needed. To wit, I don't think the methods would have been reproducible without explicit detail and the corresponding author always just wanted that section shorter. It was a nightmare.

Asta [AMP]

@[email protected] @[email protected] @[email protected] @[email protected] I'm also reminded of the difficulties I had implementing a method from a paper I was a co-author on (because I supplied data, and was also part of the editing process)...