Links - 25^th August 2024

In my experience, there’s only one way for a collaborative project to remain organized. It requires one individual to dedicate themselves to keeping it that way.

The project hero follows up when the conversation dies down. They keep an eye out for folks who aren’t participating. They keep track of unresolved issues. They take meeting notes and update the document to reflect decisions. They make sure ideas don’t get lost.

A really good project hero also helps manage the discussion. They point out when it’s going in a circle. They identify miscommunication. They intervene when the group gets sidetracked by unimportant details (“bikeshedding”).

If that sounds like a lot of work, then you’re not getting an accurate picture. It’s an enormous amount of work.

The fundamental problem is a mismatch between the way collaboration works and the way documents work.

The intended result of a collaborative process is a document, which lays out ideas in logical order. It’s arranged by top-level concepts, each with supporting material, surrounded by an introduction and conclusion.

The collaboration itself proceeds in temporal order. People talk about things, which spark other things. People mostly react to things someone else just said; occasionally they’ll have a new thought, which could apply to any part of the project.

The final document is intended to be read from start to finish. The collaborative discussion is intended to let participants know what new ideas have been raised. This is why the discussion usually takes place in an email thread, chat room, or live conversation, even though the final product is usually a document.

So now you have at least two separate places where people are writing things down: the document, and the discussion. Related information might reside in an open-issues list, an executive summary, or other places. All of these need to be kept in sync. And keeping differently-organized things in sync is always hard, it is one of the fundamental hard problems in knowledge work.

On August 11, 2014, I published v1.00 of Dear ImGui on GitHub. I thought I would take the occasion to reflect about it, share some data points and stories, and generally think about what I want and need.

Dear ImGui already has many users and a continuous, overwhelming flow of support requests. I believe it has the potential to have x10, x100 the numbers of users in the future. This is a marathon. To preserve my own sanity and stamina, I need to pace the growth of its user base.

If we get x10 the amount of users tomorrow, would we benefit from x10 the amount of funding and be able to hire people? I am not sure. Even if we did, it’s not like scaling engineer count is easy and comes without additional complexity.

Therefore, it is NOT to my advantage to attract too many users too fast. I prefer to work on core things at my pace. Catch up with technical debt, write better code. I prefer to first figure out how to better rely on the community to help.

An explainer for doing web development using only vanilla techniques. No tools, no frameworks — just HTML, CSS, and JavaScript.

Modern web development frameworks are powerful in their ability to develop rich well-structured web applications quickly, and for this reason alone they are well worth your time to learn. However, this rich functionality comes at the cost of framework and tooling complexity, and the resulting projects often require regular maintenance to keep secure and up to date.

The plain vanilla style of web development makes a different choice, trading off a few short term comforts for long term benefits like simplicity and being effectively zero-maintenance. This approach is made possible by today’s browser landscape, which offers excellent web standards support.

The JavaScript community’s omertà regarding the consistent failure of frontend frameworks to deliver reasonable results at acceptable cost is likely to be remembered as one of the most shameful aspects of frontend’s lost decade.

Had the risks been prominently signposted, dozens of teams I’ve worked with personally could have avoided months of painful remediation, and hundreds more sites I’ve traced could have avoided material revenue losses.

Too many engineering leaders have found their teams beached and unproductive for no reason other than the JavaScript community’s dedication to a marketing-over-results ethos of toxic positivity.

Shockingly, cheerleaders for this pattern of failure have not recanted, even when confronted with the consequences. They are not trustworthy. An ethical frontend practice will never arise from this pit of lies and half-truths. New leaders who reject these excesses are needed, and I look forward to supporting their efforts.

as open ecosystems grow, they tend to experience what i like to call “trainwreck design”

basically: when many programs are independently designed and developed & then smashed together, user experience suffers.

things feel wrong because users can sense the lack of coherent vision. tiny papercuts.

take the GNU/Linux ecosystem: “trainwreck design” happens there all of the time. programs are designed independently & smashed together, everyone spritzes holy water on their keyboards, adds 2,000 more lines of lua to their emacs config, and things mostly sort of keep stumbling forward.

but this results in programs like df. or mount.

they grow weird appendages, have millions of esoteric flags, and worst of all, they just FEEL obviously wrong.

“trainwreck design” is not intentional design.

there is third style of software design that is often conflated with the other two.

i’m calling it “the hive”, and it’s a bazaar/cathedral hybrid.

hives have one or more leaders who influence direction and vision, but who do not act as dictators.

in other words, hive leaders inspire design through vision — not by telling people what to do.

being a hive leader is not fun. they have stressful, emotional responsibilities:

• produce vision and guidance for the project

• help people understand the vision

• organize people into roles

• resolve interpersonal disputes

• provide MORE guidance when people disagree

• watch all of the trains

• try not to burn the fuck out

people involved with hive projects make decisions autonomously, but with shared understanding and vision.

good hive leaders dramatically reduce the likelihood of trainwreck design, and they keep the important communal “vibe of the bazaar” alive.

also, you get to call yourself the “queen bee”

An inquisitive anthropologist discovered that what the technicians did all day with those machines was grotesquely different from what Xerox corporation thought they did, and the divergence was hampering the company unnecessarily. The saga that followed his revelation is worth recounting in detail because of what it shows about the ingenuity of professional maintainers at work in a high-ambiguity environment, the harm caused by an institutionalized wrong theory of their work, and the invincible power of an institutionalized wrong theory to resist change.