As my family and I are looking forward to move into a new home in January, the next weeks will be filled by throwing out junk that accumulated over the years, packing up our belongings into boxes, looking for new furniture etc.pp. and I'll likely be hard-pressed for time to write — therefore, as a short bleep before I go radio silent, I want to cluster some ideas that I'd like to pick up, once I have a little more time at my disposal again.

• I'd like to finish a draft about the implementation of the little web component that I mentioned previously. This one has the strongest chance to still get done this year.
• There's a pile of scattered notes on microfrontend architectures, that have accumulated over the nearly eight years that I'm working on that topic professionally. I'd like to consolidate them with my personal experience and opinions on it. As that might get out of hand and maybe deserves a longer treatment, I'm thinking about experimenting with some kind of preplanned article series.
• Earlier this year I mused about the great books of software engineering, but the article was a bit unconclusive. I will have to pack up my library soon and thought, when I unpack the books, I'd like to do some reviews and summaries on a selected few items.
• Then, and this one is a bit of a moonshot topic, earlier this year, I took some interest in the current state of rapid application development. I'm still occasionally asking myself why, a quater of a century after the final release of Visual Basic 6, nothing has emerged that lives up to its developer experience, when it comes to making UIs and wrapping them up with a datasource. I have a some hypotheses about that, though...
• The quality of the major search engines have deteriorated over the last years to the point where their results are basically garbage. The rise of LLMs has, if anything, accelerated their enshittification. Plus ça change, plus c'est la même chose... I'd like to dive into the topic of curated web directories and explore whether there are lessons to be learned from the demise of Yahoo and DMOZ and if smaller directories could somehow become (again) a backbone for finding information on the web.

If any of you'd like to talk about such stuff, feel free to shoot me a mail. Until next time, take good care :).

I've recently made a few accessibility improvements for the site. For one, I finally got around to add a skip-to-content link to the navigation, mostly following along an article from CSS Tricks, with very few tweaks. And I replaced the sorttable script for the tables of content with a custom-element I wrote, in order to make the table columns also sortable via keyboard navigation. On the same note: some time ago I wrote that small things matter for accessibility, which as a general principle is true, but I recently learned that the example which triggered the article is not correct anymore, because bold and italics actually aren't read by screen readers after all. That was a feature of the NVDA screen reader, but not a very popular one, therefore it got disabled by default. Generally there is no audible distinction between i/em or b/strong tags for screen reader users.

Also three weeks ago, I had the pleasure to participate in my first post-pandemic in-person developer event (which incidentally has been my last pre-pandemic conference as well...), the unKonf in Mannheim. The unKonf is basically a barcamp, but it is traditionally opened with a keynote, which this year was given by Uwe Friedrichsen on the topic of sustainability patterns for IT. One fact that suprised me was that the global IT landscape causes more greenhouse gas emissions than the traffic of the worldwide logistics industry. I can only recommend the slide deck, which is filled with tons of interesting and important pointers. One take-away was that measuring and visualizing resource and energy consumption of a system is a necessary first step to move towards a more sustainable IT. Apart from that, there were many other great sessions and the "hallway track" made me realize how much I actually have missed to talk shop (outside of my actual shop).

Since this week my parental part-time is over, I'm back to working my standard 40 hours. With so much of my time to available to the company again, sure enough somebody deemed it a good idea to assign a training course on GDPR to me. Ok, in all fairness, that course was probably assigned to just about everybody in the department, in order to tick a box on some spreadsheet, for you know, a bit of corporate cover your ass can go a long way sometimes, but I'm digressing... Anyway as a good compliant employee, I started the course, hoping for the best. It turned out to be gamified, in - I kid you not - the form of detective's story and the look and feel and a UX of a badly programmed game, that reminded me very much on the numerous hobbyist game from the hey-days of Flash...

But on to a more serious matter of user and developer experience. My son is currently digging a bit into programming with Scratch on the Raspberry Pi. Following along a tutorial, after making the figure on the screen do some funny things, tweaking and exploring here and there, he got to the point where he had a little game that he wanted to spice up by checking for a game over condition.

So, a quick test: the player has lost their last life, tell me, why is the if branch not executed?

The logic looks quite sound, doesn't it? Perhaps a different notation helps to spot the problem faster:

lives--;
if ("lives" < 1) {
    console.log("Game over");
}

So, what happened? While following the tutorial he didn't drag the variable as a block, but typed it out into the field, which makes it a string literal (a legitimate thing to compare something with). Referencing the actual variable looks like that (not quite an optical difference like night and day):

As block-based programming languages have found their way into school curricula as well, I was wondering how many kids' enthusiasm for computing might get curbed by such little matters of affordances that cause confusion or frustration.

Last, but not least, I added two items to the site: a client-side full-text search (powered by lunr.js) and a Colophon, because I always like to read about the website setup of other people for inspiration and also to give credit where credit is due to a few libraries I use, which were created by people who generously open-sourced them.

So, after I've managed last week to switch over to my custom SSG for building the website, this week I spent time to play around and explore a few things, that I would not have done, if I needed to maintain them manually.

The first addition, inspired by Daniel Fedorin, is a content graph, which visualizes how connected my posts actually are. As it turned out, not that much and even less than I had thought. A lot of articles are "orphaned" (meaning, not linked to internally). The second, less pretty, but probably more useful, outcome are automatically created backlinks for each article. The last little new thing is syntax highlighting with Prism, which yielded the philosophical question: does my css still count as classless, if the classes in the markup are only created programatically?

