Committing At Least One Line Each Day for Five Years

This might sound like a hobby discovered during the 2020 pandemic, however, I started this experiment well before. Back in 2019, after years of working in slow-moving environments and becoming virtually sick of what felt like continuous on-dragging, I decided to change things for myself. Not only did I restructure the way I was working together with clients, to be able to optimize my own time as well as the overall throughput and efficiency that I was able to provide – but I also adjusted my personal life, my infrastructure, and my overall working methodology to be able to do more in less time and provide actual value, which is key to running own business ventures.

One of the many things that I decided to do was to commit at least one line a day, every day, for as long as I could make it. While I did not specify a clear target, on whether I wanted this to become a three-month streak, half a year, or even longer, I knew that I had to be dedicated to the path, rather than the destination, for this experiment to serve as a behavioral change towards not only the things I do for a living, but also own projects that up until then I was always picturing to realize but somehow never found the time to do so. Similar to how setting a goal like doing 100 push-ups per day is more realistic and potentially successful than doing 36.500 push-ups by the end of the year, I figured that committing at least one line of code per day would be a good way to introduce this habit that would ultimately lead towards a positive change in my workflow, the tools that I was using on a day-to-day basis, as well as hopefully an overall higher productivity and hence the chance to finally realize the ideas I always had in my head but never really managed to get done.

On the 31st of March 2019, I decided to improve the way I pursue my passion for computers and everything that evolves around them by changing the creating part of it, from being a necessity to becoming a natural habit. I promised myself, that I would try to commit at least a single line of code every day for the foreseeable future, regardless of whether that would be for a professional, a personal, or an open-source project. I figured that before I was able to actively improve the actual value of my work, I would need to make the process stick well.

The first month was surprisingly easy. Throughout April of that year, I had no trouble whatsoever to make time, sit down, and be productive. In fact, the first six months were going relatively well in that regard. However, after six months the first out-of-breath moment hit me. Bear in mind that we’re talking about one more or less valuable contribution per day, every day. Yes, on weekends as well. And yes, even if the workday was clogged with meeting, after meeting, after meeting; You still gotta sit down, focus for at least an hour and contribute something of value. And yes, even with a 12-hour flight, you have to make space to get out your laptop and solve at least one issue.

For the rest of 2019, I was starting to feel tired of this habit. Did I maybe get too excited about this the first few months and burn out all my enthusiasm and energy? Or did I simply expect this to be always easy?

I was starting to wonder, whether contributing at least a single line each and every day was a too ambitious goal for the long run. At that point, I barely made it to 9 months and felt drained. For some reason, the change in habit, that I was hoping for, that would allow me to find the space and enthusiasm to ultimately be able to work on more than just the bare necessary every day, and hence enable me to more consistently work on my projects, exactly that change didn’t seem to materialize. While I was able to pull off a handful of ideas that I had in mind, it nevertheless continued to feel like a struggle every day. At some point I remember having such busy days that I would fall back to for example just quickly improving code documentation by adding a handful of in-line comments, just to have something that would count towards my goal and forget about this stupid experiment that I was doing.

With meta work – as in spreadsheets, presentations, and other high-level documents – increasing significantly, in part as an effect of Covid-induced remote work for many people who were not familiar with that way of work, and hence an increased requirement for communication and coordination across client projects, I felt overwhelmed and barely able to stick to my goal. I felt like I was doing so much meta work – like creating presentations – that I had no time for valuable commits. Until one day it hit me: “Wait! By building this slide sheet that I’m going to present to other people, I’m effectively creating value. Why does this not count towards my daily goal?”

I began identifying flaws in the way I was working and the tools I was using. I started to realize that it wasn’t my presumed struggle to achieve my goal that was the issue here. In fact, being locked in during the global pandemic, I was creating more value than ever, yet my commit streak did not reflect most of that. The main reason for this was the tooling.

Like everyone in the corporate world, I was tricked into using garbage software like Google Docs, Microsoft PowerPoint 365, Atlassian Confluence, and Jira. These black holes of content ownership happily sucked up all the value I created on a day-to-day basis without reflecting the efforts that went into that. Quantifying productivity and contributed value has always been a near-impossible task, but with platforms like the ones mentioned before it is a complete black box. Clearly, I had to change my tooling.

Incrementally I began moving away from corporate platforms, to tools that would not only enable me to quantify my work but also allow me to own every bit of effort I was pouring into the creation of such sort of documents. As a cherry on top, collaboration would become a lot easier and more transparent, as every change of a document, a spreadsheet or a presentation would come with a dedicated Git commit and ideally a cryptographic signature that would verify the change as being legitimate.

Starting with Word documents, I moved everything to plain-text Markdown files, that get post-processed and transformed to PDFs when needed. One of the tools I learned to appreciate in that process is Pandoc. Pandoc is a Swiss army knife for all-things-text-conversion, supporting a gazillion different input and output formats. While it can be finicky at times to deal with the required dependencies for format conversion – and the LaTeX templates involved in the process – it is nevertheless an invaluable piece of software.

