Holiday Coding

Learning on the Job

Providing learning on the job at scale is a nut I haven’t cracked yet. I always try and provide teams with an environment where it is safe to experiment (concept: don’t wake me up at night; roll forward, don’t rebuild). A balance between getting things done and the freedom to explore (Balanced Roadmap, Uncertainty).

Still, I often find myself with too little time to guide and learn from all my colleagues. I do expect people to learn. I do expect my colleagues to keep their knowledge current. And to know their tools. I think it’s part of the profession of software engineers. The field moves fast. You have to keep up to stay relevant and keep your career path open. Especially for engineers early in their careers. With that, I don’t think it’s only about knowing the latest fancy tool. It’s not about chasing fashion. It’s also about fundamentals. Proven tricks of the trade.

I do notice however that I fall back to “basic” things that turn out not to be so “basic”. Call me arrogant, call me ignorant, call me both. Not all things I see as “obvious” are “obvious” to others. I have very smart colleagues, with talent, passion and a willingness to learn. And, thank God, the willingness to speak up. They are increasingly making me aware that there might be things I can teach. Things that have somehow shaped me as a engineer, architect, tech and product lead.

That however poses a fundamental question:

“How did I learn what I learned?”

I rarely know the answer to that question. I can tell you stories. Sometimes. But generally I barely know what and who influenced me. However, I do think I can replicate a little of what has been unique for me since my early days. Ever since I built my first BBS system in ± 1993 and my first website in 1997 I’ve had a unique advantage over fellow students and engineers.

I have always had a production system at hand to play with.

My learning was hardly ever merely theoretical. I have always been in a position with the freedom to play in production. And this, I believe, is a luxury that others don’t have. I do believe that has shaped me as an engineer, architect, product and technical leader. Having and actively creating this freedom is something that you can learn and exploit.

A first step towards getting the concept of learning with production for hobby, passion and productivity is what I call Holiday Coding.

Holiday Coding

Holiday coding is improving production systems by applying understanding through effort. It is a playful way of learning on the job in off time.

Over the next days and weeks I’ll explain more about the concept. So check in with this page from time to time if you’re interested. For now, a deep dive into the (working) definition.

Holidays.

I have holidays with kids. I have a family. Holiday means no stress, freedom to play and think. A process of starting and stopping. An hour here, two hours there. Over the period of 2 weeks it adds up. Starting and stopping, trying and retrying. Forgetting where you were, picking up where you left off, it distills the outcomes. Holidays provide both times of deep thinking and hyper focus, as well as moments of mind numbing repetitive time. Holidays provide a moment of quiet when the rest of the world is still sleeping or lounging, as well as the distractions. And while I do personally do code during my holidays, I do what I like most in my off time, the concept applies to work settings as well. It’s the spirit of holidays that count. See “off time” defined below.

Coding.

This is meant broadly. It includes coding in the broadest sense possible. Architecture, implementing 3rd party systems, shell scripting.

Improving.

We fundamentally go from something that works, to something that works and is better. Better is broad. Examples are better in readability, performance, robustness, comfort, cleanliness.

Production.

This is what sets Holiday Coding apart from Kata and Tutorials. Concepts are applied to the productive mess of production systems. Where your understanding of the whole might be limited, where real life provides uniqueness.

Systems.

We look end-to-end. While Holiday coding can function on individual functions or classes, it most often focusses on the interaction between multiple parts of the system. Holiday coding can span from infrastructure to function implementation in a single concept.

Applying.

It’s not enough to understand. One has to apply. Go from a working system to a working system.

Understanding.

It’s not just applying. ChatGPT can apply code for you. It’s about applying it in a messy situation, and through the application gain a true understanding.

Effort.

A mix of play, study and putting the work in does the trick. During a normal workday one tends to not do the repetitive thing. The things that feels unproductive, but is not. People shy away from doing the repetitive work with productivity as an excuse. Holiday Coding is not that. It often contains parts that make you feel you’re plowing through mud.

Playful.

The spirit of Holiday Coding is the spirit of play. Good natured, possibly competitive, room for improvisation, jolly, folly, individual or collaborative, with space for failure and surprise.

Way.

It’s more of a mindset, a philosophy, less of a rulebook. Any structure is there to show the way, not to be the way.

On the Job.

The benefits of Holiday coding are both to the production system and to the engineer. This means the job benefits.

Off time.

There is no guarantee on delivery. It is voluntary in nature. The holidays might be over before the concept is fully explored. The coder can hope, but should never count on nor indicate that holiday time will have an immediate productive outcome.