DEV Community

Cover image for The key to developer happiness and how to prevent coding from becoming just another job
Heshie Brody
Heshie Brody

Posted on • Originally published at

The key to developer happiness and how to prevent coding from becoming just another job

This article first appeared here:

Mid Sprint Gloom Day Tuesday

It was a week after sprint planning and I sat at my desk feeling lost and bored. Here I was in my third year in my software developer career feeling overwhelmed and uninspired.

All the pain that motivated me into focusing my career on software development and out of my boring e-commerce job was back but yet as a software developer.

I still remember the moment when at age 14 I double-clicked the Visual basic form editor button and coded my first MessageBox.Show("Hello world"). The invigoration and excitement of seeing a computer execute the code that I just wrote were second to none. Ask every software developer this and they will remember that exact moment as if it happened yesterday.

After experiencing the above I started questioning the creative work industry.

Is it impossible to experience that same feeling of joy when working creatively on my hobby as when doing it as a job?

Will a job always be a job?

Now, for us, as software developers to stay happy, we must stick close to our core motivation which is creation.

The birth of a software developer

As a human our greatest joy comes from creation, making something out of nothing. To many people buying creations built by others is enough to satisfy that need but for some of us who are desperate enough, unless we build something of our own we feel no joy.

This is how we as software developers are born.

Now, for us, as software developers to stay happy, we must stick close to our core motivation which is creation.

All the noise and pressure not related to creating or building stuff moves us further away from what made us join this creative industry in the first place.

To keep all the businessey side of things away from dampening the fun part which is building stuff, it must not feel like a burden to the creator aka the software developer.

As a software developer, when I had the following I was most calm and looked forward to my work:

  • Having my day prepared with a clear list of work assigned
  • Having ample and reasonable time for each task
  • Knowing when my work is considered complete
  • Having my manager in sync instead of pinging me all day in Slack with requests for progress updates.

The greatest pleasure as a software developer is when you are assigned work where you know exactly what the specifications are and what the result should look like.

Being able to knock something out to its completion allows us to no end.

Working off a vague idea or not knowing where to begin or end leads to burnout and boredom since to us as creators there we now have additional baggage around the creation process which turns it into a job and less like a hobby.

The non-manager, manager

Like a boss

Let's be honest, software development is chaotic much like business is chaotic.

For a team to be run efficiently some sort of separation must be placed between the software developers and the business side of things to bring it under control.

This necessary separation is the job of the team lead or engineering manager.

But even with a manager in place, the challenge is still there.

The manager must find the right balance of communication and goal setting with biz dev who wants everything yesterday and the development teams who are running a backlog.

Many times the pressure put on the manager finds its way down to the developers and before you know it your development team is pressured and micro-managed not knowing what to work on first in turn making what we find fun as a hobby the opposite as a job.

We as developers on the other side are too intimidated or shy to communicate our feelings back up and we just accept the workload and pressure as a given. And this is a huge problem since work overload and micromanagement are the greatest causes of burnout and indirection much like that Tuesday I described above.

Finding the perfect manager that can properly lead their team while keeping developer happiness levels high is difficult.
Humans are humans and we succumb to pressure and emotions. Even the greatest leaders sometimes break down and falter.

The key to developer happiness and how to prevent coding from becoming just another job

The great Lao Tzu put it best “A leader is best when people barely know he exists. When his work is done, his aim fulfilled, they will say: we did it ourselves.”

Now, what if I started my Tuesday morning a bit differently that day? As I get to my desk a curated checklist of exactly what I’ll be working on that day is in my inbox. I report to my manager the progress I have been making, and I put aside my timidness and discuss my progress and provide feedback if they assigned too much work to me.

In doing so I would’ve felt mentally at ease knowing that my manager has been updated with my progress and has been communicated with how I feel about the workload.

Also since my goals and expectations are set I now have a clear purpose and goal for that day feeling free to indulge in building in a way that makes me happy.

Now from my manager’s perspective, I have removed their morning overhead and already put them at ease since they now know exactly what I’m working on plus insight on the team progress and efficiency leading to a more relaxed atmosphere and greater developer happiness.

