Domain-driven design works best when the people who know the domain can check the model. Most modelling notations get in the way of that.

Fact-based modelling helps. Instead of starting from tables or classes, you describe the domain as short sentences that a domain expert can confirm or reject. This post walks through that way of working, then translates the result into LinkML, a schema language with good code generation.

Think in facts

The best-known fact-based method is Object-Role Modeling (ORM). Its core idea: a domain is a set of facts, and every fact can be read out as a sentence.

Each Team has at least one lead, who is a Person.

A product manager can read that sentence. A DBA can read it. The person who runs the team can read it and tell you it’s wrong. “Teams go without a lead for months during reorgs” is cheap feedback at a whiteboard and expensive feedback after you ship a NOT NULL constraint.

You find these facts by talking with domain experts, using concrete examples (“take the platform team. Who’s the lead there?”), plain language, and simple drawings. Examples do double duty: they help you discover a fact, and they test it. If the expert can’t fill in your example table, the fact is wrong.

Read Halpin & Morgan Information Modeling and Relational Databases for details.

Sketch first, formalize later

Keep formal notation off the whiteboard. Circles and lines and sticky notes are enough: a circle per kind of thing, a line per fact, the sentence written along the line, examples on stickies underneath. ORM has a precise diagram notation, and in a workshop that precision turns contributors into spectators: the expert who happily corrects a sentence will hesitate to touch a diagram symbol.

For many domains, a whiteboard photo plus the agreed sentences is the whole model, and stopping there is fine. See Caseum for more about such a lightweight approach.

From facts to schema

Sometimes you can’t stop there. You need a JSON Schema for an API, a database schema, docs that stay current. Maintaining those by hand, in parallel, is how the drift starts. Better to keep one source file and generate the rest.

ORM tooling is not in the best state. LinkML is a great alternative. It is a YAML-based schema language with generators for JSON Schema, SQL, ER diagrams, documentation sites, and typed Pydantic and TypeScript classes.

A small HR domain as fact sentences:

Each Person is identified by an id, which is a URI.
Each Person has exactly one name.
Each Person (the coachee) may have one or more coaches, each of whom is a Person.
Each Person has at most one Department.
Each Team has at least one lead, who is a Person.

The same model as LinkML (hr.yaml):

id: https://example.org/hr
name: hr
prefixes:
  linkml: https://w3id.org/linkml/
  hr: https://example.org/hr/
default_prefix: hr
default_range: string
imports:
  - linkml:types

classes:
  Person:
    attributes:
      id:
        identifier: true
        range: uri
      name:
        required: true
      coach:
        range: Person
        multivalued: true
      department:
        range: Department
  Department:
    attributes:
      id:
        identifier: true
        range: uri
  Team:
    attributes:
      lead:
        required: true
        multivalued: true
        range: Person

Each fact becomes a slot (LinkML’s word for an attribute), and the how-many wording maps directly:

Settle on a fixed set of phrases like this and turning the whiteboard into a schema stops being design work and becomes transcription, which AI can do for you.

From schema to software

Use the LinkML tools to create other files from the model. For example:

JSON Schema

Run gen-json-schema hr.yaml:

"Person": {
    "additionalProperties": false,
    "properties": {
        "coach": {
            "items": { "format": "uri", "type": "string" },
            "type": [ "array", "null" ]
        },
        "department": { "format": "uri", "type": [ "string", "null" ] },
        "id": { "format": "uri", "type": "string" },
        "name": { "type": "string" }
    },
    "required": [ "id", "name" ]
}

Mermaid ER diagram

Run gen-erdiagram hr.yaml:

erDiagram
Department {
    uri id
}
Person {
    uri id
    string name
}
Team {
}

Person ||--|o Department : "department"
Person ||--}o Person : "coach"
Team ||--}| Person : "lead"

which Mermaid renders as:

(Mermaid is supported by many Markdown tools, including on GitHub)

SQL

Run gen-sqlddl hr.yaml:

