Fabian Holzer

On unintended consequences

Consider the following scenario: an engineer demonstrates a problem and sketches a simplifying solution. The problem as such is accepted, but the proposed solution is rejected. The result is new work in the backlog that overhauls the existing functionality with something more complex. The new solution is slightly (but not essentially) more powerful. It maybe be better from a business/product management/sales/design perspective (what ever the metric of choice is).

An attempt of simplification, which results in bloat, is a perverse outcome from an engineering perspective. The engineering lense is of course not the only one, but a system that is to be maintained in the long run, surely shouldn't completely disregard it. For what could be a second-order effect of such a decision?

In the worst case: the creation of an incentive be silent. A motivation to stop contributing suggestions, and sweep issues under the mat. Such a potential breakdown of communication and feedback is a real threat for the quality and structure of any system. If a canary in the coalmine stops singing, miners know that it is time to get out.

Those who are tasked with creating systems would do good to be reflective of this, and if necessary take measures to counteract it.

Small things matter for accessibility

Can you spot the difference between bold, strong and a span with an font-weight bold? How about the difference between italic, emphasized and a span with font-style italic? If you do, you most likely either have opened your browsers' developer tools or you are using a screen-reader.

A colleague of mine recently reviewed a part of a UI component library I worked on with regard to accessibility. He found a line where I used a <b> tag instead of a <strong> tag and rightfully remarked that I'd better use sematic tags.

After the review, I thought about the reason I came up with the non-semantic markup in the first place. The component was developed against a designers' mockup, and when I derived the markup I translated the visual design in my head to the idea, that this part should be formatted bold, from that my mnemonic association I went straight to the <b> tag.

Satisfying a specification from a mere typographical point of view is not enough. What makes no difference for visually unimpaired people very much matters for users of assistive technologies.

Write down your makers bucket-list

Few things are certain in life, among them is the fact that you only get to create a finite number of things in your life. And if a large portion of your time is already allocated, it becomes important to prioritize rigorously, so that you waste none on thinking about what to do instead of actually doing something when you have an hour to spend on something constructive, on creating, on doing a project of your own. In the same manner that a lot of people keep a list of places to visit and things to experience before they join the choir invisible, it would be a good idea to have your makers bucket list ready upfront.

Sure, I‘d be hard pressed to come up with a category much more generic than „Making things“. Yet it rules out mainly consuming activities (e.g. reading books, visiting an exhibition, traveling, etc.). Those should go on different lists, but what to actively include definitively needs some thought. When that thought enables you to focus once you do have time to allocate, it would be well-spent. Dabbling around without a concrete goal likely results in spreading yourself too thin and the top-most item of a maker‘s bucket list should act as a deterrent to that kind of behavioral pattern.

A few questions to ponder, when creating your list can be:

Personally, I‘d also love to read such lists on the websites of creative people. I have to admit, my own list is not in the best shape. Feel free to call me out for being a hypocrite if I don‘t put mine on here some time in the near future. But since I see my current top-most item staring at me, and I‘ve got a few minutes left, so I know what I‘ll do after this little piece is published.

Content - fast and slow

Being a employed in some kind of role that could be classified as knowledge work implies a necessity stay on top of things. And the channels of today create a current of content in which it's hard not to drown in. That hardly is a surprise, when thousands of intelligent, highly-paid peoples' personal incomes are tied to how long you stay on a platform, how much you engage and how many ads you consume. Those platforms are products which - by design, not by coincidence - resemble a slot machine. They want to capture and keep their users' attention systems. And the creators of such platforms don't have to account for the detrimental effects on your ability to concentrate, focus and learn.

The polar opposite of these walled gardens are the many websites (mostly still operated by individuals) that still offer to subscribe to their content via a feed. Feeds empower the readers by decoupling the content consumption from the platform. No algorithm orders it for you, just a simple timeline. And a much slower one for that.

I have roughly the same number of feeds in my feed reader as I follow people on Twitter. Yet, I refresh the former manually once a day and have maybe a dozen articles in the inbox, spending a mere five minutes on the latter I'm being nudges to refresh and see more than fifty new items. Sure, your mileage may vary and the the plural of anecdote isn't data - but that's roughly a three orders of magnitude difference in items that are presented.

With regard to that, I overhauled my own RSS feed. While the first solution was a fine exercise in Satisficing, it had limits. It only delivered the last five articles to new subscribers and didn't serve the full content. The new one does all that and doesn't depend on a third party to create it.

Don't 'cd' to change directory

We all have only a finite number of keystrokes left and should use them wisely.

I don't know how many years I typed "cd" in the terminal to change my directory, until I learned that the shell can interpret anything you type, which is no command, to execute implicitly as argument to cd. I enable this by setting an option, with adding the following line to my .bashrc:

shopt -s autocd

I hope it might save a few keystrokes for whoever reads this.

The lazy webmaster's way of providing a RSS feed

