DEV Community: Daragh Byrne

The magical powers of REST

Daragh Byrne — Sat, 24 Apr 2021 02:41:40 +0000

Software development is demanding sometimes.

There are endless tasks to get done. Often they have deadlines attached. Usually, there are people who will be happy or sad depending on the outcome of the task.

Work takes up a huge part of our lives, and can be a source of joy and meaning.

But it can be draining.

(first published on codingmindfully.com)

There is often the sense of falling behind – that the to-do list will remain endless, forever.

It can be tempting to solve this by “doing more” – putting in extra hours, working weekends and so on. I’ve fallen victim to this temptation myself.

But over the years I’ve had a hunch that I’m actually more effective if I do less. I’ve experimented with my working routines, the amount of rest and exercise I get and so on.

I have some personal evidence that I’m at my best when well-rested.

(you might have worked out by now I'm not talking about REST with respect to HTTP APIs...)

It’s counterintuitive, but taking the foot off the gas every so often can actually lead you to be more effective when you are actually working.

And finally, I’ve found a book that makes the argument better than I ever could.

Rest – why you get more done when you work less by Alex Soojun-Kim Pang.

Rest is a survey of creative, productive and influential humans throughout history.

Think Jefferson, Dickens, Churchill, Scott Adams – people whose impact and output have been significant.

It’s a treasure trove of “life-hacks” of these characters.

The author analyses the working lives of these men and women. He proposes a list of things they mostly had in common when approaching their working lives

Four hours of creative work – many influential, productive figures organised their day so that the greatest body of their creative work occupied about four hours. For example, the author J.G. Ballard described his routine as “two hours in the late morning, two in the early afternoon followed by a walk along the river”. You might think that four hours doesn’t sound like a lot, but (a) it applies to the creative side of work (b) if you examine your own day honestly, you might find that you only actually do around this amount in any event (it’s often true for me).
Morning routine – this is the section of the argument that I had most trouble with. The book says that these figures often had a well-established morning routine. For example, Scott Adams (of Dilbert fame) would often get straight to work at 5am after a coffee. And many other creators would get to work at a particular time. Which I think is the real argument here – pick a time, and work at that time. For me, I’m aware that my energy cycle allows for better output between 10am and 12pm, and again between 4pm and 6pm, so I try to schedule around that for programming work in particular.
Walk – the author outlines a fair bit of scientific evidence that walking stimulates creativity. He quotes the philosopher Keirkegaard, who said “I have walked myself into my best thoughts” – something that tallies with my personal experience.
Nap – napping is one of my life skills. I’ve trained my body to be able to rest for 20 minutes and wake again, through practice. It’s been a game changer for those times when I’m all out of energy. This chapter continues in the vein of the previous one, in detailing examples from history and scientific evidence. Winston Churchill kept a bed in 10 Downing Street during the war, and used it to nap every day!
Stop – there is strong evidence that mind wandering – just sitting and thinking about nothing in particular, giving your mind free rein to go where it wants – is conducive to productivity and creativity. Athletes and concert pianists alike know the value of knowing when to stop (typically around the time your mind is telling you to push through). Of course, if you do find it hard to sit with your own thoughts, there is always meditation…
Sleep – so much has been written about sleep and this book just re-emphasises it.

Why it's hard to rest

The cultural context that we all operate in can make it difficult to accept the necessity of rest.

We’re so hard-wired to believe that there’s a linear relationship between “quantity of work” and output that it can be hard to accept that the relationship might be non-linear. The idea of rest has, sadly, become counter-intuitive.

How about you? What’s your take on this? How does rest show up in your life? Could you do more? Less? What impact does it have? I’d love to hear more in the comments.

A short guided meditation to relax into the weekend

Daragh Byrne — Sat, 03 Oct 2020 03:09:48 +0000

It's a long weekend here in Australia. I've just had an intense period of coding - Python hitting DynamoDB with a React front end, thanks for asking.

I'm determined to make the most of my weekend. I feel like I need to recover, so I won't code.

Anyone who follows me knows I use meditation to ease these transitions. I recorded this session that I delivered to my colleagues yesterday - I hope it will be useful for you!

(I'm giving free guided meditations weekly at the moment - if you want to register, hit me up at daragh at codingmindfully dot com and I'll add you to the list. Or you can find out more on my Facebook page).

My online meditation course for developers is open

Daragh Byrne — Wed, 27 May 2020 09:42:57 +0000

Beautiful humans of Dev.

Many of you have read my articles on meditation for software developers.

Like this one:

Article No Longer Available

Or this series:

Article No Longer Available

Launch day

I have an online course in meditation for software developers. It's a great way to develop or refine your practice.

It takes four weeks.

It's available here for $47 US.

(Please let me know if price is an obstacle).

The Mindful Developer - Course Signup

Let me know if you'd like to know more about it before commiting. I'm happy to answer your questions below!

Photo by Daniel Mingook Kim on Unsplash

25 ways mindfulness and meditation help in my career as a software developer

Daragh Byrne — Sat, 16 May 2020 01:18:58 +0000

A lot of people ask me how they can directly apply meditation itself, or what they learn through meditation (a.k.a. mindfulness or self-awareness) in their life as a software developer. I thought about it for a bit and came up with 25 ways pretty quickly. I’m sure there are more!

(First published at CodingMindfully.com)

Prepare for my day. I don’t know about you, but my mind quite often kicks into gear around 15 seconds after I wake up. I’m filled with thoughts of the day ahead – all the failing tests from yesterday, the pressure to deliver a feature today, which sometimes it dips into anxiety. As soon as I notice this happening, I can see that it’s time to “clear the decks”. 10 minutes of meditation in the morning helps the mind settle, and gets the day started from a calm place – which is great when I know that there’s a busy day ahead!
Helps me manage my stress cycle to keep it healthy. As we rise to the various challenges of our day, our stress response can be activated many times. Pesky bugs, demands from our team/school/whatever, constant Slack messages – they all kick your nervous system into gear. If you’re not careful, you can enter an unhealthy stress cycle, which often ends up in burnout. Mindfulness helps me by (a) helping me recognise where I am in my stress cycle (b) gives me tools to actively manage my stress levels. It’s a superpower!
Maintain presence in my interactions with others. Mindfulness is a capacity for presence. Software development is a game of relationships and interactions as much as it is about code. Applying mindfulness in-the-moment allows me to be more present with the people I am aiming to help – team, clients, other stakeholders. I can notice the nuance of expression, pick up on moods, and so on that I might miss otherwise. Which helps to…
Makes me a better listener. Through meditation I’ve trained my mind to recognise when I’m NOT listening, – especially to notice when I’m preparing my response rather than hearing someone’s words (hands up if you do this?). I can then chose to refocus on what that person is saying, helping them feel heard, and also helping me understand them better!
Recognise when I’m off track – just because I meditate doesn’t mean I’ve got laser guided focus all the time and never get off track. I’ve flicked to my browser three times while writing this article for example! What mindfulness does allow me to do is recognise those moments where my mind has flickered elsewhere (this is essentially what meditation is – training your mind to recognise its own distraction and refocus). I can “course-correct” much more easily than I used to and I attribute this 100% to mindfulness.
Recognise when I’m in an emotional state that isn’t helping me code right now. We are emotional creatures, and coding has its own spectrum of the feels. Because mindfulness helps me be more self-aware, I’m able to identify that I’m in an unhelpful emotional state at that time, and that act of recognition allows me to decide what the best way forward is (take a break, have a conversation with someone, seek support)
Especially frustration! I have no scientific basis for this but I reckon frustration is part of most programmer’s lives on a very regular basis! Looking at a piece of code, thinking it should be working and having no idea why not… literally every day!
Have overall better emotional health – being able to name my emotional state through applying mindfulness allows me to be able to regulate myself, meaning I’m less prone to extremes in the first place (they still happen from time to time, I’m not a robot!)
Remember to apply “beginner’s mind” when I’m stuck – an important concept in meditation is “beginner’s mind” – to show up to the present moment and face it as it is, without preconceptions about how it “should” be. This can help me see the bigger picture. Specifically as a programmer it helps me to…
Challenge my own assumptions about a piece of code. When dealing with code, we are forever building mental models – of the world we are trying to mimic in our code, of the code itself and how it works. Often when we are stuck with a solution it’s because one of the assumptions in our model is wrong – there’s a piece of information that we haven’t seen or acknowledged. Awareness of these assumptions through mindfulness, and application of “beginner’s mind” helps us challenge our own models.
Recognise – and deal with – my own inner critic. There is an inner voice in each of our minds that tell us we’re not good enough in some way. There are good reasons for its existence – read more about it here.
Take pride in my achievements. It’s very easy to look at the world as being “all problems” – in fact, it’s the default setting for our brains. However, most of us experience joy, satisfaction, flow and other attractive emotional states at some point. Being mindfully aware of when these states are present allows us to “take in the good” of life, to fully appreciate them. For example, the success of having a pull request accepted, or the moment a customer successfully uses your code in production – both moments to stop and allow yourself some pride and pleasure.
Keeps me in tune with my values. Because mindfulness allows me to notice and name my emotional state, I often have some insight into whether a particular circumstance is contributing. I know when something feels “off” because it clashes with my values, which allows me to reconsider my involvement. I can say no at that point if I need to.
Recognise when I’m feeling intimidated by the achievements of others. I’ve spoken with countless developers who feel like they are the worst dev in the room, in particular compared with the achievements of others. It’s that pesky “comparing mind”. I have mindfulness based strategies for dealing with that.
Know when it’s time to step away from the keyboard. Mindfulness allows me to recognise “stuckness”, which is often a sign I need to take a break – which as any good dev knows is when the problem always gets solved, right?
Meditation is often when I’m at my most creative, coming up with solutions to all my problems when I’m trying to focus on my breath/body… I have notepads with lines of code from immediately after meditation sessions.
This also helps my learning. I was feeling pretty frustrated trying to learn something about concurrent programming in Java just last night. I (mindfully) recognised that I was struggling and stepped away for a while. And of course, the solution just appeared in my mind…
I’m less judgemental when I discover confusing code. This is a big one for me. In the past, it’s been easy to throw up my hands in frustration when I discovered a piece of code I thought was stupid. Now, having gained insight into how difficult it is for me to write something decent, I’m much more sympathetic to the struggles of others who came before me. I’m sure they were doing their best.
Appreciate the beauty of a fine piece of code. This is a form of taking in the good – allowing myself to appreciate acts of genius on the rare occasion I stumble across it.
Decompress at the end of the day. A long day coding is effortful and expends a lot of energy. I need ways to wind down and restore. A twenty minute body scan meditation often works for me.
Prevents me from becoming burned out. Nobody wants to be burned out. Practicing mindfulness can help to keep it at bay.
Helps me recover when I do end up on the burnout spectrum. Everybody ends up burned out a little from time to time (or even a lot). Mediation is part of my recovery toolkit.
Be more aware of where on the Flow Cycle. I wrote all about flow here. There’s a cycle to it – Struggle, Release, Flow, Recover… mindfulness allows me to know where I’m at on that cycle.
My productivity is generally higher when I meditate compared with when I don’t.
And, in general, I sleep better when I’m meditating, and feel less tired.

So there you go. If you’d like to know more about any of these, reach out. If you’d like to start applying these, pick one! Have a go at it for a week, and see what comes out of it! Let me know how it goes…

I’ll be launching my course again in a week or so. It covers a lot of this material. Stay tuned!

The Inner Game of Software Development

Daragh Byrne — Fri, 17 Apr 2020 22:36:24 +0000

This came out of a thread of tweets. I composed last night.

Like many of you, I've been reflecting a lot on why I do the things I do (particularly my blog).

For me, it's about helping programmer's with their Inner Game.

What do I mean by that?

Here are my notes on the Inner Game of Software Development.

To be a successful software developer you are playing an outer game and an inner game. The outer game deals with the world around you, the inner game deals with the world inside you. They are related, and affect one another, but there is a boundary.
The outer game is relational and circumstantial. It means hiting targets, identifying/delivering value, producing code and documentation, making use of opportunity, building relationships, influencing the world. It's how most people measure success, which is valid but incomplete.
The outer game is important, but you only have so much control over it. The COVID crisis is an excellent example of how the outer game can quickly change. None of us were to know the precise details of when, where, and how exactly a pandemic would strike.
The inner game is a game played in your own mind. It's about responses to circumstances, mental state, capacity to focus, mental and physical energy, mindset, attitude, inner dialog, self awareness, life satisfaction, emotional intelligence and other personal psychological qualities.
The outer game is often emphasized while training to be a software developer. The outer game skills are important and necessary for success, but they are not the full story. Learning about the inner game - and how to play it - will amplify your experience of being a developer in subtle and not-so-subtle ways.
The foundational skill of the inner game is self-awareness. This is the ability to identify the aspects of your internal experience - in particular, physical, emotional and cognitive structures and experiences - that interfere with your ability to write code. A short course in mindfulness meditation is an excellent way of developing your self awareness. I teach this, ask me about it.
Self-awareness is like a superpower for a programmer. It allows you to debug yourself, by giving you a clear picture of your internal state and processes at a given time, which allows you to take appropriate action to modify that state if required (immediately, or over a period of time) to more easily achieve your outer game goals.
Managing your inner dialog is another inner game skill that allows you to moderate and harness self-doubt, impostor syndrome, frustration and other forms of negative self talk that can hold you back when creating software.
Being aware of the voice (or voices) in yourinner dialog, and learning how to successfully relate to it - especially your inner critic - will bring great dividends in all areas of your coding life.
Energy management is a crucial inner game skill that helps you manage stress, prevent burnout and make sure you can keep coding in a sustainable manner. In my experience, programming culture does not, promote sensible personal energy management techniques.
This includes promoting a reliance on caffeine, long hours/all night culture, poor diet and so on. A few changes to your physical well-being can have hugely positive effects on your energy levels. A burnt out programmer is no good to anyone.
Emotional intelligence is a particular form of self-awareness that focuses on how your emotional state, and your understanding of the emotional state of others, affects your experience and performance. It's particularly useful in the context of development team and stakeholder relationships. It's the interface between the inner and the outer games.
Obviously this is influenced by your own particular neurodiversity, but there are ways for many of us to develop this aspect of the game. Again, meditation helps, so does journaling, self-reflection and a bit of education.
Cultivating mental qualities is important for software developers because we rely on our mental processes to produce code. Learning to manage distractions (external and internal) is another key part of the inner game of software development. This is another place where mindfulness meditation can help.
Mindset is not often mentioned in software development circles. This means learning to re-frame "failure" as "learning", viewing problems as challenges (growth mindset), making use of feedback, using the scientific method and giving without expectation.
Defining success internally is a particular form of mindset that I've relied on. For example, I've defined success in terms of having more time to work on creative pursuits, so I sacrifice salary by working part-time in order to spend time on the things that I love.
For a while that meant "just" doing Wordpress development (rather than my full capacity of running hardcore web-dev teams). Neither of these make sense from a typical "outer game" point of view, but made perfect sense from my inner game definition of success.
The outer game is often outside of your control. Reality will provide you with a stream of events - opportunities as well as challenges - that sometimes have nothing to do with the effort you are putting in. I still advise shaping your external reality as much as you can. But recognise the inherent limits.
Your inner game is yours. There is always room to explore the structures of your mind, learn more about how you habitually do things and whether there are better ways. Let me know how I can help.

The Developer Burnout Survey - Results

Daragh Byrne — Fri, 03 Apr 2020 22:22:51 +0000

I did a short survey of 55 developers about burnout. Naturally, being a burnout focused survey, pretty much everyone who replied was currently experiencing burnout or had experienced burnout in the past.

originally published at CodingMindfully.com

I collected the results via a Google form late last year. I've only gotten to analysing the results now, which I'm sharing here.

Obviously this cannot be taken as representative of the software community at large, given the likelihood of those interested in burnout to have taken my survey. But the results are interesting, and tally with my own experiences of burnout.

I was curious to learn a few things:

The symptoms of burnout typically experienced by software developers
Whether developers had experienced adverse career effects due to burnout
The internal and external factors that contribute to burnout
Strategies that are used to prevent or recover from burnout.

The Symptoms of Burnout

I asked which of the following six symptoms of burnout people had experienced. This is based on my programmer burnout checklist.

Cynicism or feeling critical of the whole idea of writing code. This could show up as repeated negative thoughts or statements about building software or writing code.
A lack of the necessary energy needed to get your work or other coding projects done. Feeling like it's difficult to physically write code, to find the mental energy required to organise your thoughts
Lack of motivation to "turn up" to work -- physically going to the office, or logging in remotely.
Unnecessary or repeated irritation or anger at co-workers, or unreasonable doubting of their competence.
Avoidant or addictive behaviour -- substance abuse, excess alcohol, overeating, gaming too much as a way of coping with the demands placed on you.
A compulsion to overwork to compensate for a feeling of falling behind.
A sense that the project or team will fall apart without you -- feeling that the entire success of the enterprise rests on your shoulders alone. Otherwise known as The Indispensable Trap.

I left space for other symptoms to be submitted too.

This is not a super scientific survey. The results are supposed to be indicative or even typical.

I've divided the symptoms into those experience by most people, those experienced by "around half" of respondents, and those experience by "some people"

Download my burnout checklist now and see if you are burnt out

Most people

By far the most common experience was "A lack of the necessary energy to get your work or other coding projects done"

80% of people who responded identified this as a burnout symptom. It was the standout symptom of programming burnout.

Around half

There were a cluster of other symptoms experienced as well as lack of energy. Here's the raw data.

Lack of motivation to "turn up" to work -- physically going to the office, or logging in remotely (50%)
Unnecessary or repeated irritation, anger at coworkers, or unreasonable doubting of their competence (53%)
Cynicism or feeling critical of the whole idea of writing code (43%)
A compulsion to overwork to compensate for a feeling of falling behind
A sense that the project or team will fall apart, that the entire success of the enterprise rests on your shoulders along (43%)

I've felt most of these at some point during my burnout episodes. I have personal experience with cynicism about being a software developer (which is pretty hard to take when you've invested a whole lifetime creating a career in it).

