What music creators can learn from web developers
- Lauren Sanderson
- June 27, 2016
- read
There are always lessons creators from different disciplines can learn from one another, and in this article AudioJungle Author PhotonicMusic shares how what he learned as a web developer can be useful for most music creators.
When I joined AudioJungle all I had with me was bug spray and a few years’ experience producing techno music. Now, reflecting two years on, what really helped me survive as a music creator is that I spent five years as a developer.
As a programmer, being efficient is the name of the game. That type of work has so many pitfalls, you need to be well organized to achieve anything. And after all, you cannot afford to be slower than the competition. You can’t even afford to be slower than your co-workers.
When I began at the startup I was working for, one of my first tasks was to make a sort of submission form. It took me a week (40 hours) to complete. Our website was evolving constantly and I had to rebuild the form several times. My last attempt took me around 4 hours. With five years of experience I had become ten times faster.
It’s just the repetition of making the same thing over again that made me faster, but also a bunch of new technologies that help optimize your workflow and improve your speed. And through the years I’ve discovered techniques that actually make you faster and more efficient in anything you do.
“I’ve discovered techniques that actually make you faster and better in anything you do.”
Find your personal guru
For the first three years in the startup I worked for, I would get my job done the way I was used to. But when a new person joined our team, everything changed.
He was much more talented than me, a true mastermind with tons of experience. Watching him work was like watching Joe Satriani play guitar: it looked effortless.
When you see someone that good in action, you realize how much room there is for you to improve. Getting knowledge from someone better than you is always the best way to grow.
If you can’t find someone to look up to in your day to day life, you’ll find one on the internet for sure. My favorite sources of inspiration are Derek Sivers and Paul Graham. And when I need something to boost my creativity, I often go to Dave Pensado’s Youtube channel or watch other people making music.
“If you can’t find someone to look up to in in your day to day life, you’ll find one on the internet for sure.”
Spend hours (not minutes) planning
When this new employee joined our company, one of the first things I noticed about him was that he wouldn’t be sitting by his computer all the time. He would spend hours walking around and making notes.
One time, our boss entered the office and said with a bitter smile, “I’m not paying you to walk around all day!” My co-worker returned to his desk and told me, “If you ever see a programmer sitting by their computer all day, fire them!” His point was being that programmers should make plans away from their computers, so they can work faster when they get started.
By walking around and making plans he was actually saving time. It’s better to spend 4 hours planning and get the job done in 8 hours, than spend 20+ hours doing a job without a plan.
I try to take the same approach to making music. Testing ideas in my mind has proved to be very effective for me.
Although it’s fun to jump in and mess around with your equipment until something beautiful comes out, I find this too time consuming. I only have twenty hours a week to work on AudioJungle stuff, so I organize my time carefully. I only start working on a new track once I have a clear plan. I decide what video the new track will fit, what it should sound like in the end, build a structure in my mind, choose the instruments I’ll use, find reference tracks and so on.
This way I minimize the amount of tracks I leave unfinished. When you have a plan, you know the path to the end, so you eventually arrive there. Without a plan it’s easy to get lost and spend hours searching for a way out.
“It’s better to spend 4 hours planning and get the job done in 8 hours, than spend 20+ hours doing a job without a plan.”
Know your good hours
“If a programmer comes to the office before 9 am, fire him!” was another of my co-worker’s rules. He said he had never met a single good programmer who can work early in the morning.
Although I don’t share his enthusiasm on actually firing people that come in early, I agree we all have good and bad hours for working on specific tasks. I know I can’t work on happy ukulele jingles at nighttime. Try and find the hours that work best for you.
Be lazy – prepare to do less work
My co-worker would also occasionally say he was so lazy he could never do the same task twice. Everything he did was organized in modules he could reuse when needed. He was also using pre-written blocks of code called snippets. One hit on the keyboard and Bam! the code is there. Less time typing means more time being creative.
In music production there are no snippets, but there are templates, presets, keyboard shortcuts, etc. Each one of these takes time to prepare and learn but save you time in the long run so you’ll have more of it to actually be creative with.
A fellow Author AdiGold once published a great video on the forums to demonstrate his production workflow. Check it out and see the power of being prepared.
Do research
At the beginning of my programming path, I would often start building something that was already built and available to buy. For example, I spent a week making something I could get for $20 or even for free. (I can already hear my co-worker go crazy: “Fire him!”)
The reason for this was that I had not done any research, so I didn’t know I could actually download the code and go on a 5 day vacation. In the music production business it’s the same. Do your research and get to know what’s already available. What you are trying to achieve might already be available as an instrument plugin or sample pack.
“What you are trying to achieve might already be available as an instrument plugin or a sample pack.”
Rewrite
Programmers often delete their work and build it again from scratch. I use this approach in making music too. I make new versions of the same track in different tempos, with different instruments and different audio mixes.
Sometimes the new version is so bad, it proves the original was good enough to release. Sometimes some parts in the new track are better than the ones in the original – in this case I improve the original. And yes, It has also happened that the old version has sounded more like a demo compared to the new one; a major improvement!
Almost done? Nope. You’re only at the halfway point
My boss never understood why I needed another two days to finish something that was “already done”. Or, so he thought.
Yes, everything was visible on the screen and when we tested it, it seemed to work. But every programmer knows there are tricks to make your boss happy (for a short time) and this was one of them. My code would never be quite done. I would still have hundreds of things I needed to fix that were invisible to others before I could release the new feature.
I hate to admit it but when I do audio work I tend to become my ex-boss in many ways.
Let’s say I’m really productive and make a fresh track in a single day. The next morning it sounds done, it just needs “a few tweaks”, no more than an hour’s worth of work. Eight hours later I’m pulling my hair out; it’s still not done. The next morning, it’s almost done but still needs two more hours of tweaking.
This scenario is so common that it’s pointless to ignore. It seems your project is 90% complete but you’re actually only halfway done. Just being aware of this phenomena can save you a lot of frustration.
It seems you’re at 90% but actually you’re at 50%.
First impressions are everything
I would sometimes design a web page for days and meanwhile forget I’m doing it for other people. When my design was done, my boss would sometimes call others to join him the first time he would use it.
The first 3 seconds always said it all. I don’t know how to describe it but somehow I would already know what everyone was thinking even if they wouldn’t say it. That new searchbox would all of the sudden not seem so perfect anymore or that new tooltip would not be as revolutionary as I had thought minutes earlier.
I would be so busy organizing the visual elements on screen in the days before that I would completely forget that my final product was going to have actual users some day. And that they would make their decision to use it or not in the first three seconds.
With music it’s much the same. I can fall in love with a new track I’ve done, because I’ve gotten used to it after hours, days, even weeks of working on it. But users will decide in seconds whether it’s good or not. It’s absolutely crucial to keep that in mind. It’s always a good idea to get second opinions not just at the end but also in the middle of your working process. You need to accept that you are biased and trust others’ opinions.
Conclusion
These are probably the most important lessons I learned as a developer that can positively influence the way you work when producing music. I’m always striving to get better so I’m very curious what my fellow musicians and AudioJunglers have to add.
Let me know on the forums.
