20% Time at Supercede
At Supercede, we only work directly on our product four days a week.
Every other Wednesday we hold Research Day. This is a day explicitly set aside for everyone on the engineering team to study, investigate, and experiment with some technology of their choosing. It should ideally be some kind of technology that could potentially be rolled into our business, but that isn’t strictly necessary. We’ve looked at things like:
- Improving the performance of our test suite
- Delegating more logical safeguards to the compiler
- State machine testing with Hedgehog
- Nested record updates with lenses in Elm
Our Research Days have been broadly successful. Sometimes our experiments have lead to significant improvements to our product. Sometimes we find ways to help the whole team iterate faster. Sometimes we find some technology is not viable at all, and that’s cool too! That’s not a failure. It’s important that every programmer is afforded the possibility to explore the paths that lead to dead ends. There are still lessons learned there.
So much of our jobs as programmers is learning and experimentation. This is one of the major ways we enhance our own skills as individual software writers, and also it’s often how we come upon better approaches to solving problems for our employers. It seems the common case in industry is to relegate learning and experimentation time to evenings and weekends, and I think that’s a shame for a couple of reasons:
From the perspective of the employee: if you’re working hard on your employer’s product all week, how do you find the energy to continue studying outside working hours? It’s easy to be too mentally exhausted to pick up that weighty Haskell tome or apply novel approaches to Advent of Code challenges. If you aren’t learning, you aren’t growing, and soon after you’re no longer enjoying your work and you disengage.
From the perspective of the employer: the preceding paragraph still applies, perhaps with equally as much weight. If your company is a sweat shop, you aren’t going to do well with employee retention.
The remaining Wednesdays are designated as Open Source Day. The principle here is somewhat similar — we have dedicated time to contribute back to some of the open source libraries (mostly Haskell) that we rely on. This is not just the morally appropriate thing to do, it also works in a pragmatic business sense. If we’re helping to maintain our favourite open source libraries, it will encourage other people to do the same and everyone benefits.
A side effect of increasing the amount of work we do in public is that it forces us to slow down and be more deliberate in our communication. People we collaborate with outside our organisation are of course going to have less context into the problems we’re solving, so there’s less opportunity for us to be terse. Making a habit of communicating with people outside the organisation will improve the way we communicate with each other within the organisation.
I’m finding that both of our Wednesday traditions at Supercede are helping us to cultivate the kind of calm and productive culture that I’m looking for in my working life.
Not only that, but after establishing Open Source Days, the programmers at Supercede hit the ground running and pretty much immediately started contributing patches upstream to various libraries, which have since been merged.
It’s pretty amazing what smart people can achieve when you get out of their way, allow them to continue maintaining at their own pace the parts of the product you might not see, and quit hassling them with micro-management ceremonies like daily stand-up meetings.