I've looked for the exit hatch several times (I always end up delighted that I haven't found it. Eventually)

I've also experienced the compulsion to overwork when I feel like I'm falling behind -- something that saps my energy even further (I still need to be mindful of this!).

If you are experiencing any of these, in particular alongside extremely depleted energy, it's likely you're somewhere on the burnout spectrum.

Some people

Avoidant or addictive behaviour -- substance abuse, excess alcohol, overeating, gaming too much as a way of coping with the demands placed on you

This wasn't as common as I suspected it might be -- although I do wonder the extent to which devs underestimate their gaming behaviour as addictive, based on the behaviours I observe around me!

Other symptoms

I left a space for respondents to enter other symptoms of burnout they might have experienced. I broke them down further into physical, mental/emotional, addictive, relational and professional. Here's a summary of what I found.

Physical symptoms reported include:

Getting sick more often
Chronic tiredness that is not helped by rest or breaks
Headaches
Nausea

Mental and emotional consequences include

"Brain fog" or an inability to focus properly
Disinterest in computers -- feeling like running away from them
Hopelessness
Lack of motivation
Lack of self worth -- a raging inner critic
Social withdrawal
Lack of engagement in life in general
Feeling stressed and anxious
Feeling disconnected from work and loved ones

Relational issues include:

Feeling irritable with others -- colleagues and partners/family
Feeling anger towards others

