Writing automated tests isn’t just about ensuring the code you’re writing right now is solid. Once again, Slack is a great tool here, integrating closely with Github to make the code we commit visible to everybody within seconds.Īnd secondly, by enabling more formal code reviews and pair programming opportunities whenever possible.Īpart from directly increasing overall code quality, this also all has the advantage of exposing more of our backend infrastructure to our team, which is a great learning opportunity too. We try to learn from this at Mixlr in a couple of ways.įirstly, by encouraging our team to review each other’s code on an adhoc basis. Keep the code visible.Īs Linus’s Law states, enough eyeballs make all bugs shallow. And everybody, including our users, benefits from that in the long-run. These are questions we try to ask of every commit, because if we can create code that’s easy to read, then we’ve probably built something that’s easy to maintain too.

When writing Ruby, is that early return statement triggered by a dangling conditional worth sacrificing a clear, fully-indented code path that can be understood at a glance?Ĭan that variable really not be named a little more descriptively? Why write a nested ternary statement, when you can space that logic out onto half-a-dozen lines and make it pulse with clarity and simplicity? Once again, there’s no simple way to achieve this. Once again, Mixlr’s ultra-low ratio of developers to active users makes this principle crucial for us.Ĭode is nothing if it isn’t readable - and readable by others, not just the original developer. We make careful use of tools like Google Analytics, Mixpanel, Browserstack and Airbrake to be sure that won’t happen.īut with these safeguards in place, we can allow our community to benefit from new features quickly - even if they’re not quite pixel perfect yet.Īnd with early release comes early dialog too, which helps us finetune and improve a feature more efficiently than we ever could in a closed QA environment. This doesn’t mean that allowing a user’s experience to regress is acceptable, of course. When it comes to release, we always favour pushing new code as early as possible. This helps us to focus on improvements that our users really want, and avoid wasted development time. We start at the product design phase, defining clear user stories at the earliest possible opportunity, and then stick with them throughout the development cycle.

To keep everybody satisfied, we have little choice but to aim to release features and improvements frequently, despite our small team size. The Mixlr community has over 45,000 monthly active broadcasters and millions of monthly listeners. This is the first rule of the Agile manifesto, but arguably the most important - and even more so when you’ve got a small team, and a big user base. Here are five principles that we’ve found particularly valuable over that time. Since we started Mixlr over five years ago, we’ve experimented with a lot of different approaches to development. If you enjoy this post, you might enjoy being part of our team too. 5 development principles we strive for at Mixlr.

Don tony mixlr