CREATE TABLE "Person" (
    id TEXT NOT NULL,
    name TEXT NOT NULL,
    department TEXT,
    PRIMARY KEY (id),
    FOREIGN KEY(department) REFERENCES "Department" (id)
);

CREATE TABLE "Person_coach" (
    "Person_id" TEXT,
    coach_id TEXT,
    PRIMARY KEY ("Person_id", coach_id),
    FOREIGN KEY("Person_id") REFERENCES "Person" (id),
    FOREIGN KEY(coach_id) REFERENCES "Person" (id)
);

Testing the schema with examples

Given ada.yaml:

id: https://example.org/people/ada
name: Ada
coach:
  - https://example.org/people/grace

and bob.yaml:

id: https://example.org/people/bob
department: engineering

Here’s what testing looks like:

$ linkml validate -s hr.yaml -C Person ada.yaml
No issues found
$ linkml validate -s hr.yaml -C Person bob.yaml
[ERROR] [bob.yaml/0] 'engineering' is not a 'uri' in /department
[ERROR] [bob.yaml/0] 'name' is a required property in /

There is more to LinkML, but the shape is clear: one schema file, kept under code review, with tool automation so that artifacts do not drift from each other.

Remember the facts

Compare the written fact

Each Person (the coachee) may have one or more coaches, each of whom is a Person.

with the LinkML model slot:

coach:
  range: Person
  multivalued: true

The sentence names both roles, coach and coachee, and reads aloud in either direction. The slot names one direction and buries the rest in structure. A domain expert can verify the sentence but not the YAML.

Keep the written facts and their examples around, right next to the schema. Your AI is excellent at English and so can help keep facts and LinkML in sync.

But I think my coding agent, with all its own settings and quirks and approach, should be distinguished from everyone else’s. I use more than just Claude Code (I also use GitHub Copilot, Gemini CLI, pi, …). I thought my coding agent better have some personality.

So I’ve set up a dedicated @lsimons-bot, put it in a VM sandbox, and instructed it to identify me as its co-author. I’ve even given the bot its own blog. Now I get pretty commits with two authors which are me and robot-me:

I’ve tuned the settings so that when I am doing tightly controlled AI-assisted development, the git commits have me as main author and @lsimons-bot as coauthor. When I’m doing vibe coding in the VM, it’s reversed. And it’s also nice to see the bot make pull requests which I then review and merge.

In Claude Code it is possible to configure its attribution settings, but not all the coding agents I use can do this just yet, so as of right now I’m instead wasting tokens on it.

Steve Yegge is back with “Welcome to Gas Town,” a novella-sized blog post about his new multi-agent coding systems, full of Mad Max references. It’s an entertaining but puzzling read. He describes a chaotic world of “polecats”, “GUPP”, and “Convoys”, covering the architecture with thick narrative lore.

To decipher what he is actually building, I fed the post and his GitHub repository into Gemini. It helped me understand Steve’s vision of a Kubernetes-like control plane for AI code agents and then helped write this blog post.

Decoding the Metaphors

Yegge’s system manages the chaos of running 20–30 concurrent AI agents in parallel in YOLO mode. Key parts:

• The Controller (“The Town”): A central Go binary that orchestrates agent lifecycles across projects.
• Git-Backed State (“Beads“): The atomic unit of work isn’t a database row; it’s a JSON file committed directly to the project’s Git history. This makes every task, status, and message persistent and version-controlled.
• The Interface: The system uses tmux as a dashboard (HUD) to manage the fleet of agents.

The Workforce

The “Gas Town” roles map to standard distributed system components:

• “Mayor” (Interface): A persistent agent acting as a Chief of Staff for the human user.
• “Polecats” (Batch Workers): Ephemeral agents spun up to execute tasks and vanish.
• “Refinery” (Merge Queue): An engineer agent that resolves merge conflicts when multiple workers submit code.
• “Witness” (Watchdog): A monitor that detects and restarts stalled agents.

Tackling complexity

More than the specific solution it’s interesting to see the underlying problems being solved for. Claude Code is polite and it stops to ask for confirmation, so, control systems are built to make it continue. Claude Code context compaction can remember the wrong things, so structured external memory is provided in specific and evolving ways. Etc.