I consciously setup my website as minimal as possible. It's liberating to have a the content immediately in a representation that renders good enough. Yet I'd like to offer is a RSS feed. I could of course write it manually, but that would become a chore rather soon. A small tool chain could also work, but I would lose the feeling of immediacy.

Having a regular markup structure made it possible to an external service derive the feed automatically. So, here you go.

Avoid collecting without acting

The amount of information which is thrust upon you is orders of magnitude larger than the capacity to absorb and make use of it. This can lead to a destructive habit, called the collector's fallacy. This fallacy is a form of self-deception. It makes you feel like you are progressing where you are actually stalling. It leads to wasting your precious time on something that's not worth it.

To avoid falling prey to the collector's fallacy, you need to work actively with the collection you have. Introduce some form of rate limiting: Don't buy a new book before you finished one. Don't bookmark another article before you haven't read (or at least deleted) one of those you have bookmarked.

If it would have been important, you would have already read it. Its content likely won't be lost. There are search engines and even in case the of uncool urls there's still the wayback machine.

On digital gardening

On content-focused websites the prevalent pattern for the organizing content is the blog format: a list of articles/posts presented in reverse-chronologically order. Amy Hoy wrote a criticism of this organizational pattern, which found some resonance. So nowadays - as everything old is new again - a bunch of personal websites started to conscientiously style and organize themselves as digital gardens.

Now, there is no copyright to that term, but one overarching concept I see and very much like is, that articles are not seen as something that is written once and then finished after the publication, but as a seed which might grow into something that eventually becomes evergreen, more akin to a well-organized public (read-only) wiki.

I haven't yet figured out how I will this page in the long run, currently it is much more a blog than a garden, yet I find the idea to go back to existing article and enhance them over time very intriguing.

On Satisficing

Every day we need to decide many things and many of those decisions are of minor importance. Lots of trivial decisions to make can create neural fatigue and lead to unproductivity and loss of focus.

Herbert Simon coined the word satisficing for a strategy that concentrates on getting an option that is good enough, but possibly not the very best. Satisficing is one of the foundations of productive human behaviour because it avoids wasting time on finding improvements that are not going to make a significant difference.

Yet, satisficing should not be applied to very high-priority endeavours where much is at stake. There pursuing excellence might actually be the better strategy. But those are few and far between. To have the capacity to make them happen, satisficing is an imperative.

The benefits of a classless approach to CSS

I first experienced the web in the mid-nineties. At that time CSS wasn't really around and even if the first browsers supported it, many pages were just text-heavy unstyled documents. Today you would consider such an approach as luddite, yet since the H in HTML stands for hypertext you could argue that keeping styling concerns out of markup is the purest form of authoring a document for the web.

Today's default choices are quite distinguishably different from that. A minified version of Bootstrap 4 ships 117kB. As a comparison: I would have to write about 60 to 80 additional articles on this site to match that weight with an equal portion of content. And while at it, I'd have to clutter my markup with classes over classes. There are of course slimmer css frameworks than Bootstrap, but nonetheless, my main motivation is in the writing down useful things, therefore I decided to approach the styling of this site quite radically with classless CSS. All styling decisions are taken by CSS which is targeted by element selectors only. If I'd bother to minify it, that would clock in little over half a kilobyte, and even unminified it is less than 1% of bootstrap.

But page weight isn't the most important thing. A classless CSS approach enables me to author content without intermediate representations (e.g. the Markdown flavour du jour in combination with a static site generator) directly in HTML while still allowing me to focus on the content.

Add expiration dates to TODO comments

When I spot an idea for a non-trivial refactoring, I often add a TODO comment. The ideas which are not acted upon immediately are often, but not always, valuable. A problem is, that they tend to pile up without being resolved. In a mid-sized real-world code base that I maintain the ratio was roughly one such comment per 100 SLOC.

Therefore I decided to add a reasonable explicit expiration date to any such TODO (some 4 to 8 weeks in the future). When I encounter a comment that has expired, deleting it is a perfectly viable cleanup. The code structure obviously was not so bad after all, or else I would have put energy into the refactoring already.

Is it worth my time?

About twenty-five centuries ago Hippocrates of Kos famously stated that life is short, while art is long. Most knowledge workers can very much relate to that. While the body of knowledge in a field is ever growing, the time available to an individual for deliberate learning activities is limited severely.

I use the following criteria to assess if a topic is worth spending my time on it.

Longevity and Transferability

