Developer Grief

It’s hard enough to interview and hire good software engineers. It’s even harder to keep them engaged, productive, and willing to stick around. There are definitely ups and downs to any job, and being a software engineer is no different. Sometimes, the downs get overwhelming, leading to great engineers looking for work elsewhere.

In the ten years I’ve worked in software, I’ve seen several engineers come and go. When they go, it’s often because they’ve found themselves unhappy in their current role. Maintaining “developer happiness” is usually a concern for managers, but the responsibility falls on the entire team.

Here are some common reasons for developer grief and some of the best ways I’ve seen them addressed.

“I’m in nothing but meetings all day”

As engineers of software, we expect to spend most of our time writing code. Yes, meetings are essential for the dispersal of information and gathering of ideas, but we truly value our heads-down, programming time. There’s a balance to be found, but if the pendulum swings too far into meeting-land, we quickly lose interest or feel like we’ve lost our way.

To combat this, I’ve seen engineers mute email notifications or snooze Slack for a couple of hours to prevent interruptions throughout the day. I’ve seen others go so far as adding blocks of “Do Not Disturb” events to their calendars. A very effective strategy is to get the team together and establish a “Work From Home” or “No Meeting” day (both, if we’re lucky). This empowers everyone to focus and get things done, uninterrupted.

The important thing is to be explicit about setting aside time to work on code. Meetings have explicit times and locations, so should programming time!

“All I ever work on are bugs”

Engineers love building new features. It’s an opportunity to take ownership of a problem and come up with creative ways to solve it. However, we’re also expected to keep things up and running, and that means squashing bugs. Debugging and fixing old code isn’t always thrilling. It’s draining, making us feel like we aren’t adding value.

It’s not easy to break out of the bug-trap, but one of my favorite ways is to be more engaged during the early stages of feature development. Being more involved in the product life cycle gives engineers insight into potential feature-work, and a chance solidify our role in its implementation early on. We don’t want to intrude too much on product development or the facilitation of work, but some involvement isn’t too much to ask.

Bugs are an inevitable part of the job, but being more engaged in the early stages of the product development life cycle is one of the best ways to jump on new feature-work.

“I haven’t learned anything new”

Continuous growth and development is extremely important to engineers. In the software industry, technologies change very quickly, and we don’t want to be left behind. Constantly learning is essential to our careers and mental well-being. If we don’t take time to explore and learn, we may find ourselves too complacent, uninspired, or maybe even obsolete.

One way to encourage growth is by enabling engineers to learn from other engineers. This can come in the form of tech-talks, local meetups, or attending conferences. While individuals can take it upon themselves to attend, it’s even better when the whole team is involved. Conferences, especially, are great ways to expose engineers to a breadth of technologies, but they also serve as team-building, morale-boosting opportunities.

Resources may vary, but it’s important to invest some level of time or money into the education of engineering teams. An exercised brain is a happy and productive one!

“It feels like my work is meaningless”

Most engineers are perfectly fine with their job as long as the pay is good, and there’s absolutely nothing wrong with that. However, I’ve seen many great engineers leave well-paying jobs, just to escape feeling like a tiny cog in a big, corporate machine.

Nobody wants to feel invisible, but if work continues to go unnoticed or unacknowledged, it’s bound to happen. Why spend time and energy on something if it seems like nobody cares about it? A “good job” or “thanks for doing that” goes a long way in making someone feel like he or she made an impact. And recognition doesn’t always have to be a pat on the back. Criticism, when constructive, is also a form of acknowledgement. It doesn’t always feel good, but it means someone actually cares about our growth as engineers.

I’m not suggesting we give participation trophies to everyone, but acknowledging work, big or small, gives engineers a sense of accomplishment. And we all want to feel accomplished.

Conclusion

Happiness is a highly subjective term and trying to make every engineer happy is a lost cause. However, making a little effort in preventing too much developer grief is important for keeping great engineering teams together.

What are some other ways of achieving developer happiness? Let me know in the comments!