The git repo reveals more of such complexity not fully explained in the blog, with the docs containing some of the more interesting insights of what happens when you do vibe coding at scale. For example, why identity of (sub)agents matters.

The repo’s AGENTS.md is interesting too. Agents are explicitly forbidden from asking permission to push; they must run tests, commit, push, and verify success before reporting back.

Looks like quite a serious attempt to build an industrialized coding factory, turning the developer from a coder into a manager of a synthetic manager of synthetic workers.

Looks like most of the work to make this happen is handling accidental complexity, not essential complexity. I wonder how much of that is due to building on top of Claude Code. Perhaps a future iteration integrates its own less-polite less-error-prone coding agent, something like pi?

(Yegge being co-author of the book Vibe Coding, who recently said in a talk “if you are using an IDE [in 2026], you are a bad engineer“, because you should use a coding agent)

Fast forward to today, and we’re seeing a return to that mindset based on the practical demands of AI-assisted development.

Spec-Driven Development: A Modern Twist

To keep tools like GitHub Copilot, ChatGPT Codex, and Claude Code behaving, developers are increasingly writing natural language specifications that guide code generation.

This trend, often called spec-driven development, emphasises writing structured, human-readable descriptions of what software should do — before writing any code.

These specs aren’t just throwaway prompts. They’re version-controlled, reviewed, and treated as first-class artifacts. They are what helps keep the AI on the rails.

The Parallel with Literate Programming

What’s happening here mirrors Knuth’s vision. In both cases, the developer is encouraged to think clearly and write clearly. The difference is that now, the audience isn’t just other humans — it’s also an AI model that can turn prose into functioning code.

Modern tools like Jupyter already blurred the line between documentation and implementation. This hybrid approach is now becoming a valuable way to avoid AI slop.

Why It Matters

This isn’t just a tooling shift — it’s a cultural one. We’re moving away from “vibe-based coding” and toward a more deliberate, explainable, and collaborative process. And in doing so, we’re rediscovering the value of code as a form of communication.

Co-authored with AI (Anthropic Claude Sonnet 4.5).
Normally I don’t publish content that AI helped to write, but I wanted to see how it feels.

Short video introduction:

It doesn’t work!

Disclaimer

Though I incorporated feedback from a lot of colleagues, this was never “the” SBP framework. Our company culture is as informal as it can be, with just enough structure. Making a framework such as this official is more than we need. We do not want people to think of their careers as a checklist to complete or as a ladder to climb. Instead, we suggest people mostly focus on growing their impact, picking up and mastering new competencies along the way.

Framework

The base framework is rather abstract, defining 10 coarse-grained competencies that apply to all engineering roles, such as “maintaining quality” or “planning and organizing”. The competencies have up to 7 different levels. These 10 competencies are grouped into Craftsmanship, Human, and Leadership categories.

The Progression app is organized into strict levels. To make the tool work for us, the online version of the SBP framework defines these levels too. But these are not actually used within SBP! It’s quite common to have some competencies at a very high level and others still much lower, and that’s ok with us. One common example is engineers with very highly rated craftsmanship skills but lower rated teamwork skills. The reverse also happens!

Roles

In this framework there are only three roles defined: engineers, tech leads, and technology officers.

Engineers are our individual contributors (ICs), an industry term we don’t usually use. When engineers lead others, they do so primarily by example, based on the content of their work.

Tech leads (TLs) are engineers that accept additional leadership responsibilities. Tech leads are not in charge of teams, we expect servant leadership of them.

Technology officers (TOs) are a lot like tech leads but with somewhat different leadership responsibilities. While tech lead engineers lead one specific team, our technology officers have a somewhat broader scope. They’re a bit further removed from the day-to-day engineering work, giving them time to focus on cross-team topics and to do work for which there isn’t a dedicated engineering team available, like presales.

