The Value of the Last Moment

During each year of high school, I attended Infoeducatie, a competition of software projects. It took place in Gălăciuc, about 60km away from Focșani, in an relaxing scenery, close to a natural reservation with amazing views. The way it went was that each participant brought to camp his own project, with his own idea and implementation and presented it to a panel of experts. This whole process involved learning by doing, planning, dealing with trade-offs before arriving at camp and getting a lot of feedback from the jury and from peers while being there. I can honestly say that Infoeducatie did more for boosting my education and jump-starting my career than the bachelor’s degree in computer science.

But there was this one habit I formed when attending Infoeducatie which proved extremely valuable both in my personal and professional lives…

Back then (2004-2007) the Internet was no so easily available and wireless network were few, far between and not always reliable. Moreover, I had a desktop computer at home. So uploading my project on GitHub or in Google Drive was not really an option. What this meant was that I had to burn a CD with my project (sources, binaries, examples, presentations) before I left home. The presentation also took place on another desktop computer, so having hard-to-manage dependencies was a challenge to be avoided.

So the situation was that the project I worked on for 3-6 months had to be done the moment I packed my bags. Keep in mind that I took the trip by train and it took about 10 hours in total – so it wasn’t like I could got back home and burn another copy. Afterwards, there was no debugging. There were no last moment commits or patches or fixes or changes. The binaries I packed in my bags were the binaries I had to install on that desktop machine I would use (and share with other participants) for my presentation. Little room for error.

Because of this constraint, I was forced (or I forced myself) to develop a discipline: that CD-ROM had to be burnt 1-2 days. To make matters truly immutable, I finalized the session when I burned the CD, to make absolutely sure there was no way to be tempted to change/tweak/something. Of course, I made at least 2 copies of my work, but most usually 3 (one for me, one for the jury and one just-in-case).

Now of course, you can argue that I am just paranoid. Or you could argue that things would have gone smoother if I had a laptop or if I had bought an USB stick or if the organizers facilitated an Internet connection (which they did, years later). But in my view, I can only be grateful with this configuration of constraints, because they seared one important concept in my mind: done means done.

In case something failed there was no point in finding excuses. There would have been no one else to blame but myself for having lost the opportunity to present months worth of my work. So this moment of burning and finalizing the CDs became some sort of well-prepared ritual. By the time I did it, I had a good idea of what features worked well, what features I wanted to showcase, what were the limitations I had to work around.

Over time, I came to treasure my ritual of immutability time and time again, because other that its advantages regarding discipline and well-preparedness, it yielded one other significant advantage: freedom. You see, after the painstaking task of researching, prototyping, coding, testing, integrating, preparing examples, running the whole thing end-to-end over and over again, after finally making that immutable “commit” – I was free. My mind knew and felt, from its brightest rooms to its darkest corners, that I no longer had to think about the code. Good or bad, well-tested or buggy, with impressive or with lame features – it was done. It was beyond repair and beyond improvement. It wouldn’t have mattered if I got the brightest idea which only took 5 lines of code – it wouldn’t have mattered.

And in this freedom, I found detachment for “could be” or “should be”. I found release from the guilt of “maybe I could do a bit more work the night before the presentation”. My mind became entirely focus on working with what I had and making the most out of it. During a 10 hour trip, I was free to talk with fellow participants, I was able to brainstorm, enjoy the view.

In the later years of high school, some participants started bringing their laptops. At some point, we had wireless networks with pretty good coverage. What happened was that before the presentations the participants started spending more time on their laptops. Tweaking just one more thing. Fixing a small bug. Doing some feature or implementing some idea they got. And they missed out on a lot. They missed out on the camp fires and and on that clear sky you don’t get to see in the city. They missed out on exchanging ideas and on talking to others. They missed out on listening and on taking in. They missed out on all the stupid shit that teenagers pull, especially geeks. All because they were busy pushing a few more lines of code at the last moment.

Sure, you’ll tell me that I’m old fashioned. “We live in the age of continuous delivery, continuous improvement. Automatic testing. Instant messaging. Push notifications.” you’ll say. “Slack. Google Drive. GitHub. Docker Swarm. Jenkins!” you’ll add. And far be it from me to not recognize the merits of these tools. Who in their right mind would burn CDs nowadays? Who would do manual tests when you can just as easily write unit tests? The new tech is great, it does make your life easier. But this article isn’t some rant trying to convince you to go back to digital tapes.

My point is don’t become overly reliant on automation. Don’t become overly reliant on instant connectivity and ubiquitous 3G or 4G. Imagine that you have to burn that CD. Set yourself up to have a last moment when you can declare your work as done. Finalized. Allow your mind to mark that task or project or action as immutable, so that you don’t spend your mental resources swapping between “what if I did something more?” and  “what should I do next?”

Tell yourself that for the purpose of that presentation, for the purpose of this sprint, for the scope of this client meeting – this is all the work I will have to do. Once that is done, deny yourself the possibility of getting your hands in it again.

Sure, you’ll yell out that this impedes productivity and that you wrote some of your best code at 4AM. Sure, it makes sense, I write code at night as well and I always aim for finding the most efficient solution to a problem. But don’t trade that extra 5% or 10% of work you could maybe squeeze in on your train ride or on your commute for the immense freedom that you gain by having some thoughts immutable.

Think of it in terms of multi-threading. If a piece of data or action is shared between competing threads, then you have to synchronize access to that. You have to make a perpetual choice between disconnecting/moving on to another subject and doing another git push from the airport boarding room. When you declare data immutable, you no longer have to think about it. It frees your mind from clutter and from the pain of handling conflict and competition between streams of minds (i.e. read threads). Also, by freeing you mind of what is done, you gain space that you can leverage to gain depth into something else.

Back in the day, people could only do work at the office and I could only write code for InfoEducatie at home. Those were the technical constraints. Now I can basically do it in every coffee shop. And while that freedom seems like a good thing for a while, it starts to take its toll when you are a constant state of choosing something to do out of all the (many more) things you could do. It’s the equivalent of resource thrashing, when the CPU starts doing more work on switching in between tasks than on actually doing any of the tasks.

The freedom that technology has offered has come with some caveats. We need some constraints, we need some point-of-no-return, we need to metaphorically burn that CD from time to time. And the thing is that for each such constraint that technology took away we have to fill the gaps with some discipline.

So have a last moment. Have the courage to label things done and move on. Buy yourself that buffer between the moment when you declare “DONE” and when the actual deadline is. That buffer (be it an hour or two days) puts you back in the drivers seat and returns depth to your mind.

Or maybe I got this whole story all wrong. Maybe I should have started with my father’s university stories. He said the even for the hardest exams, he would study for one or maybe two weeks. But he always left the day before the exam as a free day for relaxation. Nothing extreme, nothing tiring. Reading a book, watching a movie, going out with some friends (presumably without drinking themselves to coma).

The last moment, the hour or the day before the deadline, should always be free. That’s your buffer zone. That’s your leverage of control – both inside and outside your mind. And the ubiquity of tech has rendered that buffered so thin that it’s bordering non-existence. But it’s up to us to impose to ourselves the discipline to retake it.

Da Vinci said “Art is never finished, only abandoned.

Not only I agree with Leo here, but I also think that art (or work) also has to be abandoned. In the same way you leave behind the perfect vacation spot by the ocean, only to know you’ll return one day.

Bogdan Written by: