The best perk to give software engineers

Hint: it isn’t’s tools.

Tools on wood table

Tech companies today spend a lot of time thinking about how to recruit and retain the best engineering talent. This is one of the reasons why perks—like daily catered meals, free snacks, and onsite game rooms—have become the subject of countless online slideshows about the tech industry.

But if software engineering is one of your core competencies, these perks are nowhere near the most important things that you can be doing to improve the day-to-day experience of your most valuable employees. Instead, I believe that the key to engineer happiness is productivity: making it easier for developers to do their jobs and work on solving hard problems, without letting anything else get in their way.

After talking to dozens of companies from startup or a 100-year-old corporations about ways to make their software engineering efforts scale, I believe that there are a handful of steps that can be recommended across the board. The suggestions below go a long way to addressing key pain points for your developers, which is one of the best “perks” that you can provide them.

Automate away the annoying stuff

Every time an engineer has to fight against your dev environment to do their job, you have to assume that the same problem is going to crop up again in the future. One year ago, LinkedIn kicked off a long-term effort to identify software development speedbumps and come up with solutions. What this translates to is a laser focus on identifying problems, and a commitment to not just solving them, but doing so at scale. In the modern software engineering organization, “at scale” is synonymous with “automation.”

There are no limits to the number of small integration problems and checklist items that can sabotage a release or eat up extra cycles, breeding frustration and wasting your employees’ time. That’s why one of the best investments that companies can make is to automate as much process as possible at every stage in the lifecycle of a piece of software.

In the development stage at LinkedIn, we automate the process of working across software repos through multiproducts, a logical abstraction we created for development and delivery of all kinds of software. There’s nothing more frustrating than writing a new piece of code only to find that it conflicts with an older program, so we explicitly declare and version any dependencies to take the ambiguity out of this process. Testing and deployment, especially across multiple platforms, are notorious for creating bad engineering experiences. If a shortcoming in your testing tools is making releases fall behind schedule, you need to not only solve problem, but solve it at scale. That could lead to building your own solutions. The common denominator in automating all of these processes is that the extra work you do on the front end saves you many headaches down the road.

Kill branch-based development as soon as possible

Perhaps the most surprising area where we’ve worked to eliminate tediousness from our developers’ lives is in branch vs. trunk development. Many people like the idea of branch development because it allows you to write code while being isolated from the main trunk of the codebase. It allows you to avoid conflicts by removing yourself from the finished product. But ask any of these orgs about “merge hell” and you’ll get a knowing look. Too often, time saved developing code in isolation is lost (with interested) due to problems when it’s time to merge the branch back into the trunk.

Instead, we prefer to develop off of the main trunk for all of our software releases. In most cases, branch development simply kicks the can down the road when it comes to integration challenges. This helps improve our developers’ experience by streamlining their build process and reducing unnecessary and time-consuming conflicts between branches and trunks.

Customer impact = number of bugs * time customer sees a bug

The above equation is something we live by at LinkedIn, which is a focus on fast deployment and recovery over eliminating bugs. While we realize that customer impact is at the center of every development team, we try to create a positive environment for our engineers by making it OK to make a mistake and easy to fix those mistakes quickly. Many companies measure success by the number of bugs caught in their code, with the least amount of bugs possible being ideal. To do this, they exhaustively test code before it is deployed, which has the effect of lengthening the time between deployments.

At LinkedIn, we embrace a different philosophy as part of our “members first” approach to doing business. Because we have full control of the frequency of updates, rollbacks, and the way that our product presents information to members, we instead focus on minimizing customer impact or mean time to recovery (MTTR). In other words, our focus is on how many bugs affect our members and how long the bugs affect them for. The key to this philosophy is focusing on rollbacks over fix-forward solutions and allowing for self-service deployment. Our engineers move quickly to deploy code, and sometimes that means a bug may sneak in, but they’re able to quickly roll back to a previous, bug-free version while the problem is sorted out. As a result, our engineers are less afraid of pushing new features, making us faster to roll out changes to our members, which is important in today’s fast-paced and competitive landscape. By contrast, in a system that uses fix-forward solutions and doesn’t have self-service deployment, bugs can survive until an engineer with deployment privileges is able to create a solution, making bugs more serious and daunting, and slowing the pace of development.

Act like an owner

Last but not least, we try to make our developers happy by encouraging them to act like an owner. This mantra is one of our core values at LinkedIn. It captures the idea that engineers should feel a personal stake of ownership in the products they create, which both empowers them and encourages them to focus on quality craftsmanship in the code they write.

Not only does this allow the developers the opportunity to really test their skills, but it also results in the best possible product for the company. It’s much more pleasant to devote time to a project you can truly take pride in, and we want our employees to feel that way about their work at the company.

You can’t fix what you can’t measure

As mentioned earlier, we are a data driven company and use regular surveys, polls, and interviews to identify pain points and quality of life improvements for our engineers. Our goal is make sure we are always approaching problems head-on and committing to fixing them.

Software engineers are smart people, and they know it. That’s why they want to spend their time coming up with creative solutions to hard engineering problems—not wasting hours wading through tedious processes or buggy systems. I always say that I know I’m doing my job right if the developers start complaining about the food, because that means the important parts of their job are going well.

Achieving all of the things I have laid out in this article is anything but simple, but you want our your employees to do their best work possible, why wouldn’t you do everything in your power to facilitate that? Once you get the important stuff right, you can concentrate on the extra perks like food and ping pong tables.

Copyright © 2017 IDG Communications, Inc.

How to choose a low-code development platform