Reverting unhappiness

Being happy isn't something I hear of often in developer circles. Developers mostly complain about stuff that's already in place. And talk dreamily of new things that haven't yet proven as boring and buggy as the previous new things.

The legacy you hate was once the shiny new dream of someone else. But dreaming about things that's not (yet) legacy can't fill a workday or pay the bills.

What about being happy with what you're doing right here, right now?

Why you care

What does science have to say on being happy? In the research carried out by Daniel Graziotin et al there is an interesting line in the discussion of the results: "Happy developers appear to be more focused, have higher performance on problem-solving, higher mental energy, higher skills, and to learn better."

This is echoed in the book by Shawn Achor called the happiness advantage - people who are happy have higher levels of dopamine and serotonin. This turns up the learning centers of our brains.

It makes it easier to make new connections, think more creatively and be skilled at complex analysis and problem solving. The very bread and butter of your software developer career: working memory, problem solving and learning ability.

Augmented by such a mundane thing as feeling happy about what you do.

Unhappiness

What, then, happens in the opposite state of being happy: miserable (or unhappy if you don't like dramatic words as much as I do). How about this encouraging list from the same research paper?

"Unhappiness takes its toll in terms of low focus, inadequate performance, reduction of skills, fatigue, and problems with decision-making. Such consequences hit directly at the core of the software development activity, as it is inherently intellectual."

The same bread and butter: working memory, creativity and learning capacity takes a hit. That paints a clear picture: get happy or suffer as a programmer because of it. But that leaves us none the wiser.

How do you become happier as a programmer?

What causes unhappiness?

The same authors of the research did another survey of some 2000 GitHub developers to find out what causes unhappiness. Here's the top 10 causes of misery listed with the frequency the answer appeared:

Being stuck in problem solving (186)
Time pressure (152)
Bad code quality and coding practice (107)
Under-performing colleague (71)
Feel inadequate with work (63)
Mundane or repetitive task (60)
Unexplained broken code (57)
Bad decision making (42)
Imposed limitation on development (40)
Personal issues (39)

The study notes that "We also expected the majority of the causes to be related to human aspects and relationships. However, most of them came from technical factors related to the artifact (software product, tests, requirements and design document, architecture, etc.) and the process."

Software developers are much more likely to be unhappy with code and imposed limitations. No big surprise here. You didn't get into this because you're a people person.

The Zorro circle

What's the underlying theme of all the points listed above? It's about not being in control. It's about having the outside world dictate how you should work, how fast you do your work, how many corners you should cut, whom you should measure up to, how much magic you should pull out of your sleeve.

The funny thing is that it's not even about how much control you have. It's how much control you believe you have. The people who think their actions matter are significantly happier. And if nothing else - doing something will have an impact at some point - thus proving that you could actually influence the situation.

Shawn Achor cutely defines this as the Zorro circle in the happiness advantage. The things that are in your (perceived) control. Things you perceive to have some influence over. This circle should be kept very small in the beginning.

Only once you've started to work on things inside this circle and gained some sense of autonomy and self-worth can you expand the circle a bit and start again.

All the small things

The first thing you should take back and put into your zorro circle is the small things that makes your day more enjoyable. If you're miserable and under tight deadlines, chances are that you've stopped doing these. Having breaks is among the first to go.

There's a dangerous notion that hunkering down and sweating it out leads to being more productive and by extension happier. Culture loves to romanticize this image especially in start-up circles. Burning the midnight oil. And it's wrong.

Small shots of happiness during the day - and they can come from anything that you enjoy - have been proven to significantly raise your creativity, working memory and learning abilities. Yup.

These are the first things you can take back control over. Have breaks. Socialize with someone. Go for a short walk. Watch some funny clips. Small but by no means trivial things.

Anything to put a smile on your tired worn face. Treat this part as important as the actual work. It's laying the groundwork for awesome things to happen.

Then go back and do genius stuff.

Expanding the circle

Now that there are glimpses of happiness during the day, what's next? Slowly, ever slowly, start working on antidotes to the list that makes you unhappy. Since you are not me - and that is something right there you can be happy about - these are my collection of things I'm doing and have done to believe I have some control over the world. These are listed in order of small to bigger circles.

Rig the game - Stolen from podcaster Tim Ferriss is the approach to play a game where you are winning. Make a list of things you want done by the end of that day. Make that list so short and easy that you can only win. Once the list is done anything else you get done is a tasty bonus. Suddenly you are setting the definition of a good day's worth of work and not the outside world.

Be methodical - When things feel drawn out and you're stuck: have a process of some kind in place and iterate on that process. A great example is when problem solving. It's a process that can be learned and improved upon. You can't force the actual solution but you can very actively do ground work that will make it happen faster. Suddenly with a process in place you are dictating what counts as progress.

The same goes for some piece of code you can't understand. Be methodical. Start with the smallest piece that you do understand. Then slowly expand outwards. This eases the feeling of being stuck for me. I'm doing something, no matter how small, and that's moving forward. Take a moment to look back at where you came from and what you've learned.

Make small improvements - Lots of the points related to bad or broken code. Guess what? You can fix that. Not all at once. But a small part of it right now. And yet another small part of it tomorrow. The greatest programmers I've ever worked with did just that. They dug in and improved the code others complained about. Until there was nothing left to complain about. Suddenly you're controlling what parts of the code that suck and what parts that no longer suck.

Make POCs and skunk work - If the outside world gives you stupid limitations then prove them wrong. With working code, show how it can be done in a better way. It's easy for someone else to downplay ideas. But with working code much less so. Now the other side has to come up with better working code to prove you wrong. Suddenly you're eloquently showcasing your point of why this is a better way.

Be fearless - You'll never grow and progress as a developer if you stay with what you know. Growth happens outside your comfort zone. Try as often as possible to take on new tasks where you know next to nothing. Some of the best programmers I've ever worked with did just this. They routinely took on things where they knew nothing. Until they knew most of it and then moved on. Suddenly you're exploring new directions where exciting things might happen.

Become a teacher - This is the only people point in the list. Teaching and becoming a mentor is a great way of knowing your material in depth. There's even a methodology for it: the Feynman technique where you are imagining explaining the topic to a five year old. Do this as much as you can - it's way harder than it sounds to be clear, concise while stating the general idea in simple terms. Not only will you become the go-to guy but people will start listening to what you say. Suddenly.

The big pic

But what if what you want isn't actually what you need? In his seminal paper you and your research by Richard Hamming he notes that less than optimal working conditions produce the most outstanding results. And conversely when scientists get what they think they need: a nice corner office with a view, staff, secretary and a laboratory their creativity and by extension their productivity plummets.

Seeing things as obstacles can either mean that they are immovable and you have to accept them. Or it can mean that you have to get creative and work through it, around it, under it, over it, whatever. In the book Obstacle is the way Ryan Holiday illustrates a number of individuals that lived the credo that the world is far more malleable than we perceive it to be.

Obstacles are there for you to try your hands at, get a little more skilled at handling before you move on to the next. Being stuck with an unsolvable problem in a stupid framework in a mess of legacy code is maybe what you need. Not what you want, but what you need. Roll up your sleeves and get busy.

Hitting obstacles and pushing through them is another way of feeling satisfied. Flip what's limiting you into an asset. Courage and persistence atrophy. Keep them well toned and in shape.

Have a log of the obstacles you've conquered so far. When you feel unhappy / stuck / limited go look at that list. You've probably managed far worse things than what's currently stopping you. Take a moment to recharge your confidence in your abilities.

No means no

It should be so painfully obvious that it needs stating anyway: all of this still means accepting no abuse, bullying or boundaries not respected. If so, report it and promptly leave. There is more code to complain over now than at any previous point in history.