TLs and TOs are leaders but not managers. At many companies with career ladders and levels, TLs and TOs might be considered staff or principal engineers, i.e. they are still on the “individual contributor” track. While some engineers progress by taking a TL or TO role, it’s important to realize there are engineers at a “staff” or “principal” level without a TL or TO role. Those engineers could match a different staff-plus archetype (like Solver or Architect), or just not match up with such a rigid framework at all. It’s also possible to switch from a TL or TO role to a regular engineering role.

Engineers at SBP do have additional roles at times that require additional competencies. For example, engineers can become coaches. These are not part of the framework.

Competencies

While Progression is optimized for defining pretty specific skills for pretty specific roles, this particular framework is broad and generic, and so is focused around competencies.

There are up to 7 different levels defined per competency.

While the basic competencies are the same for TLs and TOs as for engineers, our expectations of where our leaders will focus are a little different, and so for some skills there is a leadership (L) variant defined. Since Progression doesn’t support such variant definitions, there’s some overlap/copies.

Competency example: Client Orientation

SBP is an outsourcing company. Our engineers work in self-steering teams dedicated to a single customer. Because all our engineers have a lot of customer interaction, the framework is relatively heavy on communication compared to many other progression examples.

Progression for comparing roles & levels

One cool feature in Progression is how it allows you to put different roles and different levels side by side. This can help engineers think about which direction they might develop in next, though since at SBP we don’t actually use levels it’s of limited use for us.

Progression for check-ins

A recent addition to Progression is a new check-in feature that arranges a guided conversation between engineers and their managers (or in SBP its case with no line management, coaches). The idea is to agree together on career progression.

I like what they’ve built here. I imagine it’s a good way for HR departments to help beginning engineering managers have decent-quality factful conversations. But it’s not the right tool for Schuberg Philis.

It’s a great example of our “too much structure” rule kicking in. We have an internal 360-degree feedback process that is less structured than this, asking open questions instead, focusing on the important feedback conversation more and happily sacrificing some structured/detailed record-keeping in the process. Maybe when SBP is 10 times bigger that has to change?

Spreadsheet version

I created the Progression version of this framework based on my initial spreadsheet version of this career framework. I’ve found most people feel quite overwhelmed (at best) when confronted with this spreadsheet, while HR professionals appreciate the comprehensive overview.

Success!

Developing this framework helped me think through career guidance in great depth and that has helped make my advice to others clearer. I sometimes refer back to it when helping to weigh or appraise feedback, during salary discussions, or when writing job specs.

Putting the framework in Progression really helped to compare our framework to other engineering companies and to benchmark our internal levelless ranking system to common industry levels. Sometimes I can use it to explain to our younger engineers that no, they would not be ranked as principal engineers at Google, yet!

The process of iterating on the framework together was valuable. Asking and discussing feedback helped to align our leadership’s thinking about how we appraise and value our colleagues. Beyond leadership, trying to describe very different work in common terms (dev and ops, for example) helped the people involved to understand more about each other.

Our HR professionals happily adopted the framework, for example to develop and finetune our internal leadership training. For my HR colleagues relatively new to IT organizations it really helped them to see and understand both the breadth and the depth of our careers.

Failure!

This framework hasn’t helped our engineers or their coaches! My colleagues may look at it, perhaps understand it as reasonable and sensible…and then will never use it during their career planning or career development conversations.

People are unsure why, but they tell me the framework “doesn’t feel right”.

I believe one problem is that the level of abstraction is so high people don’t know how to apply it for themselves in a practical way. Making more concrete roles (like “java developer”) with more concrete skills (like “java programming”) could help, but that’s a lot of work to set up and maintain.

I believe another problem is that the setup is still too constrained: our actual appraisal system is more free-form. I imagine if we were to strictly define career levels that would then prompt more colleagues to use this framework. Especially if we linked the levels to salary ranges. And…I don’t know that would be positive. SBP tries to be a place where all our colleagues can “become who they are”, which for many colleagues can mean quite an “unbalanced” set of competencies.

