Photo by Mike Kenneally on Unsplash
Have you heard about the SLOW CODE movement? (not to be confused with ‘low code’ and ‘no code’ approaches). I wish I had during the 15+ years of corporate programming.
Slow coding is for developers who value the craftsmanship of writing code, and all that comes from it. Romanticised, it’s similar to folk who still make wooden surfboards by hand, the enthusiast who hand-tunes their Triumph motorbike, or the turning of wood in the garden workshop.
Slow coding is about enjoying the very act of writing code. It’s the experience of sitting comfortably, thinking carefully, being focused, and becoming one with the tooling. It’s about working in a way that enhances emotional self-regulation and promotes physical and mental relaxation. It’s about finding the right balance of communicating with colleagues and periods of isolated, individual endeavour.
Slow coding isn’t opposed to boilerplate classes, autogenerated comments, or AI-generated code snippets per se, but it is against these if the result is the mindless production of mass-generated artefacts. Slow coding can be practised in corporate workplaces, but not if you are physically uncomfortable, mentally stressed, or continually interrupted.
Unfortunately, some people may not experience the full benefits of slow coding until a more wholesale change is made, eg. a different team, workplace or employer. Failing that, and if you aren’t already drained from your day, some after-hours coding may provide you with the enjoyment of slow coding. Many open-source contributions arise from exactly this.
A deep sense of rejuvenation should be the inevitable outcome of slow coding, similar to the peace that others experience from activities such as writing, reading, or completing a crossword puzzle. Slow coding should also leave you longing for more.