Wouldn’t it be nice if all developers were just happy at work? The chance of that occurring is close to zero, however, there are a few things that actually make developers happy.

Clear Requirements

You would think that the client would be ecstatic to provide you with exactly what they want. That’s never the case. Either they don’t know how to gather their thoughts correctly or they don’t want to pay for an expert to guide them through. What you receive most of the time is a loose collection of notes, scribbles, power point slides, and excel sheets. The business analyst takes that information and speaks with the client a few times before passing the “open to interpretation” requirements to the UI/UX team. The team does their best to create the designs. After a couple of iterations, the client agrees with the proposed designs. The designs are not complete and it’s up to the developer to use their best judgment. Sometimes the client is happy and that’s about as much as you can hope for.

That’s the best case scenario in most companies. More often than not, companies don’t have a qualified BA or a BA at all; the project manager handles both roles. The client is busy any time that requirements gathering is needed but demands progress to be shown. They refuse to pay for HiFi designs and believe that developers should know what they want by looking at the few LoFi designs. They ask for constant revisions and believe they n shouldn’t pay for them. The developers get burnt out and finally quit.

On a rare few occasions the stars align and you start working for the perfect company. There is a clear distinction between the BA and the PM and both positions are rockstars. The client understands that the requirements gathering process is a paid process and they have the funding for it. HiFi designs are created with all possible application states. The developer receives their tasks, perfectly planned and linked to the various confluence pages. They enter nirvana. Even when the client proposes changes, the timeline shifts according to those changes.

Although this is something that every company strives for, only a few will ever achieve it. When a developer gets a taste of it, he or she will become spoiled quickly. Have fun listening to “the way it should be done” for the rest of your life.

Proper Project Manager

Nontechnical project managers do not belong in the development world. Nothing frustrates a developer more than asking their PM for assistance and the PM not understanding a thing. The developer is pulled into most client meetings because the PM does not know how to explain it to the client. Tasks don’t make sense and the Jira board is always a mess. I’m not talking about lazy Project Managers. These individuals try hard and yet they make everything a mess.

The perfect PM is one that was a previous developer with soft skills. They understand how developers work and they can communicate with the client with ease. The best ones had a taste of requirements gathering perfection and are on a mission to replicate that environment, where everything runs smoothly.

A great relationship between the developer and the project manager is essential for project success.

Healthy Work Environment

A poor work/life balance will cause developers to run for the hills. There is unfortunately an expectation that developers should be available at all times of the day to answer any questions that may arise. When developers go on vacation, they frequently hear, “make sure to keep you phone on you.” They’re expected to check Slack/Teams no matter what they’re doing or whether they have time off or not. Deployments are done during off-hours so as not to affect the user. This is usually at 9:00pm or later. I don’t know how this started or why developers choose to tolerate it, but it’s not something that I would personally put up with. All individuals want to finish their work and disconnect; developers are no different.

A work environment without toxic coworkers is a dream workplace, however, there’s always at least one. I’m not sure who hurt this person growing up, but he/she is on a mission to make everyone’s lives miserable. They strive on stress and will look for every opportunity to create it. These stress-creators sometimes mask their toxicity with a smile, but you know who they are. It’s the person that everyone always avoids.

There are others that sabotage progress because they can’t get out of the “good old days.” These are the ones that you have to look out for like a hawk. Make sure that their toxicity doesn’t infect the rest of the team. Once it does, it’s difficult to break that mindset. Developers will feel unhappy and they won’t know exactly why.

Final Words

It doesn’t take much to make developers happy. It’s the same stuff that makes all employees happy. Clear job requirements, skilled coworkers, and a lack of stress-creators. Is that really too much to ask?