Finding the courage to do so is a game changer.

But do we find the courage?

Do we speak up when we disagree on how something should be done or do we just stay quiet to get done with ‘that’ meeting?

Do we communicate our feelings about the timeline or do we just nod along so as not to be called out as a “non-team player?

Here’s an exercise; now it might not be for everybody and if you’re great at communicating then kudos to you but for those who are not great at communicating [yet] next time you feel something during a meeting; a thought, an insight, a timeline expectation, speak up!

It’ll be tough at first, you’ll feel your body fighting many different forces but carry on, It’s worth it.

People hire you for more than just listening. They want your opinion and thoughts, they want that clarity and insight that your background brings that someone else may not have.

In doing so you will effectively get more comfortable communicating your thoughts and help keep your team in sync while also putting you at ease and giving you the needed clarity to focus on what you love best which is building product.

A win-win! But only if you have the courage.

May the courage be with us.
May the force be with you

"Zigi is your own AI-powered personal assistant, managing your entire dev workflow and handling all your mundane,
Non-programming tasks across multiple apps, so you can focus on code creation and innovation".

Top comments (5)

jonrandy profile image
Jon Randy 🎖️

The greatest pleasure as a software developer is when you are assigned work where you know exactly what the specifications are and what the result should look like

That sounds like my worst nightmare TBH

olavidps profile image

😯 why?

jonrandy profile image
Jon Randy 🎖️ • Edited

Mainly because:

  1. It sounds like donkey work, with little room for creativity, investigation, and problem solving - therefore mostly boring.
  2. You can pretty much guarantee that if someone is 'exactly' sure of the specifications and the output, they're probably not right.
curious_web_addicts profile image
Curious Web Addicts

I cannot say that I agree with this article.
In my opinion, you miss the point here, focusing only on the interaction between the managers and your work. This is basically why Agile practices are developed in the first place. A checklist or better communication will not give me more happiness at work, it is useful for doing a better job, but it will not give me back the creative part of the work, or that first feeling of happiness that you wrote so perfectly in the beginning.
After a couple of years in IT, I haven't been happy for a while and I can't tell how many other colleagues feel the same way and would like to quit this job. I have begun to analyze the reasons and I am thinking that part of the problem is precisely this cage of "take and give" tickets to be estimated and solved, with little or no room for creative improvements to propose, linked to technology stacks often decided by other people who they probably no longer work in the company. Basically we are treated like line workers, putting the same bolt into the same piece every day, with constant pressure to finish on time.

aimerib profile image
Aimeri Baddouh

What you describe here is mostly a failure of management, which is a problem across industries and disciplines of work.
Too much work and too little time with too many competing priorities have very little to do with how happy you are as a DEVELOPER and very much to do with how happy you are as an EMPLOYEE.

Furthermore, just from empiric evidence, there are plenty of developers who are very happy with development being just their job, and loathe the idea of programming on their free time, yet I've known them to be excellent developers nonetheless.
Personally, I do like to have a clearly delimited idea of what the expectations on a given task are, and when they are considered completed, but having that or not doesn't stifle my creativity. A lack of vision and direction from management simply makes me lose faith that my work is actually impacting our users in the right ways.

And one last point, even for an artist, work is work for the majority of working artists. When they work under commission, their creativity is generally not as much into play as their artistic style, and their customers creativity (or sometimes their lack thereof) still overrides the artist's. Very few artists get a chance to be purely creative for work and still get paid for that, and generally only while they are still striving for their first breakthrough. A musician might be able to make their own music based only on their own creativity, but that goes away the moment they sign up with a label. Same goes for illustrators. The few exceptions I can think of are artisans who can spend their time and craft working on creative projects until they find a few that clients really enjoy, then the majority of the artisan's time goes into reproducing the same products over and over.

As a closing note, I do agree with the sentiment that poor leadership will lead to poor happiness at work, but if you still enjoy coding, exercise your creativity in side/hobby projects. Nobody can tell you what or how to do what you love on your own free time.