I am a self taught programmer with no formal background in computer science. I have spent most of my career as a high school humanities teacher, but I am now considering the possibility of applying for jobs in the computer industry. I have been studying C++ and JUCE intensively for 3 years, and computer audio for much longer. I would say that my coding level is probably upper intermediate. There is still a lot that I don’t know, but I can learn new things fast, and I have reached the point where I am writing efficient and maintainable code. I am looking for some general advice to help me plan this move and see whether it or not it is feasible.
What would a self taught programmer like me need to do in order to have his application be considered by an employer? Would I need to get a degree or certification? What kinds of things should I have in my portfolio in order to be noticed?
Would it be significantly easier for a self-taught programmer to look for a job in a field other than computer audio? I am thinking of audio because I have a passion for it and because it’s what I am familiar with, but I also know that it’s a very specialized field. Does a self-taught programmer stand a chance here, or would it make more sense for me to get good a JavaScript and look for work as a web developer?
I would appreciate any insights people can share, and please be honest. At the moment, I’m mostly just trying to work out how feasible it would be for me to make a career change, and even under the best case scenario, I would not be actively applying for jobs for the next 6-8 months.
So my personal journey has been a bit different but what I’ve learned will probably help you all the same. I’ve been working in digital audio and DSP professionally for about 7 years now but I entered with a hard science and programming background and degrees - although not much DSP work in school.
My advice to you would be that if you have a passion for it, you can absolutely do it. How’s your core programming skills? Object oriented and C++ knowledge? If it’s not great, bone up - plenty of resources to have you up and running in no time.
Next I think Juce is an excellent place to start. Go through their demos to understand the “flow” of digital signals and audio. Then you can go through the demos to learn about how to manipulate samples to do what you want. I would also recommend an audio centric programming book - Will Pirkle wrote a great book I picked up when beginning.
In my work I occasionally conduct interviews. If you are looking for something entry level that you can also learn from, the you can probably get that gig with a small company. C++ familiarity will be paramount and you can learn from the more experienced guys there about the more audio centric stuff - a lot of audio tech companies need guys to program things like UX, refactor, code organization, app maintenance… things like that. Then you’re in the door.
Sorry if this is a bit meandering but point being: bone up in your C++ skills to the point where you’re comfortable showing them off and understand enough about audio programming to get the jist and work around others in the field doing less intensive audio-based dev.
Make sure to communicate your passion for music/audio in any job application, and preferably have some code examples on something like GitHub. I wouldn’t worry too much about qualifications although it will help if you specifically want to do DSP as it tends to be more maths heavy. In all honesty though few places seem to actually teach good coding practices IMO. Contributing to open source projects is also a great thing to do as it will give you some experience of working with other developers and code not written by yourself (most code isn’t at the quality JUCE is!), which sounds like an area you might be lacking in? Another area worth getting familiar with is good source control, commit messages, branching, versioning. Experience with CI and build nodes (try out GitHub actions), creating build scripts, signing, notarisation, DRM. Being familiar with multiple platforms / IDEs, debugging skills, libraries other the JUCE, STL, experience in other languages understanding the pros/cons.
IME the best developers who don’t understand much about the audio industry have a hard time working in this field, it’s quite unique, so they don’t stick around long. On the other hand if you have the a passion for music/audio then you’re more likely to stick around and you can always learn on the job. There are always cases where getting someone who would need to learn on the job more so than others just isn’t appropriate, so if you get turned down from a job don’t take it personally - it also depends on the other candidates who applied, I’ve seen perfectly capable candidates that we’ve had to turn away.
Yes! Although if you can’t get a job to begin with and you do manage to get one somewhere else then that wouldn’t do your career any harm either.
I’ll add that IME it’s often a good 6 months after starting somewhere before you feel fully integrated and understand all the details of the job and can start to really contribute to the code base you are working on (it’s not uncommon that there are several code bases), and that is often true regardless of skill level because every company is different and the code you are working with is often very different. Not to mention all the things surrounding the code, CI, contribution guidelines, agile process, tools, etc.
Thanks for the encouragement and the advice. It’s great to know that there are opportunities out there that I can work towards.
I’m conscious of the fact that programming as a part of a team is very different than programming on your own (which is what I’ve been doing), and it seems that I could learn a lot from this. Contributing to an open source project sounds like a great idea. Can anyone suggest any projects that are accessible to newcomers?
A bit of personal background: I’m working on a large DAW like project right now–this is my passion, and the reason that I got into JUCE. But it’s probably not a great portfolio piece, as it’s huge, idiosyncratic, and years off of being complete. So I was thinking that it might be good to build a couple of smaller demo plugins which I can show off. I’m guessing that a neat, working, easily readable 1000 line project is going to give a better impression than a semi-working 50,000 line project that I struggle to explain to other people, right?
All I mean really is that in my experience people are more likely to struggle if they can’t empathise with the user (although in all fairness this isn’t unique to our field). I’ve found it harder to teach someone about how products work than coding in general. If someone already understands how to use the software they are working on, what its purpose is, why it does what it does etc. then it helps in comprehending the layout of the code, and in understanding what is being asked of you when working with the code. If you’ve never even heard of a DAW or used any audio FX before then I think being asked to add features to a plugin could be quite an ask.
Indeed this isn’t unique to our field. I wouldn’t guess that a programmer working for an insurance company would need a pre-condition of empathy to actuaries Perhaps what makes our field unique in this sense is that among programmers, there are plenty who do have a strong interest in it and this gives them an edge over others who don’t.
But the way I see it, my subjective view is that our field is objectively interesting. So even if a programmer was not exposed to it before, if they’re passionate about what they do, I tend to believe that sooner or later they’ll naturally develop the empathy for the users.
I would suggest that the single-most important thing for your “new” career is to join a functional team that releases product. School or boot-camps generally focuses on projects developed by one person (you), while that is generally not the case in industry. You’re missing the “other half” of software engineering, i.e. QA and eventual release of a product. There is much to be learned from releasing on multiple platforms and with dependency on existing code. So I would suggest you start your new resume by finding a good company with colleagues you can lean on while learning the discipline of developing and releasing commercial products.
Until you’ve written code that is deployed in scale, this may seem unnecessary if not counter intuitive. But I would submit that most successful developers understand the value and necessity of participating in the entire product cycle and preferably something of size.
If you want to be “on your own”, Audio Fx is actually a good place, as you can make small plugins without a lot of dependencies. But as long-term career advice, I think this approach makes it more difficult to build all your skills.
Perhaps you can find some project to work on in the JUCE Jobs section of the forum.
Maybe some project is waiting just for a profile like yours that comes from a non-STEM area for some super innovative/creative idea.
Also, evaluating the proposals there, even if already filled, can give you an example of what is being asked and indirectly would make you realize what skills you need/desire to expand.
Good luck! I’m self taught as well, although I did study electronic music before working in the field.
My 2 cents: whenever you interview for a job, don’t act like the company you are applying to is just another company. Even if it’s a small one, some research on the products made by that company could be well perceived.
Also - and this is what really bothers me every time I interview new candidates - don’t say “yes” when in reality you don’t know the answer. A straight no is sometimes the best option.
A couple of examples (this sort of things really happened):
Do you know GIT?
Yes! I browse projects from their website frequently!
After further discussion, I realised the candidate meant he knew of GitHub, but he didn’t know how to use GIT at all.
Another one:
Do you know GIT?
Yes! But for developing user interfaces I prefer another library.
Yikes.
This said, if you’ve got the passion, I don’t think you’ll have problems in finding something nice.
As others suggested here, the dynamics involved in a company that releases many products are quite different from what a solo developer usually can do. You get larger codebases, sometimes legacy codebases, different problems to solve. Sometimes you really need to think twice before jumping to conclusions and this is not just about developing new features or fixing bugs, but also about choosing the right technologies. But in the end you get to work with very talented people and this is IMO one of the most stimulating pros of this (sorta) niche called audio programming.
Perhaps what makes our field unique in this sense is that among programmers, there are plenty who do have a strong interest in it and this gives them an edge over others who don’t.