What about scope?

Audio Plugins
1

This is about scope creep. If I were to apply to work for an existing plug-in company my favorite being JST or NeuralDSP, assuming that I would need to show personal projects that already work as proof of my skills; what kind of a project would be considered way too trivial and what kind of project would be considered way to big for one person to tackle alone? Also assuming that I don’t intentionally invite complexity to my software for the sake of complexity. I’m not going to just name drop multiprogramming concepts in an interview just to sound smart.

2

From my perspective as someone who’s reviewed a lot of code samples from potential employees, I’d say a few points to bear in mind are:

The person reviewing it is probably busy, so a short project that’s easy to navigate is going to be appreciated more than a huge rambling one

What I found myself doing was:

  • Look at the overall structure of what they’ve sent: is it well-named and laid-out sensibly? If it’s a single flat directory full of .cpp files with meaningless abbreviated names, then it immediately goes on the “nope” pile.

  • Quickly check a few of the source files to see what the overall style is like, and to rule out obviously terrible or sloppily presented code. A lot of candidates don’t get past this “sniff test”.

  • Pick out a couple of files to look at in more detail, and skim through, mainly looking for:

    • signs of their experience level. Any common beginner mistakes in there?
    • good naming
    • good use of 3rd party code (which means mainly the std library or juce). Are they using the right classes in sensible ways.
    • too much quirkiness. Everyone tends to develop a few little odd habits where they’ll tend to do certain things in an unusual way. But sometimes you see code that’s too full of weird, non-standard ways of doing standard things, and this is a red flag that this person might be a pain to work with

So TBH it’s mainly about demonstrating you can write lots of code with few red flags in it. Whoever is reviewing the code may end up being the person who code-reviews your actual real work, so you want to show them that this will be a painless process for them.

7 Likes
3

A good start to read and adopt is the juce coding standards, if it comes to code aesthetics and readability.

(…not only if Jules is reviewing, I think it is general a sensible standard :wink: )

4

I think this is the main point to take, as long as you maintain a consistent style that isn’t awful, it shouldn’t matter if that style isn’t the same as your own (if it does matter then that is the least of your problems :joy:), because there are tools that can change the style for you and/or it’s not so difficult to learn a new style if you join a team who’s agreed upon style doesn’t match your own.

Personally I still can’t stomach the function (calls) extra whitespace before the parentheses rule in the JUCE standards. Literally no other large coding standard agrees with this. :joy: But in our small team we both agreed upon the style rules we like, and code we end up having to copy from JUCE we run through clang-tidy and carry on regardless.

1 Like
5

Thanks, Julian I really look up to you. I had a bad habit the last couple years wanting to write device drivers instead of making good use of existing wrappers known to already work. The low-level stuff is neat, but it’s not going to get a plug-in built.

1 Like
6

What worked for me, your experience may vary. Find something that is missing from juce (for me it was a FileSystemWatcher and an efficient way to download on background threads) and create a juce module that has the features you need. Eventually others will need your module, and they’ll see your code and it can turn into a job.

A full featured synth or effect with a beautiful GUI might be a bit much for an example project. But a simple synth or effect that has one unique feature might be worth it.

3 Likes
7

Yes, I made similar experiences as @RolandMR. Publishing some of my JUCE modules on GitHub that others found useful generated a few good contacts. And presenting an open source JUCE module that already gained a bunch of GitHub stars from the community might be a good piece of example work to share in a job application.

8

Thanks! I honestly love making modules of all kinds I just don’t know how to do it in the JUCE context, so I’ll have to do some research. I also asked some buddies of mine if they want me to make plugins for them, but keep it simple and writing maintainable and extendable code.