The framework also hasn’t helped me! Our non-technical coaches have difficulty using the more technical competencies. You need an experienced technologist’s help to evaluate the quality of your solutions designs or implementation plans, to determine how competent you got. It sucks to have a conversation about those things with a non-technical coach.

So in the end even if my colleagues do use this framework, they will still ask for my help, and I save no time!

Fortunately, it’s the kind of conversation I love to have.

Permanent contract vs 1-year contract

Dutch employment law can get pretty complex, making the non-financial terms important when evaluating salary. One key factor is whether you’re looking at a permanent contract or not.

For more senior positions, permanent contracts are common. If you do your job well and the company is doing ok financially, your employer cannot easily fire you from a permanent contract, which makes these popular with risk-averse employees and unpopular with commitment-averse employers.

For more junior positions, 1-year contracts are common. 1-year contracts often get automatically extended, and then can convert into permanent contracts automatically after 3 years.

Getting a mortgage is harder without a permanent contract since banks are also risk-averse.

The base salaries for both contract types tend to be comparable, but permanent contracts usually have better non-base salary benefits leading to a better total benefits package.

Common benefits package components

A Dutch contract usually has a yearly salary listed for a full-time job. Usually full-time for developer jobs means 40 hours a week. If you work less hours you will be paid proportionally less, while if you structurally work more you typically do not get paid for that at all.

The base yearly salary includes 8% yearly holiday allowance, which is usually paid once a year in May. In May you receive 15.67% of your yearly salary, while in all other months you receive 7.67%.

Discretionary bonuses are now reasonably common in Dutch IT companies, paid out yearly, with 5%-20% of your yearly salary reasonably common, and 10% probably the most common percentage. Usually discretionary means that your manager informs you once a year if you get your bonus and how much you will get, i.e. your employer can decide for any reason not to pay you the bonus.

It is uncommon for Dutch employers to actually promise bonuses, or otherwise tie bonus payout to profits or performance targets in a transparent way. When that arrangement is written into your contract it is a performance bonus instead of the common discretionary bonus, which you may encounter for more commercial roles (i.e. a role as a presales engineer).

Stock options, shares, employee ownership plans, and profit sharing agreements are relatively uncommon for Dutch IT companies. Even when they are used, the “standard” approaches that exist in the US tech industry for stock options are not standard here, which means most US-centric advice on the internet about such things does not apply. The actual benefit of such programs relative to base salary can range from pretty neglible (more common) to pretty dominant (rare).

Cars in The Netherlands are expensive to own and drive, due to how taxes for them work as well as due to high taxes on gas. Lease cars are common, where your employer arranges a car for you (often of the type and with the options you choose) with a leasing company. Your employer pays for your car every month, including for any gas used. If you also use this car for non-work travel then you have to pay extra income tax based on the catalog value of the car. If you like driving a modern car this usually works out cheaper than other approaches. At some employers, lease cars are getting replaced with mobility budgets or public transport passes.

A full-time contract includes a mandatory minimum of 20 vacation days. These are a legal right; you might see them as a government-mandated benefit. Many employers include extra vacation days above 20, sometimes with various differing rules for exchanging days for cash, buying extra days, and so on. Besides vacation you also have rights to parental leave, sick days, and so on.

Paid overtime and standby shift compensation are rather uncommon for developers. If your contract does include paid overtime it is likely based on extra hours worked per week or month, which means tracking all hours. Night or weekend hours may be paid at 150% or 200%. Working a lot of overtime can mean quite significant additional income.

Most permanent contracts will include a pension, for which there are many different and confusing different setups that are hard to compare and value. It’s common these days that your employer pays some monthly amount into a fund on your behalf that is based on a combination of your base salary plus your age, with the amount being only a few percent for people under 30 and quite a lot for those close to retirement. The fine print around Dutch pensions is often more complex than for the rest of the employment contract combined.

Many employers also mention providing the things you need to do your job (like laptops, phones, and training budget) as benefits, or they point out lunch or snack arrangement or fun company events. While of course it’s nice if an employer provides such perks, when contrasting offers financially most of these are usually not significant. It’s also very rare for these perks to be promised contractually.