To sum up, what started out as the musing of a "weird dude who writes raw HTML", is moving up on the x-axis of this chart towards the static gen basin. For as, much I would like to pretend otherwise, tools matter at least a little bit.

For those who read my site via the feed, this is also the reason why some old articles might have popped in your reader up all at once. The old script was heavily depending on a certain regular structure of the directory, and I would have needed to run the rss generation script for each category and then somehow properly merge the resulting xml files, which I found to be too tedious, so the weeknote category of the site was left out (which was another driver for the rewrite).

There is a great xkcd about how much time you may spend on automation before yielding negative returns. If all the tedious stuff took about 5 minutes per post and I'll write once a week, about 21 hours of programming amortize themselves over the course of five years. But even if programming a custom SSG turns out to be uneconomically from the point of timesaving, it still was fun, which is enough reason to do it. I've put both the the generator, which I named intertwingle, as well as the source of my website on github.

On to a completely different subject. This week at work, I heard that upper management is looking into establishing tools that create metrics from our repositories and issue tracker to be reported to them. I don't know whether it is merely a conincidence that a month or so ago an article about measuring developer productivity by a big management consultancy made the rounds. Kent Becks response in two articles (Part 1 and Part 2) is quite good. In a debate on Linkedin Kent also delivered a soundbite, that sums it up up nicely: McK is offering false certainty to replace honest ambiguity. Anyway, I think it is rather obvious why advice on software engineering from a company that mainly sells political capital and powerpoint presentations (even if the latter is Turing-complete...) needs to be taken with more than just a grain of salt.

And as I was in digital clean-up mood, I also pruned my wiki. Consolidating notes and throwing away drafts that didn't lead anywhere left it both over a hundred entries smaller and more useful to me than before. Sometimes less is more.

At home I don't have so much uninterupted leisure time (emphasis on uninterupted) available, which means for most books of my choice I need quite some time to get through. But last week I managed to read Rolf Dobellis Die Kunst des klugen Handelns ("The art of acting wisely" - don't know if an english translation is published) within three days. It is about cognitive biases and errors in thinking and consists of mercifully short chapters, which fitted quite neatly into many fractured timeslots, that would otherwise have been rather dead.

Also I'm really starting to feel jaded by Substack based "blog-letters" (or how shall one call nominally newsletters with fully accessible public archives?). I hate it when the reading flow is interrupted by their annoying overlay, which is added very gradually while scrolling down, so that while you read, you know that if you want to continue, you'll have to dismiss the same damned dialog all over again in a few seconds. It totally ruptures concentration and flow. Yeah, I know, creators want to capture their audience, and free is hardly ever really free, we all have to pay our bills, but this particualar interruption in the middle of articles starts to feel for me like being hit with a hammer. There is ample evidence that forcing the brain to make decisions leads to cognitive fatigue and depletes the abilities for self-control. I'm picking on Substack here, because they are currently very popular in my online bubble, but the same could be said about many other websites and platforms. I find myself wondering, if there were a filter mechanism for all sites that apply practices that are in the end hostile to my brain, would I actually be missing out? And even if that were the case, wouldn't I be better off anyway?

It is also somehow true on a greater scale of things. Currently Google is attacking the open web with a proposed API that will serve to stifle browser competition and lock out users who don't like to be surveilled by ad-tech. And the best defense I can currently think of is also not technical, but regulatory politics (as this also constitutes a crass violation of GDPR). I know, they ditched "Don't be evil" as motto years ago, but it is astonishing how far they want to go to own your eyeballs in order to extract ad revenue.

So this is the reboot of the weeknotes. Maybe this time the streak will last more than six weeks. Chances aren't bad. My little daughter has adapted well to kindergarten, still for the next three month I'll work part-time only, so I may have a little more time to spare than otherwise.

Recently I dove into the topic of full-text search and information retrieval. I've toyed around with lunr. For a small codebase (around 1800 SLOC) lunr has a good deal of great ideas in it. I've written about how I gauged the code on a high-level, but if time permits, I'd also like to do some deeper dives into the datastructures and algorithms that are used.

Also I'm currently making a static site generator custom to my needs as a replacement for the messy scripts that I currently use to build this site. The sad state of that rewrite is, well, a text-book example of the Second System Effect. So, with that, I'll use the rest of my free time today to try to get it to feature parity with my messy (but working...) scripts.

What I like to do, in order to get a high-level overview and an idea on which parts I should focus, is to look at the SLOC (source lines of code) metrics. Now, this metric has a bit of a bad reputation, which stems from the days when it was used by the wrong people for the wrong reason (an in: by managers to measure developer productivity). I don't want to waste too much effort on elaborating why this is a bad idea, just so much: that is a textbook example of Goodhart's law in action.

Anyway, SLOC is easy to understand, quick to gather, agnostic of programming language, and a pretty good proxy for complexity. There is even research that suggests, that SLOC and the more complicated to measure Cyclomatic_complexity metrics, actually measure the same property.

There are several tools available to do the actual counting. I like Al Danial's cloc because it has a lot of options and output formats available. Curtis Gagliardi's loc claims to be two orders of magnitude faster than cloc, but on small to mid-sized repositories, the execution speed is not really a limiting factor, the missing JSON output option on the other hand is, .

Having said that, the output of running cloc on lunr is the following:

