Journal 4: The last one and a half years

I wrote my last journal entry in March 2019. While I'm hesitant to write journals more frequently again, I would regret not writing down what happened in the last one and a half years.

Let's quickly recap where I stood back in March 2019. I was busy improving the performance of a web application. For the subsequent weeks, I planned to work on my business website, and I was about to start a mid-sized client project.

Work on my website

In terms of working on my business website, the improved version is live since then. But it took way longer than I wanted. The biggest reason for the delay was that the site's CSS became unmaintainable. Unmaintainable in the sense of changing CSS for one page could easily break the style and layout of others.

As a consequence, I decided to up my game in terms of writing maintainable CSS. I have always found my way through writing CSS. I even enjoyed it most of the time. But writing CSS in a maintainable way is a different story.

The reason I allowed myself to go deep into that topic was simple: CSS is, in contrast to many other technologies these days, not going to go away in the next few years. CSS Philosophies, in which I describe the different schools of thought, is an article that came out of my learning.

For my website, I ended up using the not so well-known CSS framework inuitcss initially started by Harry Roberts. I chose to use it because I learned so much from Harry's resources around that topic. Quite naturally, his wisdom "shows" in the framework. Concerning resources, I'd like to recommend the articles on his website and CSS Guidelines. For even more resources on that topic, please take a look at the list on my blog.

Quit teaching

It was also around that time when I held my last exams as a lecturer for server-side web development at FH Joanneum - Software Design.

That it took so long to finish a course – it should have ended at the end of February – is just one reason I decided to stop teaching (at least for a while). In general, I have mixed feelings about teaching. I learned a ton myself both technically and from a personality perspective. But to be honest, it was also underpaid, and teaching was one of the most exhausting works I've done in the last years.

If I decide to teach again, I'd probably choose a different course because you learn so much yourself about the topic itself.

The mid-sized project starting in April 2019

A few notes on the mid-sized project I was about to start after the last journal entry.

Like most of the other apps I maintain on a long-term basis, this one is also a legacy web application. One core feature request was to enhance a form users mostly fill out on mobiles. I decided to use traditional server-side rendering with a little bit of vanilla JavaScript for the form's dynamic parts. I also decided to stick with HTML5 form validation.

And you know what? Users love it. Can you imagine doing something like that without React, Angular, or Vue? Because some peers recommended me to pull in Vue because of the dynamic parts. There would have been so many disadvantages. I would have added the whole Vue build process. Also, I would have to keep Vue updated year over year. It would have required the users of the app to download huge bundles of JS just to fill out a simple form.

Don't get me wrong about client-side frameworks. They do make sense for real apps in the browser. However, developers overuse them these days.

Contracting from June till November

Starting in June, I contracted around twenty hours a week for a German startup. All remote, of course. We were developing a mobile application. I learned a ton of Vue and was able to apply a lot of my newly gained CSS knowledge. I also gained some experience in writing Ruby.

Thinking back, it was a healthy amount of revenue, and I learned a ton. But the flipside of the coin was that I didn't enjoy the daily stand-up calls and the many additional meetings. I also didn't enjoy the code review culture. The team wasted so much time with nitpicking. After this engagement, I can definitively say that code reviews can be toxic. I agree with what Patrick McKenzie said on Twitter just recently.

A somewhat failed project in the accounting realm

DATEV is one of the most popular, if not the most popular accounting software in Germany. From the second half of 2019 until February 2020, I was pleased to develop the integration between a custom ERP system and DATEV. The goal was to transfer invoices from the customer to the accountant.

The initial estimate (not mine) was way too low. My partner asked to join for implementation when the project was already running. In all honesty, it ended up as a failure. Implementing the interface from a technical point of view wasn't the problem at all. The main problem was that the interface didn't have the capabilities that the project team assumed in the beginning. It was stuff like the invoice number scheme in the custom ERP being incompatible with DATEV that ground the project to a halt. Needless to say that I spend half of my time on the phone sorting this stuff out – work that should have been done in the pre-project phase.

Let's go on to more pleasant stuff.

Taking over the maintenance of a Rails application

Around August 2019, I took over the maintenance of a Rails application. An already long-term client of mine operates it. The app is interfacing with another system I have already taken care of for a few years.

After one year of supporting it, I can say I don't regret it despite Ruby and Rails not being my natural habitat. Sure, me being more fluent in Ruby could help. But that's manageable and relatively easy to overcome. It's the decisions the former maintainers made when developing the software that poses a bigger challenge when overtaking an existing system. Thus, unless it is C++, I barely would shy away from a web app written in a language I'm not so familiar with. Because in maintenance mode, I claim that the language isn't the core challenge. It's the business domain itself, and it's the architectural choices and code quality that matters more.

