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!
Top comments (11)
Absolutely. I've been thinking about writing about this very topic for a while. The famous "leave your emotions at that door" is one of the worst and most naive things to say but that a lot people believe is possible. It's funny how most companies, from tiny startups to huge corporations, want their employees to use reason only and shame them for displaying emotions, when the very reason why they're in business is the FEELING that investors had that they could be profitable, as well as the FEELING of their customers about their products and brand. I a thousand percent advocate for welcoming and encouraging emotions, especially to address and even prevent conflict and drama in the work place. Great article! I'd love to help spread EDD, Emotion Driven Development. Let me know how I can help!
Ironically, employees are expected to show emotions during hiring interviews, like a lot of excitement for their future employer and some negative feelings that they somehow managed so that they can leave them at that door to behave like a robot when hired.
I didn't intend to start a movement. Maybe we should, but thinking and talking about emotions and which role the already play even in pseudo-rational decision making will already make a change.
Well like you said, you should've thought of the emotions you'd cause on people with your article! Now it's too late, the movement has started! π
Joke aside, I agree. Raising awareness and talking openly about emotions is a great start. This has been my approach on the teams that I had the opportunity to lead and mentor and I will continue doing that. Welcoming emotions is fundamental to making people feel heard and accepted, and the way to building and maintaining trust.
I want to credit a related and inspirational talk by Dr. Emily Anhalt that I heard at beyond Tellerrand Conference this year: The 7 Traits of an Emotionally Fit Leader.
Related reading: CSS is Emotional: A Series About Code, Feelings, and the Space Between
CSS is Emotional: A Series About Code, Feelings, and the Space Between
EIO β’ Emmanuel Imolorhe γ» Nov 24
You have a valid point here!
I don't comprehend why we need to exhibit charisma, enthusiasm, expressiveness, emotional awareness, and complexity in our interviews, only to be expected to transform into unfeeling, efficient work machines the moment we secure the job.
It's utterly perplexing because if I was selected based on my personality, why on earth do they want me to completely erase it the moment I clock in?
I'm grateful that my current company doesn't operate that way, but unfortunately, it's still the reality for many people :(
There is only one start date that I remember, February 14, 1977, when I started employment with NCR E&M-Columbia. What I didn't realize was that I'd meet my future wife at work. I enjoyed my work, and my coworkers. She was laid off in November 1990, and I was laid off in November 1991. My first layoff hit me hard. I did use a bit of "Far Side" comic strip humor. There is a United States of America Code of Conduct for the flag, 4 U.S. Code Β§ 8 - Respect for flag. One section of the code is to never display the flag upside down, except in dire distress, so I turned my nameplate outside my cube upside down. That is a trend that I have done in other layoffs.
Creating a resume from almost 14 years was difficult with the various projects that I worked on.
As a defensive mechanism, after that first layoff, I don't get emotionally attached to my future employers.
After my 1991 layoff, my wife and I practiced "paycheck diversity".
Time is given equally to everyone, so it cannot be managed.
In fact, the way to manage time is to manage one's emotions.
I also think that leadership is the skill of managing other people's emotions.
I have accidentally been applying happiness-driven development this whole time by working on projects that I find incredibly interesting and have a lot of fun working on
Me too!
I need to work on managing my emotions in this area, cos once I start feeling not so good about the project, motivation drops, productivity drops and I might get dropped π