-------------------------------------------------------------------------
File                                  blank        comment           code
-------------------------------------------------------------------------
./token_set.js                           57            146            212
./query_parser.js                        49              0            206
./index.js                               56            239            197
./stemmer.js                             27             25            171
./builder.js                             45            153            162
./query_lexer.js                         38             18            153
./stop_word_filter.js                     4             30            131
./pipeline.js                            33            139             95
./vector.js                              26             76             94
./set.js                                 22             42             69
./match_data.js                          16             33             58
./query.js                               21            111             56
./token_set_builder.js                   15              2             52
./utils.js                               10             44             38
./tokenizer.js                           11             29             36
./field_ref.js                            7              0             21
./token.js                                4             39             15
./lunr.js                                 4             31             14
./idf.js                                  4              8              9
./query_parse_error.js                    1              0              7
./trimmer.js                              2             19              6
-------------------------------------------------------------------------
SUM:                                    452           1184           1802
-------------------------------------------------------------------------

But as a wall of text and numbers is not the most intiutive representation, I exported the cloc result to json (cloc . --by-file --json) and adapted the template for circular packing from the D3.js Graph Gallery to plot the output of cloc. Also, I did a second plot, where SLOC are adjusted by a factor determined of how heavily the code is commented (with the reasoning that a lot of comment indicate complex logic). The output looks like this:

Keep in mind, the intention of it was to be a quick gauge of a small code base. Which means it is not too economical to play with visualization features too much. One can see that the core data structures (drawn in red, especially index and token set) account for over 20% of the code base, but also the query language (in light green), which actually is a mere convenience feature and would actually be omittable, make up a similar portion. Also notably, the stemmer, which is a crucial module to actually build the index, is a inlined third-party implementation of Martin Porters stemming algorithm. In the second visualization this gets dialed down in size a lot, because the implementation does not make much use of comments, although it is very dense, full of regexes and short variable names.

But the fact that a map mustn't be confused with the territory doesn't render maps useless.

Something that I regularly think about, almost everytime I select something to read through for furthering my knowledge in my field, is if there is something like a canonical set of reading material.

On the other side of the Atlantic ocean there is a concept of a liberal arts education that is called Great books program, a four year college degree that solely consists of studying a canon of Western philosophy and literature, without a major though of its immediate utilitarian value.

As much as I find this notion of education to be romantic, I won't suggest that it would be a blue print for a technical discipline like software engineering, if only one would come up with the right set of text books and papers as canon. But I think it would be helpful, especially for those who are not at the beginning of their career anymore and outside of a formal degree program, to have some structured guidance, to maximize the value you get out of the time invested. The higher the delta to your current knowledge the better, or with the words of Alan Kay: Perspective is worth 80 IQ points.

When I searched for reading lists and comprehensive bibliographies, I stumbled over a list of Seminal Papers in Software Engineering published by members of the faculty of CMU. In the introduction they write: To understand the context of current research, it is essential to understand how current results evolved from early fundamental papers. These classic papers develop timeless ideas that transcend technology changes, and the ideas embodied in their solutions often apply to current problems. Of course, you have to keep in mind that this list was compiled in the context of post-graduate education and is a means to an end (informing the original research the students are supposed to do), which imposses a limit in size.

Imagine somebody who does not want to go down the PhD path and has already written a fair portion of software. Which techniques and ideas should such a person study? What material would sustain the remaining 20 to 35 years of their working live in software the most? I suppose the "Great Ideas in Software Engineering" would not only comprise of books and academic papers, but also certain code bases, blog posts and probably even recordings of talks. It would inherently have to find a balance between practical and idealistic aspects.

As I didn't manage to find a compilation of material that goes into that direction, I am still not sure how much merit the idea of such a curriculum does have, yet I also cannot get rid of the feeling, that many great ideas are already out there, burried under a lot of noise, waiting to be (re-)discovered.

No website is guaranteed to exist for ever, not even for a timespan that significantly outlives its original author. Keeping one up and running is, although very cheap, not entirely free. But even loss-leader offerings like github pages or the aws free tier are payed for by somebody. And that somebody might stop doing so for many reasons.

The web is a young medium, yet in the three decades an incredible amount of content has been created and discussed on it. Some of which had deep and lasting impact. Yet, there is a high risk that a lot of what was going in and on the open web is vanishing at an alarming rate without a trace from our colletive intellectual and cultural history.

Take for example Ward Cunningham, the inventor of Wiki (both the concept and its first implementation). The WikiWikiWeb/C2 Wiki was frozen in 2015. Its content is in read-only mode ever since. Since then Ward is remodelling its software basis, but in an issue on github he wrote:

Perhaps I should explain why wiki worked.

I wrote a program in a weekend and then spent two hours a day for the next five years curating the content it held. For another five years a collection of people did the same work with love for what was there. But that was the end. A third cohort of curators did not appear. Content suffered. I had visualizations. I could see it decay. That is what I mean when I say that the those of good will have passed. A security engineer has compared the open internet to the summer of love. It was neat while it was happening but it is over.

I find this stance disheartening, albeit understandable. And the c2 wiki is at least still readable. But for how long will that remain so?

There are many, too many examples of content becoming inaccessible or even destroyed on a whim. The highest risk bears everything that is hosted by commercial entities for "free": think for example of Yahoo killing Geocities. This free (as in beer) is penny-wise and pound-foolish. Single copies are single points of failure and hopeing somebody will keep the lights on is not a viable backup stragegy.

Speaking of backups: One of the very few organization that tackles the problem of preserving the web is the Internet Archive. Sadly, it recently lost a lawsuit against big publishers, which has the potential to completely destroy it financially. And it appears that there is no meta-backup strategy in place.

