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)!
This paradigm can easily (and should) be applied to software development. Especially when dealing with something as rigid and literal as a computer, everything can be broken down into pairs of outputs over inputs. This is what makes the UNIX command line so brilliant; the idea of piping the output of one command to the input of another in a long chain is exactly what a patchbay is doing. As an anecdote and an aside, this paradigm allowed me to write software before I even knew how to write software. So ok, story time. In school, we had a ridiculous system for booking time in the recording studios. Open time slots for the next day would open for booking at 6:30pm the evening prior, and at that point it was first-come-first-served. Everyone in the department would log in at exactly 6:30, the booking site would take forever to load in, and whoever's request happened to get served first would get the time (and everyone else would get screwed with a 4-6am timeslot). Then one fateful day, I had the bright idea to do a view source on the booking form page, and I quickly realized that I could apply the patchbay principle (I had no idea what I was looking at). I noticed that when you would click on a timeslot on the calendar, it would take the data associated with that timeslot (output) and use them to fill in a hidden form on the page (input, see what I'm getting at here?). The submit button would then take the data from the form (output), and send them to the booking office (input). If I could patch into the process somewhere, I could set myself up at quite an advantage, but where would I patch in? Well, longest part of the process was waiting for the calendar to load in. The hidden form would load nearly immediately, but the calendar was in an iframe with a bunch of Javascript running, so that could take seconds to load if the server was being worked hard (always), so if I could patch into the input of the form, I'd be able to skip over the entire calendar loading process. I got right to work writing a (very gross and poorly organized) Perl script (why Perl?) that would ask the user's desired timeslot and then output the Javascript one-liner to paste into the browser's address bar at exactly 6:30:03 (wouldn't want to look like a bot), which would in one step fill in the hidden form and submit, thus allowing me a nearly 100% success-rate booking any studio time I wanted. Was this a 100% ethical use of my time? I'll take that one to confession. Is this a great example of the patchbay principle at work? Absolutely.
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.