En réalité, cela introduit un coût immédiat.
Chaque abstraction anticipée augmente :

• le temps de développement
• le temps de review
• la difficulté d’onboarding
• la surface de bugs potentiels
• la complexité du debugging
• la quantité de tests nécessaires
  Et surtout :
• le besoin anticipé peut ne jamais arriver.
  Mais même si ce besoin arrive un jour, un autre problème apparaît. La solution que nous avons imaginée n’est peut-être pas la bonne.

Because the problem is so low-level to solve that the Rust guarantees can not work properly at this assembly code level.

Safe wrappers can be built upon it though.

• not memory safe (thread access, ...)
• error handling
• garbage collected
• used to directly call sys calls
• can trigger MTE on Android because Go reads the whole page of memory to access a string

It's not a bad language: It's often easy to write a full production ready server using only the standard library. In 2026 this is becoming more of a feature due to the ongoing supply chain attacks. Go itself also has some great technologists working on the project who are extremely responsive and care very deeply.

The library parses rich schemas (nested sections, $ref, arrays, key/value maps, pattern properties…) into a navigable form tree, renders it as a keyboard-first editor, and validates the result after every edit so users always see the full list of issues before saving.

It can be useful someday

C'est ce qu'on fait: tester en tant qu'utilisateur. C'est le minimum, je dirais même avant les tests automatisés.

Les tests valident le code
l’usage valide le produit.

En comparant la réalisation du ticket avec l'essai du produit en tant qu'utilisateur:

Exécuter un ticket est simple :

• lire les requirements
• implémenter la logique
• écrire les tests
• ouvrir une pull request

Tester réellement le produit demande un effort différent.
Il faut :

• suivre le parcours complet
• imaginer les actions d’un utilisateur (se mettre à sa place)
• tester des scénarios inattendus.
  C’est plus lent, et demande de l’empathie.

Les pièges a éviter:

• readme cimetière
• theator of documentation: useless comments
• outdate trap: "how" is a wrong answer
• un ROI négatif.(Lectures × Temps gagné) - (Temps d’écriture + Maintenance).

Pour maximiser ce ROI, il faut distinguer quatre types de documentation :

1. ROI Infini : La doc fonctionnelle (le problème). C’est la boussole de la feature. Elle ne décrit pas les boutons, mais la valeur.
   • Le contenu : À quel problème client répond-on ? Quelle est la vision à 6 mois ? Quelles sont les limites actuelles (ce qu’on a décidé de ne pas faire) ?
   • Pourquoi c’est crucial : Sans elle, un dev qui itère sur la feature 1 an plus tard risque de supprimer un comportement “bizarre” qui était en fait une réponse vitale à un besoin client.
   • Le public : Elle est le pont entre la Tech, le Produit et le Marketing. C’est la doc qui aligne tout le monde.
2. ROI Élevé : La Doc d’Intention (l’histoire).
   • Pourquoi ce choix ? Quelles étaient les limitations ? C’est ce qui survit aux refactos (ex: les ADR - Architecture Decision Records). N’importe quel dev peut comprendre votre code, mais personne ne peut deviner une intention métier disparue.
3. ROI Opérationnel : La Doc d’Usage (le manuel). Le strict nécessaire pour être autonome. Par exemple le guide du “Day One”. Si je ne peux pas lancer le projet à tous les coups en quelques minutes lors d’un onboarding, le README a échoué.
4. ROI Négatif : La Doc d’Implémentation. Les détails techniques changeants. C’est du “Waste”. À supprimer au profit d’un code propre, typé et bien nommé.

La documentation est écrite pour être lue, sinon elle est nulle. Une bonne documentation doit être compréhensible par la majorité de l’équipe (Tech, Produit, voire Marketing).
Le vrai danger lors d’une passation, ce n’est pas la perte du “savoir-faire” technique, c’est la disparition de la compréhension du système.

About the <picture> syntax which the author finds great.

On the contrary, the srcset and sizes attributes on one image are hard to use. "So, we are left describing the all of the sizes that an element will be, across every breakpoint and container query, as a single string, in an HTML attribute. How disgusting."

A tool is neede to write media queries in the sizes attribute.

How is a tool supposed to generate (min-width: 1340px) 257px, (min-width: 1040px) calc(24.64vw - 68px), (min-width: 360px) calc(28.64vw - 17px), 80px though?

The author proposes to bury this attribute and use sizes="auto". The developer can rely on loading="lazy" to load the images after the layout is computed, thus the browser know the size in advance.
sizes values remain a must have for images displayed way up at the top of the page... well sizes="100vw" is a good fit for it, isn't it?
All other images? loading="lazy" sizes="auto"

The idea seems good. Another ID format: 16 bytes like UUID v4 and v7. The key difference is they are monotonic, but that's something UUID v7 and ULID can have.

The structure:

Timestamp: 8 chars · ms since epoch · good until year 6028
Counter: 6 chars · randomly seeded · monotonic
Random: 7 chars · cryptographically secure randomness

The landing page uses catchy things without real correlation: 23M SparkIDs/sec in Rust. Ok but with which hardware?

Customer research is always quantitative. The start the next Google with venture capital. That’s not true. The research is really what allows you to distinguish yourself from your competition so that when someone comes to your site.

No SEO wakes up in the morning and thinks, “Damn, I have a WordPress problem.” They wake up in the morning and say, “Damn, I have a business problem.”

As an example:

You’ve gotten this level of traffic so far with your existing site. You want to double that over the course of the next year. You were saying that the roadblocks that are stopping you are a) you’re on an outdated architecture where you, personally, have to write everything, and b) it’s been impossible to find someone who is a subject matter expert at this who can also make web pages, because that combination of interests just does not exist.