What can an invidual do? Those who create websites might want to consider to follow Jeff Huangs approach and design their websites to last. Probably another good idea would be to explicitely use a license for free cultural works to allow content to be mirrored without legal headaches.

As much as I'd like to end on a high note, it is obvious that such issues cannot be tackled by an invidiual or small idealistic non-profit groups and the economic incentives are not in the favor of an open web.

Since I started my website, I published 38 posts (this one not included), which means on average a little more than once a month, but my publishing cadence is far from being that regular. In some months I managed to put out something on a weekly basis, but I've also had dry spells that lasted for several months. All the while I wrote notes privately on a more or less daily basis. This makes me wonder what causes my disconnect between the frequency of writing and publishing.

At the end of the first year of this website I tried - without success - to publish daily for a month. Derek Sivers, did a similar experiment with much better success has written a retrospective on his experience. He says he the he disliked the daily publishing cadence, because it made his writing worse and with it he broke a principle, that anything he posts is really worth the time of his readers.

On the other hand, there are people who consistently publish on a daily basis over many years and sometimes even decades. Seth Godin is one of them. He writes:

For years, I’ve been explaining to people that daily blogging is an extraordinarily useful habit. Even if no one reads your blog, the act of writing it is clarifying, motivating and (eventually) fun. [..]

What I’ve found is this–after people get to posting #200 or beyond, they uniformly report that they’re glad they did it.

- The first 1,000 are the most difficult

On the question what constitues an appropriate blog post, Mike Crittenden, who also publishes on a daily basis, argues that atomic blog posts are fine. He also says: There’s space for the crappy short blog post. It’s the crappy long blog post that shouldn’t exist.

Another person who makes the case for smaller blog posts is is Matt Gemmell. He thinks that the rise of social media had detrimental effects on the psychology of bloggers:

On social, content of any length at all is fine [..]. So, perniciously, our eager-to-simplify brains have decided that the converse is true for blogs: you can write only longer, weightier stuff. The sole possible outcome of this is the one I see all the time, which is that people are reluctant to start blogs because they think they don’t have enough to say. Those who do blog will often sit on pieces for too long, because they’re waiting until they have more to say — or they shelve pieces entirely, wrongly believing they’re too brief and thus somehow trivial.

Collectively, this is all a surrendering of creative output to the whims of external platforms, and is antithetical to what makes the web so useful and potent.

- Write less

Michael Nielsen in his article on his motivations for publishing his thoughts, states that his goal is to enhance his abilities to think and create. He says that he thinks better when the stakes are higher and that one of the best ways of raising the stakes is to make a document into something you're sharing with people whose good opinion you desire.

Reflecting on my personal approach, I think my reluctance to publish more often has to do with an internal belief system that holds quality as more important than quantity. But I am coming to think that this might be a false dichotomy. To get to quality one needs to practice. Public writing seems for me to be in a different category than private notetaking. So to get to quality there is no substitute for publishing. I don't intend to force a daily cadence, but I probably will try to take Matt Gemmells advice to [w]rite less, and be at peace with it., and to do so more often.

Last year one evening my whole family was asleep unusually early. On contrast, I was not particularly tired, which is equally unusual. I used the time that I unexpectedly had at my disposal to write a tiny web app for managing my bookmarks.

Initially my goal for this article was to describe the app and its making on both a technical and non-technical level, but I got a bit lost in discussing and justifying technical minutiae, which aren't that essential. What follows is an attempt to describe the psychology of writing a simple, yet useful system in a very limited amount of time.

An itch to scratch

I regularly jump between multiple browsers on several physical and virtual machines, and I bookmark quite a lot. And if it weren't for the further, I'd be happy with the browser built-in bookmarks. I never really found a solution for keeping bookmarks in sync that suited my taste. Still, my requirements are simple. I just want a single place where I can reach all of my bookmarks, and a way to add a link with a single click.

Certainly, bookmarking-as-a-web-app has been tackled many times over. I could have taken the sane persons' approach and just subscribe to some SaaS, or I could have searched for some open source solution that to host for myself. But then again, I'm a programmer, and it seems this comes with a déformation professionelle that got the better of me. I like to call it inverse vandalism (when vandalism is destroying things just because one can, then inverse vandalism is making things because one can). Those who want to take a look at the code first can do that here.

A few foolish assumptions

Feeling the compulsion to open the IDE and start hacking is the one thing, but there is one very hard limitation: having a chunk of uninterrupted time with good attention span available. Most of that is sold to my employer already. So when I have a good timeslot, in order to get something into a working state, its complexity must be rigorously limited. To keep the program as small as possible and overcoming the the hardest limit of all, the available tiem, deciding what is out of scope is probably more important than programming the actual features. And define a certain class of problems out of existence is a remarkable productivity boost.

Many, if not all, of the assumptions I took are unthinkable in a commercial setting. Yet they turned out to be liberating in this little project. The most fundamental was, that I wanted to create a system, which is intended for me alone to use. This freed me from a whole lot of yak-shaving. Assuming a single user means I don't even need to explicitly model it out. It made it easy to estimate how much (or rather how little) memory my data will consume, and as a second order effect, suddenly the filesystem is justifiable as a good enough storage mechanism.

So what remains to have a most rudimentary bookmark manager? A mechanism to add a url, to delete it again and to render the collection of all links. All of which is accomplished by a single node.js based script which reads in a file of all bookmarks into memory and provides three endpoints. One to render all bookmarks in a single page, one to add another bookmark to the file and one to delete a single bookmark. The endpoint to add a new link is meant to be called via a bookmarklet.

