Ships Through the Night

Last week I participated in a Ship-It event at work.

The concept: the engineering staff form teams around concepts and ideas. Innovations that have been on peoples’ minds. Things that they think might be useful. Wow an audience.

Then at 2pm on Thursday, coding starts, and at 2pm on Friday, pencils down.

The aim is to put together a presentation or demo to an audience of everyone in the company. After all the presentations we vote. After the vote, one team wins the esteem of having won, their names on a trophy to be put somewhere in the office, and a custom-designed-one-run-only t-shirt.

Most of us are in it for the t-shirt… we have some kick-ass designers in our company.

The team I was part of started the event with a great idea for an improvement to some internal tooling. It was never going to win because it doesn’t cater to a broad enough audience, but it will make our own lives easier.

First lesson: 24 hours is not a lot of time.

We took some time designing a solution prior to the event. We had a fairly good idea of all the moving parts. Some databases, a message queue, some background processes and a Web UI. As I type that list up, I’m already wondering what kind of crack we were smoking to think it’d fit. But it’s good to be ambitious. I love hard problems.

By 6pm though it was time for dinner. Some of the chefs had stayed behind to make us something they called “chips”, but which so far surpassed the food item I have come to associate with that label we might as well pretend it was called “caviar” instead.

It didn’t feel like we had made anywhere near enough progress, and the day was getting late.

By 9pm, the team was starting to itch to go home and get some sleep. I foolishly stayed till about 10:30pm thinking I might make some more progress through the night, but my environment was exhibiting issues I couldn’t solve with a tired brain by myself.

Second lesson: stay or stay-not.

I probably should have headed home earlier than I did. A good nights’ sleep is a great way to restore productivity and get a fresh perspective on all the problems from the previous night. I guess this is why working weeks have nights at home scattered throughout them as well.

At 10:30pm I briefly considered sleeping in the office somewhere. I had prepared for staying and showering at work the next day. But I also had a kink in my neck and as comfy as the lounges are, I wouldn’t have been able to sit-up straight in the morning. Maybe I could have won a sympathy vote or two with a Hunchback routine, but it didn’t seem worth it.

I got home at about midnight, slept 5 hours, and headed back into the office early to get a head-start on the day. I was back at my desk by 7am feeling much fresher, albeit a little worn out.

If all this sounds exhausting. It is.
But it is also so much fun that it just doesn’t matter.

Third lesson: redefine the problem.

We came to the conclusion early on Friday that although only about half the available time had been spent yet we weren’t going to have a complete working system by 2pm.

So we did the smart thing.
We pivoted.

Rather than trying to produce a full working solution, we started to work on proving the feasibility of as many of the parts of the full solution as possible. We proved a migration path. We proved throughput. We proved the result we were aiming for.

And then we presented our findings with a demo of a Web UI over some batch-processed data rather than the live feed we would have liked to have had.

Fourth lesson: 24 hours is more time than you can imagine.

And then I presented for my team. Did an accidental mike-drop at the end (that’s my story and I’m sticking to it).

And we didn’t win of course. 8 out of 11.

But, what struck me is the amazing things that the teams came up within a mere 24 hours. Some teams stayed far later than I did; perhaps because they didn’t have to travel far to find their own beds. Next time I hope to find the strength to go around the clock myself.

There is something magical about dropping all process and standards, and just racing for the best you can do in a small time with a limited amount of time. It is refreshing. And at the same time it gives a good appreciation why some level of process is necessary.

I shudder to think of the code I wrote over 16 hours actually being the final version. It is atrocious by production standards. But it also worked brilliantly to address a tangible problem.

And then we rest

From what I understand we’ll be doing these every 6 months with fresh ideas to pursue.

It is a brilliant way to blow off steam. To try stupid things in stupid ways. And to work with staff outside of my own direct team. Mix-and-match.

I just need to prepare a palatable place to sleep in the office.
Just a few hours will do.
And I already have an idea.

2015-04-24 - Fireworks