With spreadsheets, on the other hand, I went from Excel files to plain CSV files, for which there is plenty of tooling around. For more sophisticated things, I went for sc-im, an improved version of the Spreadsheet Calculator. sc-im natively supports XLSX imports and exports and offers an integration into GNUPlot, a command-line and GUI program for generating 2D/3D plots of data. And with sc-im supporting Lua scripts, it’s possible to build fairly complex spreadsheets that can retrieve data from external services.

For presentations, I switched to tools like lookatme, presenterm, and slides for the more low-level things, as well as marp and slidev for when graphical presentation is required.

FYI: Pandoc, the tool used for text conversion, can also be used to produce slide shows.

Besides all these changes in regards to the local software I use, it also helped the cause to adjust the server-side software I relied on. Getting rid of Ghost as a publishing platform for this site and moving towards a statically generated Hugo site, that is purely plain-text Markdown files at its core, had made a big impact on my workflow. Not only did the setup simplify the hosting environment and hence leave me with more time on my hands to do actual work, but it also immensely helped with streamlining the publishing flow, which not only consists of the actual writing, but also photography (for at least the covers) and post-processing, and sometimes proof-reading.

As for more professional/business-related things, I moved away from time-tracking software like Toggl and Tyme, and instead built my own tool that I could easily integrate into Git, as well as custom-built invoicing software, to have a smooth process for converting time tracker entries into PDF invoices. For accounting, I dived into plain text accounting and started using the Ledger format, which is widely supported by various tools and editors.

Transitioning from a GUI-focused workflow to a command-line-based one not only helped me quantify all the work that was going into different things but also made the whole workflow a lot smoother and ultimately more efficient. It was also throughout that period that I moved from Sublime Text to Neovim and from macOS back to Linux. I came to realize that the perceived comfort of nifty user interfaces – be it macOS, iOS, or web UIs – came at the cost of slowing down the actual progress of getting things done.

One metric that made the improvement obvious to me was mouse use. When I was still on a MacBook, my hand would glide down towards the touchpad every other moment, leading to all these micro-interruptions in my workflow. Leaving and having to find home again, especially on a keyboard that is notoriously bad to type on, introduces a miniscule but nevertheless noticeable disruption.

These days on Linux, however, I barely ever use the mouse to do things. My Neovim configuration uses set mouse=, my desktop environment – Sway – and even my browsers – Firefox and ungoogled-chromium – can be navigated with solely the keyboard (via Surfingkeys for the browsers).

All the source documents that I work on using all of the above-mentioned tools
eventually end up in a private Git repository – GitHub, Gitea, Radicle or a client’s own Git infrastructure – and be version-controlled and cryptographically signed. Critical documents are being encrypted using git-crypt. Depending on the platform, CI runners then automatically export the files into all sorts of different formats and upload them to various destinations/services for further use.

Today, most of what I’m doing will one way or the other end up in a Git repository and more often than not tracked via zeit. Using tools like git-quick-stats.sh, git-stats, and a few custom-built scripts allows me then to quantify the work that went into different things and get a relatively good overview of the time they required. Using that information I can guesstimate more accurately how long individual tasks (e.g. writing a post like this) will take on average and thereby plan deadlines accordingly. This time estimate also allows me to understand what task I could realistically work on and finish, for example within a two-hour window – let’s say, on a flight – and which would potentially require a larger window. Using this info I can line up things in a way in which they fit my day, rather than structuring my day around them, effectively removing big parts of the struggles of committing at least one impactful change per day.

Not only did what started as an interesting experiment push me into rethinking my workflows and venturing out into new territories; It also helped me grow and learn about myself and how I structure my days. This experiment is directly responsible for what you’re reading here – namely this website – as well as for the projects and other content that I managed to publish over the past few years and for many other improvements throughout my professional life. Committing daily has become something natural – muscle memory, so to say – and through that the habit of doing something meaningful on a day-to-day basis. With a setup that directly benefits this habit and makes it a pleasant experience, I managed to change it from a burden to something I truly enjoy doing.

I figured that the key to making this habit stick for me was to make it as efficient and comfortable as possible. I removed every piece of software that I detested using, I took time to optimize my setup, to learn new tools that would ultimately benefit this habit and I made my work environment really comfortable. I got into mechanical keyboards and built myself input devices that would feel exciting to work on, and that would make me look forward to typing. I set up a workstation and later a laptop that would function the way I wanted and not get in my way. I invested in other useful equipment, I set up infrastructure that works for me and I removed as many distractions as possible.

“Is this the ultimate recipe for becoming a 𝟙0x eNgInEeR?”, one might sarcastically ask. Clearly, no. In fact, all of this has nothing to do with being/appearing to be 10x, but instead with learning a habit that would ultimately improve workflow efficiency to a point where there is enough time left to pursue own endeavours. A habit that enables you to work on that IoT project that you had in mind for such a long time. Or on that piece of infrastructure you wanted to try out. Or that would simply free up enough time to just tinker around and build silly things.

Just like attempting to do 100 push-ups every day is something that will identify flaws in one’s muscle strength, condition, health and movement, by trying to commit at least one line every day, I was able to identify flaws in the way I was working and hence reconsider my work environment and workflow to make them more efficient. More importantly, I learned many new things along the way. And just like with the push-ups, the looks from an outside perspective after being consistent for five years are just the cherry on top.