One aspect that is not considered a perk is what working from home arrangements have been made. Besides your own preferences around this, not having a daily commute may save you money & time, while not having your home office setup paid for may cost you money or health.

Salary ranges

Dutch developer salaries are perhaps €43k average, compared to €38k median salary across the country for all jobs. I’ve never heard of a developer making half that average, while double the average and more does happen. Most developers make close to and perhaps a bit less than the average, while a select few developers make a lot more. What’s going on?

• Senior developers switch into different higher-paying jobs that have different titles, like architect, manager, or consultant.
• Senior developers go freelance, so they write invoices instead of receive a salary.
• Senior developers don’t do things to increase their salary, instead doing things they find more fun or interesting.
• We have no idea what individual developers are worth, so there are few good arguments for employers to pay much higher than average.

Even for those salaried developers that do continue to hone their craft and gain the experience that clearly makes them more valuable, I believe the salary curve flattens out. A bit of this is simply due to how The Netherlands thinks about what’s a fair distribution of income. A bit of this is because developers don’t like salary negotiation so their employer ends up paying them what they can, instead of what they are worth.

Evaluating benefits packages

With all that basic understanding in place, you might now enjoy playing with this google sheet of example developer salaries that I invented to make the above graph:

The sheet might help as a baseline for evaluating different benefits packages and contrasting some different salary ladders against a simple baseline. The absolute values are probably less useful, though I did attempt to have them be reasonable based on my own experience and some general awareness of 2021 numbers at a couple different companies.

Sample goal: cool company where no-one worries about money

FAANG pay high salaries but not everyone wants to work for them. You may choose to work for a smaller company, or a cooler one, or one with better values. Perhaps then we can pay a bit less?

Let’s look for a really cool small company with solid values, and see what they pay. Bryan Cantrill’s Oxide Computer pays everyone who works at their company a $180k base salary (€160k). That is enough:

1. to live comfortably with 3 kids in the Bay Area;
2. to be in the top 5% of income in the US;
3. to not worry about money, even when putting extra organic raspberries in your shopping basket.

They also provide good benefits like healthcare and stock options. For them, €160k is enough to take money of the table as a employee demotivator, enough to assemble a great team.

The people that work at Oxide Computer could earn more at other employers. That’s ok: beyond some amount, more money simply matters less than other things, like pursuing autonomy, mastery, and purpose. What they offer candidates is something like join a great team, try to make something cool following decent principles, live comfortably, and have a small chance to become independently wealthy.

While it’s not a goal for them forever, Oxide so far has (quite) senior engineers only, of which Bryan writes “engineers at the earliest stages of their career are unlikely to be a fit for us right now”.

Let’s imagine we start a similarly cool company, with similar hiring goals, but in Amsterdam, The Netherlands. Let’s imagine we want to hire (someone like) Bryan as our first awesome senior engineer. He’ll get options or shares of course, and a nice pension, and so on, but what base salary should we pay him so money is not a worry?

€76.000?

The estimated modal income in The Netherlands for 2022 is €38k gross. €38k is the income where 50% of employees make less and 50% make more than that. An example of a job where you can expect to make about €38k is as a nurse with a college degree.

€76k is double that modal income. Ignoring market conditions, I consider double-modal quite a decent benchmark salary for individual contributor senior software engineers with a lot of experience.

• Until our recent housing crisis, a double-modal income was enough to buy a house, support a family, and otherwise live quite a comfortable life in The Netherlands;
• €76k is more than the average senior software engineer makes in The Netherlands, which is probably about €60k;
• Above-average does seem reasonable to me, after all this is Bryan Cantrill we’re trying to hire!
• It feels right to me.

Unfortunately, with the rising house prices, €76k salary is currently not enough for Bryan to buy a comfortable Amsterdam family home, and it’s definitely not enough for unlimited organic fruit. We should deal with our housing crisis and make healthy food cheaper, but in the meantime…

€100.000??

