It's no secret that recruiting good software engineers takes work. Those of us who are trying to do it have probably given a lot of thought to what qualities we want in an engineer, but what about the other perspective — what engineers want from a company? Thinking that way is more helpful and likely to lead to a good match.
To try this theory out, I found an article, Nine Things Developers Want More Than Money, that rang true with my own experience, and I set out to see how our company, Fluencia, stacks up. So while the following assessment may sound like there's some shameless self-promotion going on (there is), it was written in the spirit of investigation: first, to ensure that we are in fact a great place for engineers to work, and second, to work on language for communicating this to candidates.
So how do we do on "Rob’s Criteria for Keeping Your Developers Happy"?
1. Being Set Up to Succeed
This is an easy one, because engineering success is fundamental to the success of our company. Our users expect and deserve a great experience from our products, and compromising on that for any reason just doesn't make sense.
The engineering team partners with our product team to set priorities and schedules. We push hard with our goals, but they're not out of reach, and code quality is built into the schedule. Simply put, shipping unmaintainable, buggy features — no matter how fast — would negate all our hard work and erode the trust our products have built up over the years — so we don't do it!
Big, beautiful monitors and nice laptops are another dimension of being set up to succeed. There's no skimping on tools, if they'll help to get the job done!
2. Having Excellent Management
Chris, our CEO, knows the English-Spanish language-learning domain inside-out.
His talent for problem-solving is legendary. He asks challenging questions, and he wants to be challenged. The first question out of his mouth when addressing a new question or problem is, "What do you think?"
On top of that, he did engineering work for years, so he knows how engineers think — which, personally speaking, was a big factor in choosing to work here. On his own, he scaled SpanishDict into a site capable of serving multiple millions of visitors a month, which means he knows what it takes to do things right.
3. Learning New Things
We never solve the same problem twice. Our team is responsible for two very different projects. One, SpanishDict is a reference website, built for speed, scale, and simplicity of use. The other, Fluencia is a fresh take on solving the age-old problem of language learing via cutting-edge technologies in a responsive single-page app.
Underlying both these endeavors are proven yet fast-evolving technologies such as Node.js, Backbone.js, MongoDB, AWS, and Chef. And as we've learned more about how to use them, we've given talks at local meetups on best practices.
The Node ecosystem in particular moves at the speed of light. We're always on the lookout for new modules and libraries to help us out and enable new features. And as we move into the middle of 2014, we're tackling a new tough challenge: voice recognition.
4. Exercising Creativity and Solving the Right Kind of Problems
As long as language has existed, people have wanted to easily and quickly learn new languages — and it's never been possible. That's the ultimate problem we're out to solve.
Along the way, we're solving lots of particular, individual interesting problems. One of the reasons Fluencia works so well is that it provides tailored feedback when users answer questions incorrectly. Our feedback module applies heuristics that allow it to recognize many kinds of mistakes, determine which rules of the language the user broke and what context they were broken in, and choose a few particular things to emphasize for each response. It's a thorny problem, and we're far from done solving it completely.
In addition, we get to solve interesting problems of scale as our user base continues to grow, and we collect more and more data about how our users use our products. We are in the business of solving users' problems, sometimes before they even know what they are — and by analzying data, we can do that.
The boring, wrong kinds of problems that Rob mentions in his article, such as fixing bugs, patching broken code, and supporting legacy systems, are minimized since we promote code quality and responsibility. The less time we spend on that, the better.
5. Having a Voice
Chris sits about six feet away from the engineering team. He wants to hear from us, whether at our quick daily standups, or via chat and email, or any other way. When something isn't working right — a process, a feature — he's all ears. He takes suggestions and ideas seriously.
The same goes for the rest of the team. Content, marketing: they all talk to and listen to the engineers. On a small, dedicated team, every voice should be heard, because good ideas can come from anywhere.
6. Being Recognized for Hard Work
Our company has a tradition of giving each other cumplidos at our weekly team meetings. Cumplidos can be translated as "compliments", and it can also mean something that is accomplished or fulfilled (as in misión cumplida, or "mission accomplished"). We recognize and cheer each other on for reaching goals, working together, and going above and beyond.
Our greatest recognition may come from our users. At our weekly team meetings, we share a sample of it as well. For example:
Your program is definitely working for me. It's fun, educational and very effective. It's like having my own private tutor...but better. Please, keep up the good work! Thank you for such an excellent method. - Michael
Positive user feedback such as this is truly gratifying!
7. Building Something that Matters
Our company is solving a fundamental problem of communication for SpanishDict's 9 million unique visitors per month and Fluencia's 150K+ users. You don't have to look any further than the feedback to know how meaningful it is to them. Hearing responses like the one above, week after week, helps us to keep in mind the value of the work we do.
Whether it's allowing loved ones to communicate, making it easier to get a job and earn a living, or facilitating travel, we are focused on breaking down the barriers to communication. Ultimately, we're making the world a better place.
8. Building Software without an Act of Congress
We spend as much time coding new features as possible. And we strive to get our new hires and interns writing code for production use as soon as we can. Barriers to building software are something we work to remove, not erect!
Instead of acts of Congress, we discuss new features at meetings every other week, ensuring we understand what the feature includes and what the user experience will be like. We generate a rough estimate of how much effort it will take. And that's it — it goes into the priority queue, and once a developer gets to it, they start to work on it, and see it through to completion and deployment.
We value code quality, so we have extensive automated testing, and all code is reviewed before being merged. Far from being a barrier, this practice lets us move quickly by preventing regression bugs and giving us confidence that our features work as expected. That frees us up to work on — you guessed it — even more new features.
9. Having Few Legacy Constraints
Our backend architectures use Node.js, which didn't even exist until a few years ago, and is now being widely adopted — in fact, by the time you finish this post, another well-known tech company will probably have started using it. Fluencia's front-end uses Backbone.js, which is also only a few years old.
As a rule of thumb, we choose the best tool for the job. We defer upgrading for the sake of it, but when we start working on a new feature that touches old code, we determine what it will take to upgrade, and we make it happen.
So even though SpanishDict has been around since 1999, a very long time by internet standards, nearly all of our codebase is very recent.
All in all, I think Fluenca does pretty well when it comes to Nine Things Developers Want More Than Money. What do you think?
If you need more convincing, here are some posts by interns from the summers of 2013 and 2012 about their experiences. We enjoyed working with them, and I think they enjoyed working with us too!