Of course, a system based on those assumptions is tautologically not able to scale. But the alternatives would not have potentially scalable software vs. the scrappy single-user system. It was either something I could do in a single good session, or not creating something at all.

Lessons learned

Hillel Wayne dedicated an issue of his fantastic Computer Things newsletter to the question What can you code up in an hour?. He writes Fast programming is a distinct skill from software engineering. Software engineering principles don’t totally map over. - and this matches quite a bit with what I learned from writing this little script (and running it without major maintainance ever since).

Don't hesitate to rigorously limit scope. Make an art form out of cutting corners. Minimize the number of moving parts. YAGNI, really.

If the project is not an exercise for the sake of learning a new technology, use familiar tools. The standard library is your friend.

Most best practices are trade-offs, which, if a certain time/complexity threshold is not reached, might not pay off.

Data > API > UI. If I ever wanted to evolve what I have, the only thing I would definitively want to keep are the over 1000 bookmarks I've collected.

Learn to recognise chunks of good time as they come and grasp them firmly. You don't need anybodys permission to experience the joy that comes in creating something for yourself. Just keep in mind, when project time collides with in-person time with your most important people, that the tail end comes faster than you realize.

In light mode, I go with the user-agent styles for the links, and there the contrast ratio is fine, but the same choice in dark mode, was under the level of what the W3C Web content accesibility guidelines recommend.

My go-to resource for figuring out the right colors with regard to the WCAG is the WebAIM contrast checker.

What up until now I haven't understood was how these figures are actually calculated. And it is actually all laid out in pseudocode in the WCAG recommendation. But since it is spread out, I decided to write it up for my personal reference.

So, the spec defines the constrast ratio as

(L1 + 0.05) / (L2 + 0.05), where L1 is the relative luminance of the lighter of the colors, and L2 is the relative luminance of the darker of the colors.

To answer the latter: the lighter color is the one with the higher relative luminance. And to answer the former, I quote the definition from the WACG again: The relative luminance is the relative brightness of any point in a colorspace, normalized to 0 for darkest black and 1 for lightest white.