1. To live in a modern 4 bedroom house in the greater Amsterdam area, Bryan’s mortgage will be about €550k, for which he will need a salary of about €100k;
2. He’ll pay about 40% income tax, so will have net income of about €60k, which puts him in the top 5% of income in The Netherlands;
3. After base costs, perhaps €30k remains as disposable income, which should be plenty for all the raspberries he’d like, plus a couple of family ski trips a year, plus buying carbon offsets for that trip.

€100k ought to be enough of a base salary based on the goals we picked. It’s is a lot more than most software engineers make in The Netherlands, but $180k is of course also more than most software engineers make in the USA. We want excellent people so we will have to pay an excellent salary

€140.000???

Most expats prefer living in Amsterdam itself instead of merely close to it. It’s nice when the staff at the local organic grocery shop speaks fluent English as they point out the organic raspberries isle. To live in Amsterdam itself, Bryan’s cost of living goes up a lot, especially for housing.

1. He will need perhaps an €800k mortgage, for which he needs a salary of about €140k;
2. His taxes will then be a bit higher too, for a net income of about €80k, which now puts him in the top 2% of income in The Netherlands;
3. Perhaps €35k of that is now disposable income, still plenty for those more expensive Amsterdam raspberries.

Beyond just money, the living standards for the top 5%/2% of earners in The Netherlands are arguably quite amazing compared to the Bay Area. After all The Netherlands is one of the best places to live in the world! Rather than try to flesh out that argument here I’ll point out the excellent YouTube channel NotJustBikes.

So is this €140k enough to get Bryan to join us? Of course €140k isn’t €160k…but since The Netherlands is so awesome, it does seems somewhat reasonable to me to have to take a bit of a paycut to live here, just like it also seems reasonable to take a bit of a paycut to work for an amazing company such as Oxide Computer. That 12% paycut might be ok to Bryan, and is a bit less than the 15% cost of living difference between the Bay Area and Amsterdam, so day to day it may not feel like a big paycut to him.

€160.000????

It’s 2022 and many US tech companies are all-in on full-remote work, often no longer adjusting for cost of living when setting global salaries. More and more of these companies will pay those Bay Area salaries over here, so to be globally competitive in the job market €160k now really is the rate to match and that’s what our imaginary Amsterdam startup should probably do.

Wow. While €100k is already considered a high salary by most Dutch standards for just about any regular job, €160k plus benefits is more than most Dutch software engineers imagined they could make at any point in their careers. Over here that €160k makes you a part of the 1% even before considering the rest of your benefits package. Many software engineers are loyal employees who don’t like to change jobs, but finding out a life-changing amount of money is perhaps on offer (while building cool things with Bryan Cantrill, no less!) many of us are tempted!

On the other side of the negotiating table, as a hiring manager who pays their engineers €76k or perhaps €100k and thinks that it is quite a generous and reasonable amount, it can be jarring when we hear that those same engineers now earn 60-100% more somewhere else for the same (or more fun!) work. Should we try and somehow match the US salaries, or, should we accept we’re not a globally competitive employer and risk losing some of our best people? Ugh! That also doesn’t feel right.

How high will salaries go?

Over the last few quarters a lot of Dutch employers are bumping engineering salaries by 10-20% or more, German IT salaries are going up fast too, and probably this really is true across Europe. Employers are trying to remain competitive in the job market…but is a 10% bump enough when 60% or 100% more salary is on offer elsewhere?

Since the scarcity of senior software engineers won’t be fixed change quickly, and the BigTech companies can afford to pay a lot, it seems like the top global salaries are poised to still go up further in the short term, in turn creating further strain in our local job market, and keeping the money topic on the table for most IT employers and employees everywhere.

Will salaries come back down?

Perhaps. The global economy seems to be overheating. It could be we are in another bubble, which could burst, which could turn the scarcity of engineers into surplus of engineers really quickly as investment drops. Since no-one really understands how the global economy works, it’s hard to be sure.

(Disclaimers: I work in outsourcing, not at a startup. I work and live in the Amsterdam area but not in Amsterdam itself. This is not how compensation is set up where I work. I make a lot less money than Bryan Cantrill, who was also not consulted about this blog post (I owe you some raspberries, Bryan).)

