Developers are Spelunkers

Words are funny. Some words whistle by nonchalantly and unnoticed, but some stop at your door as if saying: “Do you remember me?”. Sometimes you hear a word, understand its meaning and remember where you first heard or learned it. That initial meeting with the word has forever associated an emotional link. One simply cannot unlearn the relationship with these special words, they have become your friends for life.

For me, “spelunker” is such a word. I learned this word as a 12-year old boy from a C64 computer game Spelunker (screenshot underneath). It wasn’t the best game, but the title stuck.



A spelunker is an explorer of caves. If you hope to one day be a spelunker, you probably have a love of dark, damp spaces and headlamps. (

A spelunker is an “explorer of caves”, or somebody daring enough to go into a dark place alone. I think this metaphor works to understand developers too.

Developers have to use willpower and concentration to descent into the depths of a code base. It’s work they must do alone, nonphysically (mentally). They sometimes face unforeseen obstacles; it-world counterparts of damp air, slippery slopes, snakes, lizards and skeletons in the form of non-maintainable spaghetti code, bad code comments, non-documented interfaces and ill-performing complex algorithms. Developers need to balance on small ledges of logic, but yet take into account complex cliffs of requirements and paradigm restrictions. It’s a pretty daunting task, actually.

Image result for spelunker c64

The deepest real-world caves are over 2 km deep. The descent to the bottom can take days and spelunkers need to set up camps in between. Similarly, it takes developers time and mental effort to descent to such intellectual depths. Every context-switch, meeting or a even friendly “hello!” are violent disturbances from the ‘spelunking perspective’.



After any kind of real-world disturbance (meeting, phone call…) developers need to descent back down into the virtual cave. They’ll need to take the same dangerous journey to where their work was cut off. It can easily take 10-15 minutes before they have reached the required depth of thought again. Do that five times a day and I’ll guarantee you’ll feel exhausted.

Developers enjoy spelunking. It’s their hero’s journey.

Here’s a thing to understand: developers actually enjoy spelunking, because that’s what they’ve used to doing. There’s a feeling of power related to this, something that doesn’t exist in the real world. I think many developers can relate to this feeling of power. Devs must do fair bit of spelunking otherwise they cannot build virtual castles existing only in the mental world. Spelunking is their hero’s journey.


(Image from

However, from people perspective it’s vital that they are periodically brought “onto the surface”, into the real world. I don’t mean this in demeaning manner, as if devs were somehow lesser creatures and unable to self-orient. No, I mean that their work is fundamentally different than everybody else’s in the organisation. Devs are sacrificing their physicality, and many other faculties, by willingly sitting paralyzed in front of two monitors every day. It’s brutal beating to the body, to be honest. It’s the price they pay for your success.

Therefore it’s vitally important that we take good care of developers, and support them when they are climbing up. This can be done by ensure reflective spaces (mental and physical) exist where they can enter as full human beings, with needs, feelings and aspirations.

Organizations must allow people to exist as full personhoods

This “revival” work is part of Scrum Master’s responsibility and I absolutely love creating reflective spaces. I often use physicality and rhythm as techniques to bring people to the present moment, onto the ground. Here, devs are allowed to dust off all the terrors of deepest caves, and breathe in free air.

Here a few tips for tech organizations, regarding developers:

  • Don’t be annoyed if your devs don’t return all greetings (they might be spelunking)
  • Make sure your office has a silent working area
  • Introduce “Don’t disturb me :)” cards
  • Allow individual setting of PC notification preferences (to turn off notifications)
  • Allow variable seating options
  • Allow using headsets, or even better provide noise-cancelling ones for free
  • Make most meetings voluntary
  • Make sure Scrum Masters periodically retrieve developers “onto the ground”
  • Use physicality and rhythm as ice-breakers
  • Don’t allow overtime
  • Don’t allow weekend work
  • Make sure code base doesn’t have much technical debt
  • Make sure tech dept uses “simplicity first” approach (less spelunking needed…)
  • Introduce pair- and/or mob-programming
  • Allow home office

That’s it. Until next time, stay agile – or lean. 😉

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s