The response:

I totally understand that it is impossible to find someone who is both good enough of a journalist in the space to work for a genuine published magazine and also can edit HTML pages. I have an idea for you. I’m going to make a CMS for your website. That’s just a page that they can go into, like WordPress, and they can do their writing like they do so well. The CMS will ship it over to you, and you figure out which business model that you experimented with will work well with this content.

I pay them pretty well. I have passed on hiring engineers who may be more technically proficient, but they didn’t understand what I wanted. Honestly, guys, as a business owner, do you think I care if you’re using this technology or that? I just don’t give a damn [about technology]. I really don’t.

Nothing motivates people like having their own words repeated right back to them, which is something that you should try to do more often.

Even if you’re building a website for someone, it’s not just a website, right?

There is some particular need that they have for that website, whether it’s for their business purposes or because a lot of business owners are very personally invested in their business.

By the way, guys, for all the engineers in the audience, you sell engineering services to for profit companies because they are the only people who can pay actual professional engineer rates.

The CEO only sees it in the “This is the tool that someone I trust is doing something incredibly valuable with me on. It is cheap at any reasonable price."

Focus on taking your B+ customers/prospects to be A customers. Don’t focus on the D people, trying to turn them into A customers. It will never happen.

Author blog about the business of making and selling software: https://www.kalzumeus.com/blog/

90% of programming jobs are in creating Line of Business software. [...] Software solves business problems. Software often solves business problems despite being soul-crushingly boring and of minimal technical complexity. [...] It does not matter to the company that the reporting form is the world’s simplest CRUD app, it only matters that it either saves the company costs or generates additional revenue.

Engineers are hired to create business value, not to program things: Businesses do things for irrational and political reasons all the time (see below), but in the main they converge on doing things which increase revenue or reduce costs. [...] Add revenue. Reduce costs. Those are your only goals. [...] You really want to be attached to Profit Centers [notion from Peter Drucker]. [...] If you can’t, either a) work elsewhere or b) engineer your transfer after joining the company.

About programming languages:

In the real world, picking up a new language takes a few weeks of effort and after 6 to 12 months nobody will ever notice you haven’t been doing that one for your entire career.

Co-workers and bosses are not usually your friends: You should be a good person to everyone you meet — it is the moral thing to do, and as a sidenote will really help your networking — but do not be under the delusion that everyone is your friend.

“Read ad. Send in resume. Go to job interview. Receive offer.” is the exception, not the typical case, for getting employment: Most jobs are never available publicly, just like most worthwhile candidates are not available publicly (see here).

Networking just means a) meeting people who at some point can do things for you (or vice versa) and b) making a favorable impression on them.

Academia is not the real world. [...] Your major and minor don’t matter.

Be better at negotiation:
a) Remember you’re selling the solution to a business need (raise revenue or decrease costs) rather than programming skill or your beautiful face.
b) Negotiate aggressively with appropriate confidence, like the ethical professional you are. It is what your counterparty is probably doing. You’re aiming for a mutual beneficial offer, not for saying Yes every time they say something.
c) “What is your previous salary?” is employer-speak for “Please give me reasons to pay you less money.” Answer appropriately.
d) Always have a counteroffer. Be comfortable counteroffering around axes you care about other than money. If they can’t go higher on salary then talk about vacation instead.
e) The only time to ever discuss salary is after you have reached agreement in principle that they will hire you if you can strike a mutually beneficial deal.
f) Read a book. Many have been written about negotiation. I like Getting To Yes. It is a little disconcerting that negotiation skills are worth thousands of dollars per year for your entire career but engineers think that directed effort to study them is crazy when that could be applied to trivialities about a technology that briefly caught their fancy.

The author is negative about equity grants.

So would you recommend working at a startup? Working in a startup is a career path but, more than that, it is a lifestyle choice. This is similar to working in investment banking or academia. Those are three very different lifestyles. Many people will attempt to sell you those lifestyles as being in your interests, for their own reasons. If you genuinely would enjoy that lifestyle, go nuts.

Your most important professional skill is communication.
Communication is a skill. Practice it: you will get better. One key sub-skill is being able to quickly, concisely, and confidently explain how you create value to someone who is not an expert in your field and who does not have a priori reasons to love you.

Modesty is not a career-enhancing character trait: The right tone to aim for in interviews, interactions with other people, and life is closer to “restrained, confident professionalism.”

All business decisions are ultimately made by one or a handful of multi-cellular organisms closely related to chimpanzees, not by rules or by algorithms: People are people. Social grooming is a really important skill.

At the end of the day, your life happiness will not be dominated by your career. Either talk to older people or trust the social scientists who have: family, faith, hobbies, etc etc generally swamp career achievements and money in terms of things which actually produce happiness. Optimize appropriately. Your career is important, and right now it might seem like the most important thing in your life, but odds are that is not what you’ll believe forever. Work to live, don’t live to work.

Oh shit we are in deep trouble: names are complex to handle.

My rules of thumbs:

• they can't be identifiers
• they are mutable
• the format is so complex that a single "display name" field should be used
  • create dynamic models (or SQL tables) if you need details for legal reasons
• UTF-8 encoding is a must. All characters are allowed because I can't verify Japanese, Chinese and all the possible character dataset

As always: test on the data.

XZ stays my favorite though.

An app on the web performs better on many points. Definitely.

• distribution
• maintenance
• releases
• adoption (shareware funnel to get the desktop app running)

About the AI fatigue