Addictive symptoms include:

Drinking more coffee than usual
Browsing more than needed as distraction -- social media in particular

Professional issues include:

Not wanting to adhere to development best practices -- taking shortcuts like not thoroughly testing
Lack of interest in new projects
Lack of interest in learning.

It's not certain that experiencing any one of these symptoms alone is burnout related. Sometimes they just come and go as a normal part of developer life. I think it's fair to say though a cluster of them experienced together is an indicator that burnout is worth considering as a cause.

Career effects

I asked the question "Have you experienced negative consequences to your career or studies as a result of being burnt out?".

Out of 28 people who gave an answer, 8 people said "no" or "not yet".

Several respondents reported issues with productivity, including failure to deliver projects on time, or "not progressing fast enough" on projects, feeling stretched too thin and so on

Several respondents reported having to leave jobs, being performanced managed (sometimes out of a job), being "squeezed out", made redundant or feeling that their relationship with their team was so compromised that they had to leave.

Several respondents reported health impacts, ranging from some of the physical impacts mentioned in the previous section, to stress and anxiety symptoms, to a compulsion to overwork, to having to spend a month in a psychiatric hospital. Sometimes this also leads to leaving the job in question.

Of those who said there was no impact, a couple mentioned their ability to hide or push through the effects of their burnout -- even though they were feeling burnt out, they were able to work well enough that their career was unaffected.

Personally, job-induced burnout has contributed to periods of poor mental health (anxiety and depression) and other health issues. I've not left a job because of burnout, but I've certainly turned down offers of employment when it looked like working conditions might cause burnout.

Factors contributing to burnout

In order to assess what programmers feel contribute to burnout, I asked two questions:

What external factors contribute to burnout? e.g. workplace culture.
What internal factors contribute to burnout? e.g. mindsets or beliefs you hold.

I'll present a summary of themes that I've extracted in a fairly non-scientific way. I feel it's representative though, and I've anonymously quoted segments of the answers below.

External causes of burnout

I divided perceived external causes of burnout into:

Process/management,
Workplace culture,
Tech culture
Meaning

Process/management

Download my burnout checklist now and see how you compare.

Unsurprisingly, process/management was mentioned frequently. Issues that came up more than once included:

Lack of recognition -- "not getting recognized for ... work contributions"
Poor process -- "misunderstanding of development processes, context switching"
Unrealistic expectations and deadlines -- "unplanned projects with accompanying arbitrary deadlines"
Not understanding tech -- "managers aren't technical enough, there is no understanding of the time it takes and variability of project outcomes in software"
Over promising -- "management who over-promise on projects leading to working long, exhausting hours"
Feeling unheard -- "my ideas are constantly rejected".

