I've been told it's an odd jump to go from a degree in audio engineering to working in software, and I suppose that's a take that makes sense initially. I've mulled on this for a while though, and I've made the determination that the degree I hold is in fact uniquely suitable for the field of of software engineering, and I'll aim to make my case here.
My entire case hinges on the patchbay. You mean that thing in the wall with all the cables hanging out of it? Yeah that. For those who don't know, a patchbay is actually a very simple device. Essentially, it tracks a logical flow of a signal through the steps it needs to take to reach its endpoint, while allowing an operator to interrupt that flow if needed. Put plainly, if I want to record an audio signal, a microphone needs to capture that signal and output it to the input of a mic preamp for amplification. Then that mic preamp, after amplifying the signal, needs to output it to the input of the recording console or interface, which then outputs audio to the input of a recorder (gross oversimplification), which then outputs to the input of a fader, which then outputs to the input of the speakers, which then ultimately outputs to the input of our ears. There can be more or different steps depending on the hardware being used, but what I hope to make clear is the relationship between outputs and inputs here. The patchbay, if configured properly, makes these default connections for us without any intervention, but let's say we want to process our microphone signal through a compressor and record that. Well, the patchbay makes it trivially easy to take the output that's coming out of the mic preamp and reroute it to the input of a compressor. We can then take the output of that compressor and reroute it to the input of our recorder. By taking a problem (sound needs to be recorded and played back) and breaking it down into its component steps, we're able to much more effectively plan out solutions, and implement much more creativity in the execution of those solutions. The patchbay is a brilliant way to visualize this type of problem solving, and it's one of the most valuable skills I learned during my degree.
And it's not just sound recording, the patchbay can be used to visualize pretty much any problem. Take the problem of making dinner, for example. I have a steak in a package, and I need to turn it into dinner that I can eat. Well first, the package needs to output the raw steak to the input of the hot frying pan. Once the pan is finished processing the steak, it outputs to the input of a board where the steak can rest. Once that's finished, the output ends up at the input of the plate, and then we're done. Now that's all well and good as a sane default flow, but this isn't just any steak, this is a nice ribeye steak that deserves a proper reverse sear. Well, we can take the output of the package and patch it into the input of a warm oven, the output of which will then be patched to the input of the pan, and the process continues. Nice summer day (I wish!)? The output of the oven can be patched to the input of the grill outside, which can then output directly to the board for resting, skipping the default step of the pan entirely. The possibilities are endless (within reason, don't patch the raw steak directly to the plate unless you really trust your butcher)!
Now, is this principle always applied in software development? No, not at all (looking at you, methods with 3000 lines that do hundreds of unrelated things). But it's a principle I've carried forward throughout my entire post-college life, and I like to think it's informed the design of the software I'm writing now in positive ways. Or maybe I just wanted an excuse to ramble on about recording, steak, and that one time I wrote a semi-automated studio booker at school. I dunno, that's all for you to decide.