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.
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:
What is outside of your immediate needs that you would find fun?
Which branch your field would you like to explore?
What would you wish to have come up on your own with?
What object would be cool to have?
What was the last thing a single person came up with that I admired?
Which off-the-shelf product does an okay, but not very good job?
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.
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.
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.
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.
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 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.
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
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.
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
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.
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.
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.
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:
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 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.
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.
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.
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. :)