Emotion-driven development

As many people seem concerned about AI replacing humans and taking away creative and coding jobs, it becomes more important to become clear what essentially makes us human and will never be replaced by machines and algorithms. One obvious aspect is emotion.

Desperation as an inspiration?

I first heard about "rage-driven development" as a joke, making fun of people getting upset at work and (over)prioritizing certain tasks based on their feelings. But that does not necessarily have to be wrong, as long as we are aware of the process and use it as one out of many signals for inspiration and prioritization.

Happiness-driven development might be a more positive extreme either about cherry-picking the most comfortable tasks instead of what needs to be done, or about a team where everyone does what best fits their abilities and preferences (including some who are happy to do anything as long as they get paid a high compensation).

I have been blogging about anger, laziness and anxiety as part of my professional work before. Despite neurodivergent awareness and more developers talking about mental health and actual personal stories beyond "sharing productivity secrets", aggressive feelings still seem stigmatised in the workplace. Maybe that's with good intent. When we want to make work culture more inclusive and welcoming, banning hacker dude grumpiness might seem like an obvious improvement.

As I learned during psychotherapy, hiding or fighting against our feelings can make them stronger and make everything worse by pushing them away instead of being honest (at least to ourselves) and finding productive solutions.

Negative emotions as warning signs

Fear, anxiety and anger can be warning signs telling us that something is wrong and needs to change. Popular advice like taking a break, going out for a walk, exercising physically and talking to others can be adequate and helpful, but it can also be misleading. But in my experience, talking to people in a corporate environment often makes coworkers and team leaders downplay a problem rather than finding a solution that tackles the root cause. Often, they don't have the power to make the appropriate change, or doing so would harm their goals and agreements, like encouraging an employee to quit and find a better job.

"Red flags" 🚩🚩🚩

Some people call it "red flags", but I would rather talk about heuristics. Most things are not 100% good or 100% bad, and people might do the right thing for the wrong reason. Decisions about a job offer can consider many different pros and cons, and it will most likely be some compromise. Red flags are warning signs of possibly unacceptable, uncomfortable or even dangerous aspects. Often, we have to choose "the lesser evil" with a lower red flag count.

Many problems in a workplace are problems of society or even humanity, so we have little power to make a change, but still, some change might be better than no change at all. Getting angry about unjust treatment might give you the energy and courage to speak up, file a complaint, suggest an improvement or talk to that person and tell them you witnessed the incident and feel for them.

Some kinds of emotions are very specific to our work as developers and closely related to developer experience (DevEx or DX, researched by scholars like Fabian Fagerholm at Aalto University).

Emotion as a non-functional requirement

Rage and anger vs. happiness and self-efficacy can be a measurement orthogonal to existing KPIs that we might apply to our strategies and decisions. Like test-driven development puts testing before coding, a rage-driven - or maybe better yet, a happiness-driven development approach would (also) focus on emotions. Some team leaders already try to include that aspect, but let's be honest: how many employees feel safe enough to be really honest, especially as junior developers in times of mass layoffs?

A discussion about tasks and requirements typically includes making sure the specifications are clear and complete enough and that everyone in the team understands them in the same way. Before proceeding with assessing the complexity and possible duration and cost to implement a feature, the team could stop and check if they have a feeling about it. Like planning poker, we could use some common emojis to indicate indifference, excitement, boredom, fear or frustration. Even if the team has no authority to modify the requirements, there are other possible consequences.

Possible consequences indicated by "emotion poker"

• 😐 indifference: no special action required
• 🥱 boredom: take extra care to work properly
• 🥳 excitement: do it properly, showcase results internally
• 😱 fear: increase quality assurance, documentation, time estimation
• 😡 anger: increase estimates, reduce priority (if possible)

In the long run, even little steps like that might tip the scales and make a feature get shipped or ditched. As a freelancer, I have more freedom to decide compared to my previous position as an employee. In the end, many development discussions and dilemmas are always the same, but as we gain experience and respect, our opinion might be taken more seriously by decision-makers.

Beyond day-to-day work in a corporate feature factory, feelings might make a difference and decide if people ignore and work around certain bugs or if they take the time to open an issue, investigate bug details and recommend or develop a better solution.

Control, contain, contribute

Human developers are no robots. But we are no animals either. So we want to use our intellect, not our gut feeling, to be in control at work.