Workplace culture

Workplace culture was also prominent in the results.

As one respondent put it, "it's hard to get burnout in a vacuum". Culture matters almost as much as management.

Here are some examples of cultural norms that create the conditions for burnout.

Long hours culture ("prolonged culture of mandatory overtime perpetuated by teams to meet deadlines") -- lack of "work/life balance", "little vacation time".
Coworker relations -- "passive aggressive pull request comments", "toxic colleagues who lie and deflect to cover their own backs".
Mixed attitudes to quality and contribution including "other team members who don't do their fair share of work" and programmers who don't adhere to the agreed quality standards
Poor tools -- "proper chairs, desks and tools"

Tech culture

Tech culture as a whole also has an impact. Tech is an industry where you are constantly rated on what you know, in a landscape where that body of knowledge is constantly changing. It's no wonder programmers suffer inordinately from impostor syndrome.

Examples from the survey supporting tech culture's contribution to burnout.

"I have a friend who's constantly worried about his future as a dev due to articles he reads online" -- comparing mind
"Social media, .... peer pressure"
"Tech culture as a whole
Issues of diversity -- "being the only woman in the room... not being included... being name-called".

Meaning and value

Several respondents identified lack of meaning in their work as a contributor to burnout. It can also be a symptom as well. A couple of examples:

"not feeling connected to what you're achieving
"passionless projects and work environment"
"doing very repetitive work"
"working on a product you don't believe in".