I prefer evergreen knowledge and focus on topics that are not bound to a specific technology. As a general principle, anything with a version number attached to it should be treated with caution. But: Using a specific technology (even if it's non-mainstream or dated) to illustrate a concept is fine.

Applicability and personal usefulness

Many concepts are long-lived and transfer well, but when the chance of applying them is rather slim, then other things should take priority. Not applying something is detrimental to retention and time is too valuable to spend it on learning something that falls into oblivion.

As a caveat: To some degree, it cannot be known which topics will lend themselves to be applied to problems presented to you due to external needs and interests. Chance favours the prepared mind.

Immediate necessity

Not everything which needs to be learned will be a beautiful timeless idea. Sometimes I need to grasp a poorly documented functionality of some obscure technology to get a task done. It comes down to a judgement call, which is a matter of experience and confidence, how deep to go. It can be beneficial to build a real understanding instead of just copy-pasting from the web (which might get the job done but comes at some loss of control).

Personal interest and commitment

There are also a few topics and technologies, to which I'm committed deeply. I consider it worthwhile to keep up with them, even if the criteria laid out before are to some extent not met. I also regularly reassess my commitment to the topics.

On the risks of quick fixes

Every software system has its issues. Usually, at any point in time, there are many ideas for new features, enhancements, as well as fixes waiting to be implemented. A lot of them are indeed solvable with a few lines. But many of those small tasks are wasted work because they work around a problem, which could and actually should be solved by a slightly larger change, that requires some - but not very much - more effort.

If the order of development is optimizing for throughput, the so-called quick wins and quick fixes will be prioritized and the effect results in a well-known problem in scheduling algorithms: starvation.

Resource starvation is a problem encountered in concurrent computing where a process is perpetually denied necessary resources to process its work.

In this case, the process is the task in the backlog, which would be the fundamental solution to the problem, and the resource is the allocation of time to work on that task.

Steve McConnell formulated yet another risk of those quick wins and fixes in his "Software Project Survival Guide" (p. 127):

The problem with quick and dirty, as some people have said, is that dirty remains long after quick has been forgotten.

The Second-System Effect - Excerpts

The following is an excerpt from chapter 5 of "The Mythical Man-Month" (1995 edition) by Fred Brooks.

If one separates the responsibility for functional specification from responsibility for for building a fast, cheap product, what discipline bounds the architect's inventive enthusiasm?

The fundamental answer is thoroughgoing, careful, and communication between architect and builder.

The architect has two possible answers when confronted with an estimate that is too high: cut the design or challenge the estimate by suggesting cheaper implementations.
For it to be successful, the architect must
  • remember that the builder has the inventive and creative responsibility for the implementation [..]
  • [..] be prepared to suggest a way of implementing anything he specifies [..]
  • deal quietly and privately in such suggestions
  • be ready to forgo credit for suggested improvements
The builder will counter by suggesting changes to the architecture. Often [..] some minor feature may have [..] large costs when the implementation is worked out.

Brooks considers that, the first system which an architect builds is potentially clean. As the system is designed, there are ideas which get stored away to be used "next time". All the frills and embellishments which were kept out of the first design, often make it into the next system. Therefore, he states:

The general tendency is to over-design the second system [..]


The second system ist the most dangerous system a man ever designs.

Basic system assumptions can change. These changes make some techniques obsolete. The tendency to refine those can be another symptom of the second-system effect.

An architect cannot skip designing a second system, but he can be conscious of it hazards. Self-discipline must be exercised to avoid functional ornamentation ("gold plating") and sinking time in obsolete areas and functions.

Two classes of disagreement

I learned about the concept of two classes of disagreement from an anecdote in Michael Hiltzik's book Dealers of Lightning on the history of Xerox PARC.

He describes strong tensions between Robert Metcalfe and Chuck Thacker, who are both pioneers of the Ethernet and personal computing. Hiltzik quotes Bob Taylor, the manager of PARCs computer science lab, who introduces what he calls a "Class One disagreement" as the root cause.

According to Taylor, two people have a Class One disagreement when they disagree and neither can explain to the other's satisfaction the other's point of view. When each person can explain to the other's satisfaction the other's point of view, it's a Class Two disagreement. The latter enables people to work together, even if they disagree, while the former is destructive.

With that framework in mind, when you "agree to disagree", it would be wise to ensure that it is on a Class Two disagreement.

Can you ever know enough about people?

I recently finished 100 Things Every Designer Needs to Know About People.

Susan Weinschenk has compiled a lot of research into a hundred short essays. The book covers a lot of ground with topics ranging from perception, over how human memory and thinking and decision making processes work to how humans tend to deal with errors.

The book doesn't require any prior knowledge. It is very digestible and actionable. The chapters are to the point and contain a condensed list of key takeaways. No reading order is required. Being very broad in topics makes it rather hard to summarize - yet cheapskates and people in a hurry could probably even get some insights out of simply reading once through the table of contents.

All in all: a recommended reading.

It's been a while...

Many, many years ago, I maintained a website. It was fun. Then life got in the way, domains expired, and that site fell into oblivion.

Meanwhile, I made a profession out of what was once my hobby. Earning one's bread doing what one would have gladly pursued free, for passion is a privilege granted to only a fraction of the human race, as Fred Brooks rightfully stated in the epilogue of his seminal Mythical Man-Month. So, by and large, I consider myself a very lucky man.

Yet, over the years I lost track of the passion, the fun aspect slipped away a bit. This, therefore, is an attempt at rekindling it. For now, in the shape of a single file, filled with random musings of some weird dude who writes raw HTML.

Just for the fun of it. :)