But how do I get to this number between 0 and 1? Well, by simply reading on in the spec. There is some some pseudo code, which is easily translatable to Javascript (which I'm doing here in form of a literate program again):

Now, the contrast ratio is easy to implement:

An input type color will return a string in the form "#RRGGBB". To use this as an input for the color parameters of the contrastRatio function I need another utility function.

So now I can drop in two color pickers: and to cobble everything together:

The contrast ratio of the chosen colors is

: 1

Coming back to the starting point, color contrast is only one aspect with regard to what affordances links should provide, but that is a topic for a different blog post.

Media queries make it very easy to detect the readers preference and CSS custom properties help keeping the rest of the styling clean and non-repetitive. So I thought it would be a right neighbourly thing to add the following:

It looks plausible to me, but visual design isn't my strongest suit. So if someone, who prefers dark mode, has thoughts on it, I'd be thrilled to hear from you.

So, did you know, that when you type the words do a barrel roll (without quotation marks) into Google's search field, the page with the results does as you bid, and turns over 360 degrees.

The implementation of this behavior can be achieved by adding a little style to the body, for example the following class:

If you want to try it out on this very website, you can use this input field.

The necessary logic to apply the styles is provided by this script:

Now, these little snippets of CSS and Javascript are not the whole point of this article. More interesting is, in my eyes at least, that what you just read is a literate program.

The code you read is not only a mere nicely formatted textual representation, but is the actual HTML style and script elements that control the rendering and behaviour of this website in your browser. This is achieved, by and large, by making the the script and style elements block-level elements, which makes their content visible. The tags themselves are rendered as content of the :before and :after pseudo selectors.

I've stolen adapted the styles from Colby Russell, who created and documented a whole static site generator in this programming style.

Another nerdy application of this idea is the naked, brutalist HTML quine by Leon Bambrick.

Update after first version: Manuel gave me some clarifying feedback via mail, and stated that he in fact the doesn't consider all internal linking as bad. My misunderstanding originates in my interpretation of his statement, that You should only use the first type when strictly necessary - which I overinterpreted as referring to something like standard navigation elements. I'll keep the rest of my reply unchanged, as I want to elaborate on the usefulness of (pontentially dense) internal linking as a design concept beyond commercial aspects.

Manuel identifies the world of marketing, search engine optimisations, and analytics as driving force of internal linking. And that might indeed be one reason. As I do not waste any time with SEO, never had analytics in place and don't plan to, I don't market anything to anyone, for I don't want to sell anything to anybody, I don't know too much about such techniques, maybe excessive internal linking in fact is a symptom of these all motives.

While I don't share these motives, I still purposefully link my former writing. I do so out of a different, and - as I hope to convince my esteemed readers - legitimate reason.

See, most of my writing starts in my private Tiddlywiki instance. Wikis as a writing medium are terrific. I've used more than half a dozen wiki softwares in my life. From the top of my head: MediaWiki, PmWiki, Zim, Githubs built-in Wiki, Redmine, and - tell me you are an enterprise application developer without telling me that you are an enterprise application developer - of course Confluence and Sharepoint. What any wiki software worth using makes trivially easy by design is internal linking. In a wiki there is on a philosophical level never such a thing as a dead internal link, only a page of which gently prompts you to write its first version.

Now, even though my website is only the subset I feel comfortable to share publically, I do like to keep the internal connections wherever it is possible. These internal connections help me to see patterns over time.

Michael Nielsen has published some notes on how to use a personal website to enhance your ability to think and create, which is kind of a manifesto for his site. Here are some excerpts of this note that resonated very strongly with me (emphasis mine):

The purpose of the site is to help me think well. This purpose is in opposition to many widely-used norms in online writing.

[..]

Depth over engagement and audience-building.

[..]

With this site I can design an interface that better supports my work. For one thing: the site navigation and organization should help me generate new ideas, and help me see the structure in my work. This site is an interface to my past thinking and possible future creative work. This means the organization and design of the site are first-class objects. As my understanding changes, so too will the organization, since the organization expresses that understanding. Thus, I should expect to reorganize and consolidate notes often. Both are a type of meaning-making.

So, yes, I admit that my internal links have a self-serving motive, as they enhance my capabilitiy and my thinking. But that is certainly not at the expense of the rest of the world. I still very much desire to help where I can to amplify the good parts of the web. For all cynical and defeatist takes aside, there is still a lot of that out there.

So that aim in mind, I've decided to treat internal and external links from now on a bit differently regarding their affordances. Internal links, that aren't part of the main navigation, will look just like the standard text and only reveal them as links when someone hovers over them, while all external links will always look like a proper link (I haven't yet figured how I will handle it on the RSS feed though, maybe in the HN endnotes style of linking?). As I consequently use relative links for everything internal, it was quite easy to achieve with a few additional styles:

article > * > a:not([href^="http"]) {
    color: #555;
    text-decoration: none;
}

article > * > a:not([href^="http"]):hover {
    text-decoration: underline;
}

And since I am on the topic of linking. In the previous article I forgot the hat tip to Curiositry, who shared a tip how to link to a segment of a youtube video both with a start and end time. I long thought that youtube had removed that feature. As turns out, only in the standard viewer, but not in embedded mode. I hope no product manager on the other side of the big pond reads this, for such a useful feature will then likely be killed before the end of the year, which would be a pity.

Given that Big Design Up Front and the Waterfall process were prevalent notions in introductory courses on software development for a long time - to some extent, they were still present in lectures I took during my studies, over two decades after this recording - that was a great question. I just love the answer that Hal Abelson gave:

I bet that's the axiom of someone who hasn't implemented very large computer systems. [...] In general, I think people who really believe that you design everything before you implement it, basically are people who haven't designed very many things.

But what may be a fallacy to most of those who actually write software - Uwe Friedrichsen elaborated on it very clearly in his article The Industrialization of IT fallacy - is still something that I see actively pursued and pushed by a certain type of executives. Of course, it's the 21st century and its a SaFE bet that we are all more or LeSS agile. But if you are looking for today's waterfall - apart from terrible puns on waterfall-like processes in the previous sentence - you often just have to take a look at the org-chart. Those who paid attention to Mel Conway's observations on system design from 1968 know, that organizational design influences the shape of the software that gets build.

I did nothing like that (yet), just another site with a little over a dozend links, in no particular order, to mostly personal blogs and websites, which I read and of which think other people might like them as well. But at least, now something exists, to which I can tend to, when the time budget permits.

This book was was edited, printed and marketed by a reputable German publishing house and bought by my mother in 2000. Neither production, nor purchase involved any kind of irony or hipster humor. And more than that tells something about some generational viewpoints and tendencies, it tells a story about a web that felt and was different than today's web: The dot-com bubble had not burst at that point in time. Neither was Wikipedia founded, nor had Google yet become an eponym for search. Search results were incomplete and lacking. Finding information was far from feeling like a solved problem.

Fast forward only a few years and everything had changed. Search quality improved to a point, that I started to form the assumption that I won't ever need bookmarks anymore, for I will be able to retrieve any information I want with a simple query. Just, that wasn't quite the end of history. Today both retrieval and content discovery seem to be problems that are look for a new solution. For the open flank, in the light of the stellar rise of capabilities and general availability of Large Language Models and the perverse incentives of SEO, is trust.

There is infinite storage for content, but the time to wade through it is quite finite. So whose recommendation do I trust? The service that delivers results that are okay-ish, just good enough capture my attention and promptly sell it to the highest bidder - or a person I can converse with, that might have a reputation to lose and who probably has already demonstrated their sense of taste and style to me in their writings?

Certainly, from the demise of Yahoo's directory we can draw a lesson that human edited directories don't scale with the amount of content available (which is of course trivially true). But why on earth would a sane person be interested in the whole web? What I want to see are the parts that still are a labor of love and conviction.

If I were to create a directory, my first editorial principle would be that the content must be be worth my time. The second principle would be, that visitors shall be treated like humans, and not as a bunch of suckers from which one might be able to extract a few cents (as beautifully illustrated here).

Coming back to this little web directory in printed form, with 23 years of hindsight, it still manages to convey two things to me: one is that preservation of digital artifacts is a hard and pressing issue (itself serves as an example in two ways, as you see: the big Yahoo directory is gone for good, this book is still there, and of course it is largely useless for as many of its URL have rotten away) and secondly, content curation is an act that creates value. Albeit, if the price tag of 29,95 DM was an appropriate expression of that value might be a point for a whole different discussion.

If you ask yourself, why you should write online, for you fear you won't be read, Manuel Monreale has an answer. He offers to be your first reader. Chris Hannah also decided that he'd like to read your blog. I share Chris' opinion, that the internet would be a more interesting place if more people blogged.

In the spirit of Derek Sivers' leadership lessons from a dancing guy: Three is a crowd and a crowd is news. - If you start a new blog, or already have one and your only visitors are bots: send it to me, I'd love to read it. If you provide a feed for it, even better, I'll add you to my feedreader. And when I finally find some time to create a blogroll, you'll be in there as well.

Indeed, Bill has written a lot in nearly three decades. In the answer to the question how he managed to create so much stuff, one phrase struck my particularly:

I don't live in XP or ME or Windows 95. Not win3.1 either. Not MSDOS. I live on the internet, in an ancient unix shell account which is aliased to look a bit like msdos. If I should ever type up a little textfile during other activities on the computer, it only takes me ten seconds to put it on my webpage. Unlike most people, for me the barriers against publishing on internet have entirely evaporated

Isn't that a beautiful idea? The web as a basically immediate writing medium, with basically nothing stands technically in between writing something down and having it published. Alas, rather few people live out their intellectual life entirely in a unix shell.

For most the barriers are firmly there, the friction is as real as the perceived need for access to the web as a medium of personal expression.

Many of today's walled gardens got big, because a part of their initial value proposition was to lower the barriers of entry for many. They generally didn't do that with the public good in mind, and the quality of all those platforms deteriorates in a cycle, that Cory Doctorow has recently sketched out, and coined the colorful and sadly adequate term enshittification for.

I haven't figured out a solution for myself that I would perceive as frictionless yet. This website started out as a single static html file, something that would have indeed been manageable via ssh in a shell. But frankly, while I find my way around vim, I don't particularly enjoy the experience. Apparently, I am not enlightened enough and I like proper UIs maybe a bit too much. So what I have is a Tiddlywiki in which I write down most of my notes. And while I love Tiddlywiki as a writing medium, I don't want to expose all of my notes and I don't want to serve a metric ton of Javascript for completely static content. So now I have, apart from my wiki instance, a few horrible scripts that sit atop of my private wiki instance, filters the parts that are meant for publication (as indicated by tags, which are a very useful first-class primitive of tiddlywiki) and transforms them to some static html. But still, a wiki remains a comparatively non-mainstream interface for writing and the site generation script is a one-off, and I still haven't completely automated the feed generation with that approach. The whole problem it certainly quite a yak to shave, but probably - hopefully - worthwhile.

The web, with its not quite 2⁵ years of existence, is still a young medium. Blogging as one of its archetypical forms hasn't actually been away. Yet, that the web is an open platform is so not through a law of nature. Given the economical and political circumstances of surveillance capitalism, and the maddening drift to authoritarian forms of governance, those properties would better not be taken for granted.

But that is all the more a reason to experiment, tinker and shape the medium through usage and many more cute little experiments, and do what is possible to increase the signal-noise ratio of the better corners of the web.

All that is needed to make it work is a single link tag added to the head. It has three mandatory attributes: href of course for the URL of the feed, rel with value "alternate" and type with a value of either "application/rss+xml", or application/atom+xml, depending on the feed format. The title attribute is optional, but it's useful if a site offers multiple feeds.

In quite a lot of cases it works like a charm. It used to work here as well. Now, guess which self-proclaimed fan of feeds thought it would be a good idea to rewrite the template of his personal website and managed to forget putting in the following line into the head:

<link href="https://holzer.online/feed.xml" rel="alternate" type="application/rss+xml">

The approach has one problem: it is difficult to extend the API without introducing a breaking change. Two common features, which can typically be omitted in the first version, but are hard to retrofit when the returned type is an array, are metadata and pagination.

The simple prevention is to wrap all collections into an object from the beginning. Existing clients can then simply ignore all new properties, if they need to be introduced, whereas a change of the type of the response from array to object is guaranteed to break those clients.

I love personal websites (as opposed to the corporate web) and the idea of Bring Back Blogging resonated strongly with me. I just signed up to it. The project: publishing three articles in January (+an announcement at the beginning and the end) and providing a RSS feed for the site.

So this is the announcement of the beginning. I'll keep it short, and will use the rest of the evening to get my RSS feed generation script in order again.

So I prompted it to write a bash script which plays tic-tac-toe using an optimal strategy.

In the first response, I already got quite a lot of building blocks:

• a data structure for the board (more about that later...)
• a function to print the current state of the board
• a function to check for a draw
• a function to check whether any player has won
• a function to check for whether a move is valid
• and the beginning of a function to decide the move of the program.

I assume the API ran in some sort of timeout, as the last function wasn't implemented fully. Therefore I prompted it a for the whole function to make the computer move, and it indeed delivered complete implementation. So I had a lot of functions, but no game to actually play. And naturally - or at least naturally for software developer - I asked if it can generate a game loop, and I wasn't let down.

I copy-pasted the three snippets into a file, held my breath, executed the script, and: it worked. Well, at least sort of. The generated program let the human player make the first move. As the only rational opening move is to take the center field, I didn't immediately discover a subtle bug, until I tried to play a non-optimal game.

The generated code represents the board as an array of nine strings, where an empty field is represented as a single space character. The array was only initialized with 8 strings. To be fair, there are only two hard problems in software engineering: cache invalidation, naming things and off-by-one errors. And who am I, to be too harsh in a code review? I conversationally (it's ChatGPT after all!) asked it whether it could spot and correct the off-by-one mistake in the initialization of the board. And here it started to become obvious that it is a gigantic correlation machine, which although it produces very impressive results (and confidently sounding one's), it has no actual concepts of the things it generates. There is - as expected - no intelligence and no learning in the human sense. Here is how the dialog went down.

You are correct, there is an off-by-one error in the initialization of the board. Currently, the board is initialized as follows:

board=(" " " " " " " " " " " " " " " ")

Just that the board wasn't initialized as quoted above. This was no reproduction for its initial error, but another one (which it continued to explain in prose - and incorrectly so).

This creates an array with 13 elements, with indices ranging from 0 to 12.

After that it created a description of a correct solution in prose, directly followed by yet another incorrect implementation:

However, in the tic tac toe game, the board has only 9 squares, with indices ranging from 0 to 8. To fix this off-by-one error, the board should be initialized as follows:

board=(" " " " " " " " " " " ")

This creates an array with 9 elements, with indices ranging from 0 to 8, which corresponds to the 9 squares in the tic tac toe game.

It is a fun tool to play around with and I'm not unimpressed by the results. But I don't tremble in fear of being layed off anytime soon due to its existence. For those who are not convinced, Hendrik Erz has written up a lot more good reasons not to fall for the hype.

If you are interested, you can also read the complete chat transcript and the generated source code (where the correction of the initialization was done manually).

Lately I was thinking about the relationship between learning, teaching, schooling and curiosity, especially with regard to teaching computing. I cannot pin it down to something concret, but I strongly sense that somewhere in the system mechanisms are in place, that are detrimental to curiosity and form learners into consumerists.

Therefore, one thing I'm looking forward to is the upcoming round of DevEdBookClub. An informal online discussion round, that will discuss Greg Wilsons Teaching Tech Together over the next few month. I've read to book earlier this year, and it is well worth to be re-read. As I did not take notes on the first reading, this is a great opportunity not only to discuss it with other people, but maybe also get a summary done.

I've also been thinking a bit about my writing process. The fixed cadance of weekly notes has a liberating aspect: when something doesn't make it in there, there is a place for it next week, or it might even not be important after all. But having a topic for an article in mind makes it easy to move the release further and further, in the worst case until I don't see a point in putting something out anymore. I'm asking myself, if artificial deadlines might be not evil after all? Maybe I should budget a certain amount of time for a given topic I'd like to write about upfront and then just put out what ever I have once that time budget is used up?

And since the timebudget for this week's notes has basically run out and it's quite humid and hot in the appartment, I'll seek a place with more shadow now...

I've also thought a bit about how a both practical and principle-oriented introduction to software development would have to look like. Could I outline what I think to be essential? I tried and ended up with a whole lot of disparate, little aspects - it is really alarmingly easy to miss the forest for the trees. I sense that there is a lot of potential for simplification overall, but as the saying goes: simplicity is the ultimate sophistication...

Another ongoing topic of mine is coming to terms with a lot of parallel ideas and loose ends. I've started thinking in the direction of serving on-going writing in a separate folder as raw plain text. That would be quite frictionless, but it I have to make up my mind about a few details. Would I want to keep URLs of such draft/work-in-progress files stable, shall they be first-class citizens of the site, should they be indexed, how would I indicate freshness/state etc.? Also I started to think about a general restructuring of the site. After all, I've strayed away from my initial principle, that every piece of content shall live in the index.html.

And - third time's the charm - this weeknote format seems to be working for me and my schedule.

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.

One of the perks of having a personal website is that I can play with web technology as much as I want. For example: I'd like to add support for webmentions, but without a third-party service. While the specification seems straight forward, I'm a programming long enough to expect the devil being in the details of even the most straight forward specifications (And life is short, while art is long.).

I also thought a bit on recurring design elements of personal websites in general, which led me down quite a rabbithole. I've collected nearly thirty of them by now and I don't think that list is exhaustive yet. This is a topic that would deserve a proper write-up. Among those elements is for example the blogroll. I think that would be something I should add one to my site as well. I believe we'd better spend more time on personal sites instead of lingering in the gated communities of the web.

On Work-In-Progress

John Cutler shared a checklist on Twitter that resonated a lot with me. It is not only applicable in a work context but in the private life as well. Even if I think about this little corner of the web, I do have a few things that I've started but not yet quite finished...

Is your organization struggling with too much work in progress? How would you know?

- John Cutler (@johncutlefish) May 22, 2022

But more pressing than gauging the question of if, the is the question what to do about it? Sadly, just creating a Kanban board in JIRA does not quite cut it...

What aspects does a good life have?

Also via twitter I came across the article A Psychologically Rich Life: Beyond Happiness and Meaning by Eron Westgate and Shigehiro Oishi. I think their finding, that happyness, meaningfulness and "psychological richness" of life are and can be measured as separate categories, as an enligthening mental framework. It resolved for example a cognitive dissonance I had, when I first read a certain passage of Richard Hammings talk You and your research, where he said that he had neglected his spouse in order to to get what he wanted done. Happyness as category can be in tension to meaningfulness or psychological richness. All aspects contribute to a good life, but each is doesn't weight equally for everyone.

Snowclones in technical articles

Sometimes titles sound strangely familiar. They follow a certain phrasal template which sounds a bit clichée. Such templates also go under the name snowclone. I think I've encountered at least half a dozen of them in the context of computer science / software engineering. It might be worth an article to collect them.

That's not quite all folks...

There are certainly more things to be said, but as I want to put something out at a predefined time, as artificial as that might be - so I'll close it here, and in the next notes of the week I may muse on some of the following questions:

• What can be done to make software development less of a red queen's race?
• Might it be worth to take up long letter writing?
• If both time and money are constrainted, what is the most effective way to learn a challenging subject/topic?

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.

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.

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.

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:

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

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

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.

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.

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.

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.

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.

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.

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.

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 [..]

and

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.

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.

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.

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. :)