To control and contain our emotions, we must be aware of them and evaluate if they have something relevant to tell us and what it could be exactly. We could also try to assign "time boxes" where we will focus on emotion and intuition while prioritizing our intellectual thinking for the rest of our working day.

We should also assess the positive effect of allowing and integrating emotion. How can we categorize the extra time spent feeling, discussing, and doing extra work? Where does it belong in our time tracking?

There is a blurry line between the specific positive aspects of going beyond explicit requirements and taking time to understand things properly and find real solutions. I am sure that research and development have a business value, and so has an open-minded culture of sharing knowledge. But a lot of this value only proves in the long run. It might be one of the qualities of a true "senior developer", which guarantees a decent income.

Time tracking

Regarding short-time project management, it seems unclear or arbitrary where to write down the extra hours. Some possible time-tracking options include

• ☑️ the current task is a fallback for anything you do
• 🐞 bug fixing is another fallback if your feature tasks have a budget cap
• 🧐 quality assurance, process optimization, workplace organization
• 🍀 inspiration, design, requirements engineering
• 📚 research, education, training

The last one might not seem obvious, but many companies have a universal budget for proactive research and education. Sometimes, we have no idea about possible educational topics, but when we get stuck, frustrated and desperate about an existing solution, it becomes a necessity to learn about possible alternatives.

When we spend or seem to waste extra time instead of "just doing our work", this kind of dedication can pay off:

• 👀 anticipate future requirements
• 💲 optimize processes, thus saving time and money in the future,
• 💎 increase quality, thus preventing errors and complaints
• ☺️ increase customer satisfaction, thus generating revenue
• 🧚 innovate and add something nobody knew what was missing

Benefits and Results that pay off

Here are some specific issues and achievements to prove my point.

• 👥 Changing teams and jobs got me new tasks and new things to learn and meet other people with different perspectives.
• 🏳️‍🌈 Disappointment about missing diversity and inspiration made me attend meetups and conferences and listen to international podcasts, broadening my knowledge and learning new languages*.
• 🐘 Discontent with several other e-commerce solutions made me discover that Shopware 6 is built upon Symfony and how PHP has evolved over the past decade.
• 🎨 JavaScript framework frustration made me learn what modern CSS can do! I did several frontend projects without JS frameworks and got paid well.
• 🚫 Awkwardness about being offline as an IT professional made me investigate how to make a captive sign-in work.
• ⁉️ Confusion about missing best practices made me ask questions on StackOverflow that didn't get downvote-deleted but received helpful answers instead.
• 💣 Dispair of breaking changes in frameworks and third-party software made me embrace quality assurance and a more resilient development style.
• 😒 Sulkiness about medium made me research and discover the practical DEV (this very community)
• 🥱 Bored by day-to-day tasks, I came to embrace productive procrastination and start this blog post series that got me noticed by fellow developers.

I could go on and write a book about my major and minor achievements, but you will find most of them in my past blog posts.

Cleaning up and changing perspective

Finally, when we achieved our goal or we didn't, but we have taken action and consumed the initial emotion and its energy, it's time to take a step back and change perspective before hitting that "send" or "publish" button.

Finding a friendly headline!

Let's take a moment to anticipate the emotions that might arise among our readers and listeners and reconsider how to word our contributions.

I once wrote a post called "a fine Firefox feature". As you might guess from the screenshot, this wasn't the original title I came up with. But how would you feel as a Firefox developer, spending time and effort contributing to open source software and adding features with good intention, when you find out that users express their discontent using swear words against you (or your product)?

Readable, constructive contributions

When I write code, I can take my time and freedom to experiment and write whatever I like into code comments and variable names. It's still not a good idea to ever use swear words or mockery here, as we could forget or be unable to change them later. I think we should strive to create clean and readable high-quality code and anticipate our reviewers' reactions before submitting it for code review.

Likewise, revising our prose content, support questions, and bug tickets is a matter of course to provide understandable, high-quality content to the community. I often start to draft a blog post, a code pen or an issue and wait at least one day before release. This virtue is called "sleep one night over it" in German, similar to "a good idea is still a good idea next Tuesday" (quoted in the Original Hacker's Dictionary, if I remember correctly).

Conclusion

What do you think? Should we take emotions more seriously in our work? Tell us about your experience!