The Zoosk Difference – a developer’s perspective

Much has been written about how management-enforced process kills developer morale and output. I completely agree, based on my personal experience.

I spent five years in a mega-corporation and shake my head in disbelief at the difference — instead of complacency, I’m now in survival mode. I’m now in a world of judicious time use — no more feel-good meetings and processes. From my personal experience, I am going to highlight what works at Zoosk. That I look forward to my two-hour commute to the city on a Monday morning, definitely says something about the culture – that it gets a thing or two right. It keeps me excited as a developer.

A startup not only needs capable engineers, it also needs the teams to work without friction. Allow me to make an analogy to the world of finance: now that the global markets are in a turmoil, more people understand the importance of liquidity. The more readily assets can be bought, sold, transferred, borrowed or loaned, the better the system works. The analogous concept for a software company is responsiveness. It means that engineers get nearly immediate attention from each other, via instant messaging, and get their doubts over design, code and requirements resolved as quickly as possible. It also means that the development environment is highly accessible, code can be quickly browsed, test setups can be tweaked with a few clicks, and any specific build can be generated in minutes. Responsiveness is as critical as liquidity.

In mega-corporations, labels abound: Scrum. Agile. Kanban. Pair programming. Daily stand-ups. However, just because these are well-known practices does not mean they will work for every team in every company. They may not even work at all. Scrum is a nice starting point, but that’s it. Daily stand-ups for regular work cost an unproductive 15 minutes for 4-5 people. Start-ups, on the other hand, naturally exude a fluid, custom workflow. Almost like following a heuristic in an AI algorithm. Try a formula to get work done. If it works, use it and improve it, otherwise try another one. Here at Zoosk, PMs plan products complete with mockups. Leads decide a timeline of 2-week sprints. Developers work on them in a tight collaboration between back-end and front-end. The QA team continually tests new features and performs regressions. Do we need to label part of our process a waterfall? TDD? BDD? Absolutely not. I have a better phrase for it – “Get the job done with what works best.” We code as fast as possible, sprinkle enough comments in between, and write unit tests as much as necessary. We balance quality with speed. We have in-house tools made by dedicated platform developers who continuously improve them. We have a whole bunch of command aliases so even a non-coder QA engineer can check out code and make a build. We have a zero-confusion branching and merging strategy. It is all about utilizing time for the most valuable task at hand. In operating system terms, our process can thus be called Best-value-job-first, or BVJF. While we may sometimes use tools like daily stand-ups or stickies-on-the-wal on a need basis, we aren’t drowning in buzzwords and methodologies, but are instead free to accomplish our tasks quickly. Our process is intentionally lightweight and underdefined by PM so as to create opportunity for discovery and innovation during the development process. We are all clear on the goals/objective, but arriving at an optimal solution requires creativity and flexibility from everyone on the team, all throughout the process.

There is one other important aspect that we enjoy – ownership of projects or parts of it. Without this special attachment, code becomes an assembly-line product, lacking passion and elegance. Think mass-market knock-down furniture versus individually handcrafted artisan pieces. As a side benefit, the code owner can debug and fix defects extremely quickly.

To evolve continuously, a product needs to improve and add usable features as often as possible. Pragmatism rather than perfection works out better. We let out major features twice a month, and push bug fixes once a day, often twice or more. Talk about liquidity! This keeps the workflow nimble, and reduces risks. Imagine this: QA finds a bug, developer fixes it in an hour, and a new build is ready in the next 30 minutes. QA verifies it, and it goes live in another 20 minutes… for tens of millions of users, 25 languages, 60 countries. Cool, ain’t it? This is what we do every single day here at Zoosk.

In short, Zoosk is a developer heaven. If you are a passionate engineer and hate all forms of corporate BS, try working here, or you will never know what you are missing.

-Joy Dutta
Developer, Web Team