To fight your own bias think: “I don’t know”. Question your own thoughts, knowledge and beliefs, often, more than is comfortable. This will improve your thinking and reduce your bias. The more you question yourself the easier it gets.

To help others fight their bias, lead by example. Say “I don’t know” out loud. By saying it you make it easier for them to think and say it too.

To think and work together, listen to and try to understand others with a mindset of not knowing. If our own position is unsure we are more open to ideas of others. As a leader in a group conversation you can say: “I don’t know, what do others think?”

I don’t know any of this for sure! I think the above is good advice because scientific and philosophical content points in this direction and (I think…) I have some experience with it myself. But don’t take my word for it!

Frank Meester is a Dutch philosopher who has written a new book

Waarom we de wereld niet rond krijgen: pleidooi voor inconsequentie
(“Why we can’t make the world whole: plea for inconsequence” – amazon | bol | libris)

I found the book’s form almost as interesting as its main ideas. On the one hand it’s a “properly” structured philosophical work with a clear argument that’s built up and examined from several perspectives, and supported with many references to prior work (including Kant, Wittgenstein, Sartre, Peirce). On the other hand it’s an accessible story that’s full of casual and witty sentences, anecdotes, and modern cultural references, never taking itself too seriously for too long, and taking care to provide simple explanations for all philosophical concepts referenced.

I think this dual form works well to get across the main idea. Meester’s main point in the book is to introduce his own new philosophy dubbed inconsequentialism, which is summarized in his main statements:

1. It isn’t possible to tell a consistent or consequent story about life.
2. Because total consequence is not possible, we do not have to find it annoying when we don’t quite succeed at it.
3. In practices almost everything is a little bit possible.
4. A little bit is already quite something.

At first these seemed almost trivial statements to me that could hardly be the basis for a full book, but Meester diggs into them and their impact in quite some detail. In the first part of the book Meester reviews logic and reality for their inherent (in)consistency, building his philosophy on top of work by primarily Wittgenstein and Kant, assisted with reference to modern physics and quantum physics. In part two he moves on to consequences of his inconsequentialism, looking at pragmatism, the hermeneutic circle, ethics, and determinism. In part three he contrasts his inconsequentialism with existentialism, humanism, absurdism, and performativity.

The weakest part of the book for me is where Meester dives into physics and specifically quantum physics, subject matter he admits he is not too deeply familiar with. For some reason it is pretty popular these days to take the small scale awkwardness of quantum physics to make large scale arguments about the nature of nature, and Meester does the same. But the instances where that scale-up makes sense in nature are a rare exception to the rule that in the large you can usually get by with Newtonian physics, a rule that ought to mostly carry over to philosophical constructs. Fortunately most of Meester’s argument still holds up even when rejecting his view on modern physics.

I guess Meester’s incosequentialism might be very Dutch. In many ways it’s a modest and moderate philosophy, down-to-earth and practical, forgiving and reasonably applicable to daily life. As far as philosophies go, this one lacks grandeur, does not strive for greatness, doesn’t strongly critique or fully reject the ideas that came before. Instead Meester is poised to get along about equally well with influential Greeks, German, French and American philosophers.

I guess if Meester’s very Dutch, I might also be very Dutch, because I find this book to be closer to my own personal philosophy than most other philosophical work I’ve read recently. By rejecting absolute/simple answers to typical philosophical puzzles as well as the absoluteness/simpleness of those puzzles themselves, there’s room for nuance. For example:

• It’s good to try to live the good life, even if it is hard to have an exact definition of what the good life is or to be perfect at living it.
• It’s good to have lofty dreams and ideals, while it’s also ok to have practical pragmatic compromise when it is not possible to reach the ideal.
• Compromising on ideals doesn’t make the ideals bad or useless.

I find such thoughts hopeful and comforting. If you can read Dutch I can recommend this as an accessible and enjoyable book, even if normally you don’t read philosophy. (As far as I can tell the book has no English translation yet but I’ll update this post if that changes.)