Humans need to feel like their work has meaning (even if that's as simple as "it supports me/my family"). A lack of meaning can definitely contribute to episodes of burnout.

Internal factors

I know from my own experience that my inner world -- my thoughts, beliefs, emotions and patterns of behaviour -- have a significant effect on the way that I experience the world. I've held unhelpful beliefs in the past (such as "I must work harder because I'm always behind") that have worsened my own burnout situations.

I was curious to find out what internal factors developers perceived as contributing to their own burnout.

The question was "What internal factors contribute to burnout? e.g. mindsets or beliefs you hold." I roughly divided the responses into these categories:

"Not good enough" beliefs
Beliefs around responsibility
Stress management skills/switching off from work
Feeling unsupported

The "best" thing about this set of factors is that, given they are internal factors -- to do with yourself -- you have a good opportunity to work on them yourself!

Beliefs around not being good enough

Many respondents identified some variation of "not good enough" beliefs as an internal factor of their burnout. Often this related to a sense of diminished productivity, or a belief that you have to work harder than everyone else:

"by not getting enough done, I'm showing that I'm not capable/competent"
"not being good enough in the event I [lost my] job"
"always saying yes to not be seen as negative"
"feeling like I need to work more when I don't have much to work on".

A particular manifestation of "not good enough" belief is impostor syndrome. Often impostor syndrome encourages people to work even harder to fill what they perceive to be the gaps in their knowledge, compounding exhaustion:

"how you handle imposter syndrome -- when I feel I am talking behind in technical competency I speed up and scale out my out of hours learning"

Frequently "not good enough" manifests as a negative comparison to others:

"comparing yourself to others can lead to pushing yourself too hard"
"constantly measuring [your] self against other 'successful' people"

Sometimes perfectionism is mentioned directly, or "believing that you must be the best" or "setting unrealistically high standards for yourself".

Once more diversity can influence this belief:

"as a person of color I have to be 150% better than anyone else to ... be treated fairly"

Responsibility beliefs

Beliefs around personal responsibility for the success or failure of a project were also commonly cited internal factors of burnout. You put the weight of the entire world on your own shoulders -- every mistake, every missed release, every misunderstood requirement, every production issue is your fault -- "[I can't] push blame on anyone else if fail to meet [the] deadline. In reality software development is a team game where we all go wrong sometimes -- and deserve some sympathy and understanding when it inevitably happens.

Sometimes this manifests as not being able to say no ("maybe you feel as though you can't say no or push back on work"). Sometimes this comes from "being a people pleaser" (oh boy do I know that one!).

Other times we are "taking too big of a challenge" than we're equipped for because we think we should.

This sort of self-directed internal pressure can be quite draining over time and can therefore become a factor in causing burnout, and is often manifested as a symptom of burnout itself.

Stress management skills

Multiple respondents cited inability to switch off from work or manage stress as an internal factor.

I know this one intimately myself. It's what led me to set up codingmindfully.com. Unmanaged stress was certainly behind most of my burnout experience.

This was expressed as "lack of being able to switch for a while to other things", "not being able to ... relax myself". Sometimes respondents would feel "anxiety and stress".

"Ability to process negative feelings" was also cited, as well as "not being able to be at peace with situations out of my control"

I feel like this is a list of the reasons I began learning how to meditate!

Lack of support

Some respondents reported feeling unsupported. We all need humans around us who are supportive, or at least not directly destructive.

Sometimes this comes from "lacking a strong social circle". Other times from "things happening at home".

"Competition with coworkers, brogrammer mentalities" also don't help. Or, as one respondent put it, "I love my job, it's everyone else that drags me down".

Sometimes it's "fear of asking to get help", perhaps out of fear of not being good enough.

Strategies for preventing burnout

Most burnouts aren't permanent. Heck, burnout isn't even inevitable in this industry (58% of respondents to this survey said No when asked if it was).

Most people figure out ways to work with their burnout eventually. My own approach has been experimental. Over the years I've discovered a set of practices and principles that (mostly) keep me from burning out, and helping me recover when I'm there.

Again I'll do a rough grouping of the data.

Managing intensity of work
Taking a break/self care
Having other interests
Attitudes

Managing work intensity

Many respondents say that managing the intensity of work is important in preventing burnout.

For many, this means being strict about setting boundaries, in particular around working hours. Set. a "clear separation of work and out of work time" with colleagues and managers. (If you can't do this, it's a red flag about whether you should remain in that job, but more on that later).

You need to be "transparent with your teammates about ... communication" -- channels used, when it happens, when you can be expected to respond and so on. And being strict with yourself not to check messages out of hours, turn off notifications etc.

You can also practice realism in your working practices, by "allowing extra time when estimating deadlines" to give yourself breathing space.

Taking breaks and self-care

Taking a break was seen as essential in preventing burnout. Humans need to rest. It's in our nature. Taking a break is actually an excellent problem solving mechanism in its own right. Lightening the cognitive load gives the brain a chance to reset itself.

"Take time off when you need it and don't feel bad about it" advises one correspondend. You can also take "personal development time at work" or even showing up at reduced effort (it kind of makes up for all the time you put in the extra without reward, no?).

Some respondents advocate meditation (I'm down with that). Other self-care factors include exercise, cooking nice food and so on.

If you're on the edge of burnout, a short break might be enough to prevent something more serious -- "a day break is all I need". Certainly I find a few judicious hours can save me from troublesome territory.

Social media breaks -- getting off twitter -- are cited too! And socialising with loved ones and dear friends.

Having other interests

Many respondents placed emphasis on "doing things I enjoy outside of work", especially non-coding activities that have "nothing to do with computers". Humans thrive on variety -- it's important to mix it up, no matter how much you love to code! Personally, I'm a writer (articles like this, and poetry).

Other respondents recommend "writing a book" or even "increased sexual activity"! Whatever helps, I suppose!

Mindset and attitude

Attitudes and mindsets can make all the difference to your chances of burnout. Often they are related to the "internal factors" mentioned in the previous section.

One mindset I've found useful is valuing process over outcome. It's a way of dealing with lack of control -- when your code might end up being thrown away or never see the light of day, or your project canceled, if you've had fun during the process it will matter less. It's a type of protective detachment.

Remembering that "no matter how hard you try, all the extra work makes [little] difference ... when you are an employee" can help you set limits on how much you emotionally and physically invest in a job.

Conversely, attaching to the meaning of what you are doing -- "understanding the why behind our feature or product" can bring a sense of joyfulness to work that creates rather than depletes energy.

Strategies for recovering from burnout

Prevention is better than cure as they say, but even when we take good care we can find ourselves in sticky situations. So it's good to have a toolkit for navigating your way back. Although some say "there is not much you can do" I think there are enough options to give yourself a great chance of bouncing back (I know I've had to do it myself several times!).

Here's another slightly arbitrary split of the data. There is a strong correlation between "things that prevent burnout" and "things that help you recover from burnout" in my opinion.

Rest and self-care
Reprioritise other activities
The nuclear option

Rest and self-care

Most of the rest and self-care suggestions for preventing burnout also apply to recovery. I would suggest the quantity of time spent on these be increased if you are truly burned out.

Suggestions include "meditation, taking time off (if possible), breathing exercises, yoga, working out, going for a walk, talking to someone, trying to practice being kind to myself".

Getting the basics right, like "sleep[ing] early and eat[ing[ better" are also encouraged, as was "not coding outside of work for a few weeks".

Physical exercise (I recommend low intensity like yoga or walking if burnt out) was also mentioned.

Finally, connecting with others -- having conversations with friends, or opening up to a therapist about your burnout cannot be recommended enough in my opinion. "writing down thoughts as a way to understand them more clearly" also makes an appearance, and my trusty journal would agree.

Reprioritising other activities

Often burnout occurs because we let the things that restore us slip. So as well as rest, it's important to connect with the things in our life that bring us energy! It's time to reconnect with your non-coding hobbies. Baking, drawing, writing, reading, movies and all that.

It's really a question of balancing the energy equation. There are activities in life that create energy, and activities that deplete. You want more of the former and less of the latter, so that over time, you're building or rebuilding your energy rather than wearing it down.

Apply liberally until symptoms resolve!

The nuclear option

So. This is the big one.

Quitting your job and starting somewhere else. Or nowhere else!

One respondent feels that "the nuclear option is usually the only one that works". Another "usually just find[s] another job and take a month off in between".

Don't get me wrong. There are times when this is the correct course of action. If you're in a truly toxic situation, where there's no recourse to change, then it's right to pull the plug. You don't need to be anybody's hero. You don't owe your wellbeing to anyone else.

I've done this myself and would do it again. But I'm actually just careful to avoid workplaces where it's likely these days.

Summary

Burnout in software developers is a multi-faceted phenomenon. At its core, it's an imbalance of energy -- specifically, the mixture of activities in life that create and deplete energy is out of whack. Knowing the signs that you are about to burn out can be useful in preventing it, by taking action early. Specifically, watching out for issues with energy and motivation, cynicism about the profession or activity of writing code, a compulsion to overwork, irritation with co-workers and that you are entirely responsible for the success of the project can indicate some degree of burnout is present. A persistent lack of energy is the overwhelmingly universal symptom of all of those who answered this survey who had experienced or were experiencing burnout. Other symptoms reported included physical, mental/emotional, relational addictive and professional issues.

Burnout may have effects on a developer's career. In worst cases (perhaps in the worst environments?) it can lead to performance management and dismissal. In this author's view, that's more an indictment of the organisation than the developer. Productivity issues, health impacts and having to "push through" were also mentioned.

Developers identify several categories of internal and external causes of burnout. External factors include process/management issues, workplace culture, tech culture in general and access to meaning in their work. Internal factors include beliefs around being "good enough", beliefs around responsibility, stress management skills and feeling unsupported. It is noted that both sets of factors are areas where developers can make choices and take control -- which gives hope for recovery.

Burnout prevention fell roughly into four categories -- managing workplace intensity, taking breaks, having other interests outside of work and attitudes/mindsets. Rest and self-care, outside interests and "the nuclear option" of quitting a job were seen as the main ways of recovering from burnout.\
This survey is not scientifically valid. I haven't applied strict research methods. Nevertheless I hope it gives an indication of how a more thorough exploration of developer burnout comes from and how it can be dealt with might proceed. It certainly tallies with my own experience of burnout and recovery. I hope this has been useful to you!

Download my burnout checklist now -- last chance!

Dealing with your Inner Critic - a dev's guide

Daragh Byrne — Fri, 17 Jan 2020 21:54:02 +0000

(first published on CodingMindfully.com)

One of the side effects of my meditation practice is that I am quite aware of my thoughts.

If I pay attention for a second, I can give you a detailed description of what is passing though my mind.

Floating along in the stream are a set of thoughts that I have about myself. Some of these are good, and pleasant to experience. Others, less positive and indeed less comfortable.

There are a particular set of thoughts that sound like negative judgments about myself. They include thoughts like:

You’re not technically gifted enough to be a team lead
You’re a failure for your age - why aren't you CTO by now?
You’re boring – nobody’s listening to you
Your code is spaghetti – what a mess!
You need to learn that new framework NOW or you’ll be an unemployable bum forever
You’re wasting your time on this
You should be working harder – you didn’t last time and missed the deadline
You’re too loud
You're too quiet
That person would never date you….

And so on. It’s endless.

This is the voice of your Inner Critic.

I call mine Bob, for historical reasons.

Hands up if this sounds familiar? Most of us have a set of thoughts like this, to a certain extent. Unless you’re a narcissist, which is basically the inner critic turned on the rest of the world (off topic for this piece).

The thing about this voice in your mind, that looks, at first hand, like it’s trying to drag you down, is that it’s not your voice.

Where the Inner Critic comes from

The inner critic came from outside of you.

It’s vitally important to understand this if you want to learn to work with it.

As you grew as a child and young adult, you heard many, many statements about what you should and shouldn’t be doing, how you should behave or what you should/shouldn’t consume.

In effect, your mind was programmed to think in a particular way by these experiences. The inner critic is a manifestation of that programming.

Many of these messages are necessary for our safety – “you shouldn’t play in the traffic” is a perfectly sensible thing to tell a child.

But here’s the thing. As our mind develops, we build up a picture of the way we SHOULD be in the world.

Our minds model an idealised self that behaves in perfect accordance with all the messages we’ve received about how the world works.

It also builds up a catalogue of what you’re doing “wrong” – the ways you’ve failed to reach this ideal.

This is what eventually manifests as the voice of the inner critic – a combination of mixed messages from the outside world that creates a false ideal of perfection, and a model of how you fail to match up.

If you think about it, this is entirely unfair. First up, the world is a complex, messy place and anyone who claims they can install perfect ethics in a developing child is probably running a cult.

(I have a rule – don’t start, or join, any cults).

So don’t stress about the fact that you have an inner critic. It was pretty much inevitable, and it’s NOT your fault (hey, shut up Bob, it’s not!).

And in actual fact, it thinks its job is to keep you safely alive in the world. So it doesn’t have bad intent, even if it’s a bit of a dick about it sometimes!

Working with your Inner Critic

Having discovered the inner critic, it’s a good idea to learn how to work with it because

It can be tiresome, consuming our energy and making for an unpleasant experience
It can hold us back in life, by convincing us of our lack of worth or inability to do what we want to.

There are a couple of useful stages to working with the Inner Critic. Here’s the list:

Learn to recognise it
Set some boundaries
Build a healthy relationship with it Here’s a bit more depth on each of those.

Recognizing your Inner Critic

Pay attention to your own thoughts about yourself. In particular, negative self-judgement.

You can do this now – take out a notepad and for the next five minutes, write down any self-critical thoughts.

What did you come up with?

Often our inner critic has a particular flavor, or flavors, of criticism. Have a look at this list and see if any stack up:

Perfectionist – thinks you should be flawless at all times
Controller – needs you to take charge of your self and your environment
Taskmaster – thinks you should be working harder
Underminer – is out to sabotage you
Destroyer – wants to break everything inside and around you
Guilt tripper – keeps you feeling guilty all the time
Moulder – sees you as deficient from some ideal and tries to shape you that way, against your true nature

Bob is definitely an Underminer – he just doesn’t think I’m worth any success at all. Occasionally he’ll be a moulder and have me pretend to be something I’m not, but less so these days.

I’m curious to see if there is a common type of critic installed in the brains of coders – I’d guess Perfectionist might be prominent, maybe Controller – if you are feeling brave post in the comments below!

Set some boundaries

If you recognize that your Inner Critic has been causing issues in your life, it’s time to give it a reality check.

Remember, it’s a part of you and you are not completely what it says you are! So take some charge here and start a dialogue with it.

Here’s an example
_
Me: Hey Bob.
Bob: Hey loser!
Me: Bob, stop calling me that. It’s mean and you’re stopping me from getting shit done
Bob: But you’re so rubbish at everything, you’re going to fail!
Me: Bob! Seriously! I want that shiny new promotion and your incessant chattering is distracting me from getting it! So give it a rest for a while!
Bob: No.
Me: Yes!
Bob: NO!
Me: Yes, or I’m locking you in the dungeon and throwing away the key.
Bob: Dungeon? There’s a dungeon in here?
Me: Thank you, I’m glad you can see I’m serious about this.
_

There are a couple of tactics you can use in your own conversations.

Understanding – this is a big one. Try to figure out what your Inner Critic is trying to do. Where did it come from? What external voices from your younger life does it represent?
Humour – it’s OK react to your Inner Critics rubbish by laughing it off. Try it! What effect does it have?
Shouting – don’t be afraid to tell your Inner Critic to f*** right off! ###Build a healthy relationship. Make this kind of self-conversation a regular practice! Keep setting boundaries, keep trying to understand, laugh it off and, when you need to, get tough!

As much as the Inner Critic originated as a habit, a new way of relating to it is possible by building new habits.

Me and Bob are now on pretty regular speaking terms. He says what he needs to, but I don’t let him get in the way of my life so much these days, and in general he’s a bit quieter about it. It’s a much better relationship than it was!

The Inner Critic and Programmers

As devs, we use our mind a LOT. Our relationship with our inner landscape is paramount if we’re to keep pumping out useful code.

I hope this article gives you a bit more detail of the architecture of your own mind, and some practical ways of working with your Inner Critic.
Comments always welcome!

Photo by Hello I’m Nik 🇬🇧 on Unsplash

How to optimize for an amazing 2020!

Daragh Byrne — Fri, 03 Jan 2020 00:17:15 +0000

Optimise this year for flow and meaning

(First published at CodingMindfully.com).

A new year is a chance to refocus. It’s an opportunity to check in, to ask yourself what you truly want out of life, whether you are getting that and if not, what might you do differently.

We all have limited amounts of time and energy. How we choose to allocate those determines to a large extent the degree to which we are satisfied with life. If we find ourselves dissatisfied, we can examine the way we are spending our time and adjust as needed.

There are two shortcuts that I use to make sure I’m spending my time and energy wisely:

Optimise for flow
Optimise for meaning

Optimise for Flow

I’ve written extensively about Flow here (in fact there’s a lesson in my online course The Mindful Developer that gets into it in depth).

Article No Longer Available

Flow is an inherently satisfying state of being. Many of us hit flow regularly in our coding life – it’s part of the draw.

I try to fill my life with flow generating activities. Outside of coding, there is yoga, meditation, writing and so on.

Programmers are natural flow junkies. But flow begets flow, and it’s useful to have multiple sources of flow in your life. Grab a pen, list where your flow comes from, and see if you can think of a potential new source for the year ahead.

(I’ve chosen to enrol in an Improv Comedy class – a group flow activity!)

Optimise for meaning

I want to spend my precious time here on earth on things that have meaning to me.

But what does “meaningful”, um, mean?

The answer is, it depends on your values.

Your values are the principles or ideas that drive you. They aren’t fixed – they will change over time (mine certainly have, as I’ve aged).

You’ll find a sense of meaning in activities that are aligned with your values.

You’ll likely encounter frustration in activities that are less aligned with your values.

Here’s my current list (I keep a spreadsheet which I update every few months):

Playfulness
Financial stability
Contribution beyond self
Creativity
Justice
Health
Optimism
Community
Sustainability
Friendship
Mindfulness
Completion
Self-control
Intimacy
Achievement

It’s worth having a think about this – you can use this list of values as an aid.

Knowing your values is a great way to make decisions that are right for you.
For example – imagine you’ve just been offered a new job. The pay is great, but the hours are likely to be long from time to time.

If your core values include, say, wealth, it might be worth it.

If your values include, say, family time, you might need to consider whether the job is right for you.

My personal values include health – which includes mental and physical. I know from past experience that working long hours can affect that in a way that doesn’t work for me. So, it’s a pass on the job for me in this case.

Here’s another example. Say I’m given the choice between learning two programming languages or frameworks (React and something much more obscure, but kind of cool - take your pick).

If my values include curiosity, or learning, I might be more inclined to take on the obscure platform.

If my values include stability, and I know there are a heap of jobs for React programmers, then I might be inclined to take that option instead.

Another example from my life - right now I choose to spend my leisure time on non-coding activities (in particular, writing).

My value of Creativity is driving that. In a few months time, my values might shift, and I can reassess where the time goes.

I’ve also chosen to cut down my list of side projects to just two. This is in line with my value of Completion. However you might value diversity of experience for example, and be willing to pay the price of not finishing things to work on lots of cool stuff. It’s up to you!

So – have a look at the things you do in your life. The company you work for. School. Family. Relationships. Hobbies.

Which ones are in alignment with your values? Which ones are out of whack? How does that affect your sense of meaning? What can you change to optimise for that?

Beginning the year

This is a short intro to the framework that I use to answer the greatest of questions – how should I spend my time?

I hope it’s useful for you. It’s not just for the beginning of the year either! You can do this any time (I recommend every few months).

The Great Developer Burnout Survey 2019

Daragh Byrne — Fri, 01 Nov 2019 19:31:30 +0000

I'm pretty passionate about burnout. I've even done it myself a few times.

Article No Longer Available

I've learned a few things along the way.

Burnout sucks. I should know, as a veteran of a couple of major ones.

Like most adverse experience, you can learn a lot from burnout if you approach it in the right way. I sure have. It’s part of the reason that I started my website - to document strategies and practices that help.

I like to write. I find it therapeutic, but it’s also a way to share super valuable information.

My current project has a working title of “The Software Developer’s Burnout Bible”. It’s going to be a resource that covers everything you need to know about recognising, preventing and recovering from burnout.

I need your help! To keep me on track, I want to hear about your burnout experiences.

It would be AMAZING if you could take a few minutes out of your day to complete this short questionnaire about burnout and how it’s shown up in your life as a developer. All results are naturally confidential.

Click here to take the survey.

Many thanks!

Taking care of your emotional health - a dev's guide

Daragh Byrne — Fri, 18 Oct 2019 20:32:41 +0000

Emotional health is mental health

It was world mental health day this month. Mental health is a blanket term that covers everything from how you think and feel (including your mood), to your behaviours and relationships, how we handle stress and making choices that are good for us.

Personally I’ve had to learn to manage chronic and acute anxiety in the past. I’ve also had a depressive episode that took me about a year to recover from. I’ve had to learn a lot about my own mental health, and the factors that affect it.

I’ve feel fortunate to have developed skills and strategies that mean my baseline level of anxiety is massively lower than it was even five years ago, and when I do encounter anxious periods, I have to tools to cope.

I’ve been supported in this journey by many people - friends and family, therapists, teachers of all kind have been kind enough to gift me their expertise over the years. This article is an attempt to give some of that back.

I’ve structured my life so that my emotional health and mental well-being are my priority, and part of the reason I set up CodingMindfully.com is to share what that wisdom with you.

One thing that I’ve learned is that I’ve got to take care of my everyday emotional health. If I spend extended periods carrying excessive unprocessed emotions, that can compound and I can get into tricky territory.

Of course, there is no cure for the human condition, but what I present here are a few strategies for taking care of your emotional wellbeing on a daily basis.

The emotional life of a dev

Being a (neurotypical - I'm writing from my own perspective here, so sorry if this doesn't entirely apply to you dear reader) developer can be an emotional rollercoaster. A typical day can feel like:

Curiosity - when I’m presented with a new task or challenge
Self-doubt - when I realise the magnitude of the task I often freak out that I won’t be able to do it (often presenting as impostor syndrome)
Determination - as I fire myself up to get stuck into the task
I tend to cycle through flow and self-doubt as I’m working on the task. There can be moments of joy or satisfaction at this point. Sometimes this turns into self-blame if I’m particularly stuck though, which is nasty
Hope and confidence make an appearance as the end is in sight
Demo day - depending on how this goes I feel nervous or even anxious, maybe successful or even disappointed or angry.

I’ve identified at least thirteen emotional states in that one simple example.

Here are three strategies for emotional self care that I use every day. Try them and let me know how you go.

Recognise and regulate
Emotional Expression
Non-identification

Recognise and regulate

This is an essential skill that helps me daily. It’s got two parts:

Recognise that I’m experiencing a particular emotional state. This involves giving it a name - anxious, joyful, sad, angry and so on.
If I’m feeling particularly disturbed by my emotional state, I regulate using a number of different strategies

Emotions are complex responses that involve patterns of physical sensations often coupled with particular thought patterns. I’ve learned to recognise that I’m in a particular feeling state through learning the types of sensations I’m likely to feel.

For example, when I’m feeling anxious, I get a nauseous feeling in my belly. Or when I’m feeling sad or down, I get a heaviness behind my eyes.

Being able to identify an emotional state using a word can often lessen its impact.

Regulation refers to your capacity to return to a stable state after an intense emotional response. I use a variety of breathing exercises for this task (you can see an example in the video on my homepage or I'll send you some recordings if you download my free guide to meditation for developers).

Emotional Expression

Expressing how you’re feeling in words is a great way to process emotions. It shifts us out of the emotional response and into the cognitive part of the mind. Putting words on our experience helps us to make sense of them.

I do this in two ways.

First, I journal. I write down the details of the event that caused me to feel upset, the people involved, my interactions, the type of thoughts I felt and the physical part of the emotion (where I felt it in the body). This serves to help me process, AND helps me to build a catalogue of my typical responses, which leads to greater self-awareness in the long run.

Secondly, I talk it out. I’ve developed a network of close friends who I can call on to talk to when I need it. It can be quite challenging to be vulnerable like this, but it’s a skill, and people are more willing to listen than you might think. I also have a therapist that I can call on when I need to (less often these days, but it’s good to know they are there).

Non-identification

One of the reasons emotions can be so consuming is that we completely identify with the experience, as if it was us rather than just a complex set of bio-psychological sensations.

Learning to step back a bit and become a mindful observer of your emotions is a superpower. Here’s a neat trick that helps.

Imagine you are angry. Instead of saying

“I am angry"

Try saying instead

“Anger is here"

“You” are no longer angry. Instead, anger is something that is “just happening”. This little shift can create a bit of distance between yourself and the emotion - just enough to step out of the experience and begin to regulate.

Of course one of the purposes of meditation is to train your mind in how to take this dispassionate stance toward thoughts and feelings. I’ve written extensively on this before.

Learning to take care of your emotional health

So there you have it, my three hot tips on emotional self care. I’d love to know more in the comments about how this plays out for you!

6 ways meditation makes me a better developer

Daragh Byrne — Sun, 06 Oct 2019 19:16:49 +0000

One of the main points that I try to make here and over at at CodingMindfully.com is that a programmers work is channeled through their mind, so it’s in their interest to give the mind appropriate maintenance and to study it to understand how it operates; and that mindfulness meditation is an excellent way to do both of these tasks.

I’ve been meditating seriously for over a decade, with an interest that goes beyond that. Here are seven reasons I think it’s made me a better programmer.

1. Stress Management

Programming can be stressful. Whether you are a student or a professional, you probably have deadlines. You spend a lot of time confused, not knowing how to use a particular technology, feeling like an impostor. Stress, when accumulated over time, can cause problems.

By helping you develop awareness of your body, meditation allows you to notice and release physical tension, which helps reduce mental tension. These days, because of my mindfulness practices, I tend to release stress as I go through my day, rather than accumulating stress until it causes physical consequences like sleeplessness or irritability.

2. Reduced reactivity

Software development is a “high change” environment. Clients change their mind about requirements. New information comes to light that changes the technical approach you had in mind. Systems go down and everybody panics.

Responding to change reactively isn’t always useful. Panic doesn’t lead to the best choices or outcomes and can often compound problems. Cool heads are needed to prevail. A nervous system in a state of arousal leads to short term thinking, which might be useful in the moment but can lead to technical debt over time.

Practicing meditation for even a short period can allow you to notice when you are responding from a place of reactivity. I’ve certainly noticed this in myself – I am super aware of when I’m panicking (often completely unnecessarily) and can use my stress management skills to bring myself back to a state where I can make a more considered decision. It’s better for everyone.

3. Better focus through distraction management

Being a meditator doesn’t mean I have laser guided focus and never get distracted. I have picked up my phone at least three times while writing this article. But I noticed quickly, and got back to my writing – which might not have happened if I hadn’t developed mindfulness through my meditation practice.

Although meditation is a discipline that involves training your attention, you do this by developing the capacity to notice when you have become distracted. You come back from your distraction more quickly. You get better at un-distracting yourself. The net result is more time spent with your attention on the task at hand.

When coding, it’s easy to get lost down Stackoverflow rabbit holes and mazes of YouTube tutorials. Being able to notice when this has happened, and to bring yourself back to the task at hand, is a superpower. The net result is better focus, and for me, typically greater productivity.

4. Emotional intelligence

Meditation has made be better able to manage my emotions, in particular anxiety, frustration and impostor syndrome. Each of these, if they get intense, can interfere with my ability to code, or just the quality of my life.

Meditation allows me space to process difficult emotional states. It also trains me to notice my emotional condition “in the moment” so I can take appropriate steps to moderate how I’m feeling.

For example, I often get frustrated when trying to put together a piece of code with a new library (who doesn’t?). The mindfulness I’ve developed through meditation allows be to spot this. Instead of the frustration building to a frenzy, I’m able to make the conscious decision to take a break, or reach out for help – each of which allow me to make faster progress.

5. Self-knowledge

Meditation is discipline where you pay detailed attention to your own internal processes. It’s a bit like debugging yourself – monitoring your state, seeing how one thing leads to the next.

After a while you begin to notice patterns – patterns of thinking, patterns of emotional reactions, patterns of physical tension. This is very useful knowledge.

For example, I’ve become very familiar with my tendency to procrastinate when I’m not feeling super confident that I can actually do a programming task. Because I know this about myself, whenever I spot procrastination in action I force myself to “just write a line of code” – it often starts the ball rolling and leads to the completion of the task.

6. Appreciation/savouring

It can sound like meditation is just for solving problems. It certainly has helped for me, in many ways. It’s also helped me to savour the joys and successes of programming life.

I always encourage my team to absorb how they are feeling when they crack a particularly nasty problem, or when a big pull request is accepted. Humans have an in-built bias towards negativity, so it’s important to skilfully appreciate the wins that happen along the way as well.

Applying mindfulness to these moments of success has allowed me to develop the habit of feeling good – and who doesn’t want to feel good?

Meditation and you

Clearly I’m an advocate of meditation for programmers. I’m curious if any of these strike a chord with you? As always I’d love to hear your questions and comments, so please reply!

Of course if you want to learn more there’s always my Ultimate Guide.

Photo by Steve Halama on Unsplash.

Why knowing how to say "no" is important, and how to do it

Daragh Byrne — Thu, 26 Sep 2019 20:37:20 +0000

“We need to learn the slow ‘yes’ and the quick ‘no.’” - Warren Buffet

I'm naturally a people pleaser. There is part of my psychology that desperately wants to be liked by those around me. There’s a certain dopamine hit when I feel that I’m liked, which can be addictive.

It's not always a problem, nor do I see it as a flaw (like most personality traits, it can be useful or less useful at various points in time).

It has meant I've had to learn to say "no" effectively though. My desire to be liked has lead me in the past to say yes to things I'd rather have said no to, or agreed to actions that I wasn't entirely comfortable. I've been less effective and satisfied in my personal and professional lives as a result.

(This article was first published on CodingMindfully.com)

I've had to learn how to say no to friends, family and colleagues. The nature of the requests in each instance are quite different, but the techniques for drawing boundaries and saying know that I describe below can be used in

Here are several reasons why saying yes all the time is dangerous:

We become overwhelmed by taking too much on - our to-do list spirals;
We always feel like we are behind;
The quality of our work can suffer because of this feeling of overwhelm;
We can build resentment towards the people we say yes to;
We run the risk of disappointing those we said yes to when we fail to deliver due to being too busy;
We build unrealistic expectations of what can be expected of us, leading poeple to ask more and more of us;
Ultimately it can lead to exhaustion or burnout.

Over the years I've developed the skill of saying no through practice. And I've learned to appreciate and respect the "no" of others.

In fact I'd rather work with someone who knew how to set reasonable boundaries and expectations of what I could expect from them, rather than a "yes-person" who was always inaccurate about their true capacity.

Saying no is part of being mindful of how you use your time. It's a skill worth developing if you want to live life as a mindful developer.

Why we find it hard to say no

There are a number of different reasons why we find it hard to say no. Often they are based in fear or some other negative emotion. Here are some reasons I discovered in my own explorations - do you have any others?

One common reson it's hard to say no is that we feel inadequate. We carry some sense that we should be able to manage what is asked of us and that it reflects badly on us if we don't. Of course this is totally unreasonable. Everybody has limits, even the best performers in the world.

Another reason is that we are fearful of consequences. Perhaps we fear that a boss or a friend will take a negative or damaging action, or withdraw support or friendship if we say no. Of course, there are bare minimums of give and take in any relationship, but expectatoins have to be realistic, and capacity and boundaries have to be respected at all times.

If you continuously fear the responses of a person or workplace then you might be in a toxic situation, and it is worth considering whether that situation serves you any more.

Sometimes we find it hard to say no is that we fear the opinion of others. In this case we fear the consequences to our reputation. This can be related to the reason I mentioned at the start of the article (people pleasing/wanting to be liked).

Realisticaly, not everyone is going to like you in your life (I've had to do a lot of work to accept this and be ok with it, but it's true). So swallow your fear and say no!

We might not enjoy conflict. We can say yes to avoid an argument.

Finally, sometimes we are being manipulated. Someone is using social pressure ("everybody is doing it"), not telling the whole truth about a situation, flattery or other manipulation techniques to put pressure on you to do what they want.

This topic deserves an article in its own right, but it's a very valuable life skill to be able to spot when someone attempts to manipulate you and to remove yourself from the situation.

Ways to say "no" effectively

Here are a few methods you can use to start saying no effectively straight away.

Softening the no
This involves saying “no” without actually saying the word no. Use a phrase like, “I’d love to, but I don’t really have the capacity right now”. Or, "I can’t right now, but let’s check in in a couple of weeks”. This approach is very useful for social requests on your time that you don’t really want to engage with.

The calendar check
“Let me check my calendar” - similar to the above, it’s not a hard “no” and leaves scope to undertake the activity at a later date, but it’s effectively a no in the present moment.

Illustrate the impact on priorities
This is especially useful when responding to requests from seniors or managers who might not have the full context of your activities.

For example, a senior in your firm asks you to come to a business development meeting. It will take several hours out of your day, and jeaprodise the timely delivery of a feature in your sprint (which ends tomorrow). So you might say something like:

"I'd be happy to help, but if I do, I put feature delivery for my demo with Big Client tomorrow - perhaps we can have a conversation with Project Manager about that?"

This works because it makes the asker aware of facts that they might not have otherwise known. In this case they learn about the demo tomorrow, which might cause them to reconsider their request.

Suggest someone else
“I think Jamie would be good for that task, but check her capacity”.

The person asking often doesn’t really care who helps them, as long as they get help. Somebody else might be more interested, or better suited. The request to check the person’s capacity is respectful to that person.

Partial yes
This is useful when you are interested in supporting the person requesting time in a limited way. You offer partial help.

For example, you might say “I don’t have capacity to implement that feature, but I would be happy to review the code once it's done”.

Know your Yes

It’s easier to say no to things when you are super clear about your real priorities. Having an idea of the things that are valuable and meaningful to you makes it easier to spot things that are distractions or not part of your goals.

Practice makes perfect

Saying “no” is a skill and like most skills it gets better as you practice it. Start small - turn down some minor requests that you might normally say yes to (burdensome social events are a good place to start).

So, what are you going to say no to next?

Photo by Mattia Ascenzo on Unsplash. Cover image by Gemma Evans on Unsplash.