Moreover, a lot of parts in a web application are roughly the same every time. You have an SQL database, HTML, CSS, and JavaScript. Sometimes you have the Web-MVC architecture, sometimes not (hello PHP). Hopefully, the original creators decided to use some template language. You have server-side sessions and cookies, and you have the HTTP request-response cycle that hasn't changed in a few decades – and probably won't for a few more.

Deploying the refactored version of my website

As already mentioned in the beginning, I started to work on refactoring my website in the second quarter of 2019. While the visual appearance stayed roughly the same, I almost completely replaced the old CSS.

Overall it was a worthwhile thing to do because of how much I learned about maintainable CSS. However, it took me way too long. I deployed the "great refactoring" almost one year later on February 14, 2020 (Twitter thread with a few details).

Why did it take me so long? First of all, I invested a lot of time in learning maintainable CSS. Then, ongoing client work. And last but not least, a lot of busy months caused by a major non-business issue I'll tell you about later.

Speeding up my websites with cache busting

After deploying the refactored version, there was still one thing left that already bugged me for years: My sites hadn't had a proper asset caching policy. To be precise, I always wanted my websites to do cache busting.

First, I thought a smart shell script combining sha1sum and sed would do the trick. But boy, was I wrong. If I wanted cache busting, I needed to tweak the site's build process. Adding something like webpack would have been an obvious choice. But since I am averse to adding dependencies and complexity, I moved on to add asset fingerprinting (the foundation of cache busting) to C-3PO.

Mostly working in legacy codebases these days, it was refreshing in many ways. I enjoyed doing Java again probably because the last couple of years were full of dynamically typed languages such as JavaScript, PHP, and Ruby. I'm proud of the automated tests that came out of this—a big shout-out to the Spock testing framework.

One particular highlight is that unlike many frameworks, static site generators and build tools, no special syntax is required to make asset fingerprinting work. Although my solution doesn't cover all possible asset types (e.g., video and audio) and ways to reference assets, the nice outcome of this approach is that I haven't had to touch any source files of my sites to get this going.

Tech stack maintenance

Since my last journal entry in March 2019, I also had quite something to do with upgrading tech stacks. I migrated two business applications from PHP 5 to PHP 7. In addition, I had to decide what to do with a legacy Rails app.

One thing that sticks out: It's less effort and thus cheaper to upgrade applications when base technologies are used. In contrast to that, it would be far too costly to bring the Rails application up to date.

In the latter case, the initial development might have been cheaper. But I doubt it is when looking at it after a few years in maintenance mode. Thus, I'd say these systems have a higher chance of ending up being operated on outdated platforms (i.e., outdated operating systems and everything that's on top of it).

The non-business distraction from September 2019 till February 2020

Besides Covid-19, another major non-business distraction ate up a lot of my time: My wife went self-employed again as a hairdresser.

Because of that, we had some big-time construction work going on in our house. We (family and friends) managed to do quite some work on ourselves, which, of course, was detrimental to my business.

Nevertheless, if I had a regular job, we wouldn't have been able to get done so much ourselves. By the way, it was my pleasure to also design and build her website.

Although I could call this time "the lost months" business-wise, our lifestyle improved significantly.

Smaller stuff throughout the time frame

Besides all that, here's a list of smaller stuff worth a mention:

• I developed a small script to calculate my income accurately. It's harder than you think, see some discussion on Twitter.
• I supervised a bachelor thesis on the topic of web accessibility. A little anecdote: Before the final exam, my student's second lecturer asked if I would be the next candidate. And after my student's exam, the secretary congratulated me too on passing my exam.
• Brought an ancient Typo3 website back online by migrating it to a new server.
• Developed a neat little cronjob to automatically backup the photos of my phone.
• Mounted a self-designed company sign in front of our house. Actually, that's mandatory in Austria, according to wko.at.

How is business right now?

Looking at the company sign, some might recognize the changed tagline. While the website to this date still says "Webentwicklung · Datenvisualisierung", the company sign already says "Individuelle Software-Lösungen".

That's the new trajectory of my business, meaning that I'll put my data visualization services at rest.

Here is why: When I started in 2016, specializing in data visualization (besides offering web development) was a leap of faith with moderate success. I had to learn that data visualization is a tricky market. Data visualization is often seen as "just a skill" embedded in a broader context such as front-end development. Prospects don't even know what data visualization is. And if you truly want to be successful with data visualization, you've either got to teach courses or be one of the few data visualization designers that win prizes at the Information is Beautiful Awards.

In retrospect, specializing in data visualization helped me to land quite reputable clients. They accounted for approximately half of my revenue. Also, I now own a rare and valuable skill that might come handy in the future.

But the last years also showed that I'm happiest when I'm directly serving small to mid-sized businesses. There's a couple of reasons for that, but the one sticking out is the immediate feedback from users when my work helped their work become a little bit easier.

If you want to help me, I'd be very thankful for introducing me to businesses owners who look for a reliable maintainer of their custom business software.