Whether you are a software engineer, a lawyer, a manager, or an entrepreneur, your value is directly correlated with how efficiently you can process new information to stay relevant in your field in an ever-accelerating world.

But there are two problems.

The first one is that today, there is simply too much information available and it's hard to extract signal from the noise.

The second problem is that knowledge ("white collar") jobs are evolving faster than the capacity of most people to learn new things. For example, today, you are a software engineer developing backend applications, and you may want to move into machine learning with all the recent and exciting advancements.

Good news: Knowledge follows the law of diminishing returns. By spending two weeks studying a topic really hard, you can assimilate the most important principles and become better than maybe 90% of the people on this plane

Perhaps the most unusual thing about my career trajectory is that I’ve been at the same place for twenty years now. That’s pretty much unheard of in tech. It’s far more usual to see people switch companies—and get a salary bump—every couple of years.

Si vous êtes convain­cus que le télé­tra­vail est la meilleure façon d’or­ga­ni­ser le travail, vous allez instau­rer une culture et une orga­ni­sa­tion qui va avec. Ça peut être plus d’écrit, plus d’asyn­chrone, un dépla­ce­ment du budget des locaux vers le maté­riel ou vers des événe­ments ponc­tuels dans l’an­née pour se retrou­ver, ou quoi que ce soit que vous imagi­nez.

Si l’IA augmente la produc­ti­vité1, la baisse des coûts va libé­rer une masse de demandes qui n’étaient pas rentables avant et qui le devien­dront. Plus on baisse les coûts, plus la demande va être massive.

L'auteur pense plutôt que ceux n'utilisant pas l'IA seront lésés. On pourrait faire la même analogie avec les LSP des IDE par exemple.

1. The apology estimate
2. Deploy fear
3. The “Don’t Touch That” File
4. The Coverage Lie
5. Time to first commit

The author has a signal score from 0 to 2 for each points.

Exception is indeed a bad programming ergonomic that can lead to many failures

Take: Simple software engineering does get rewarded, and on balance will take you further in your career. In a year’s time, the simple engineer will have a much longer list of successful projects, and a reputation for delivering with minimal fuss

But the main reason for the counter-argument is exactly the cynical point above: most managers are non-technical and cannot judge the difficulty of technical work.

Most managers do not care about the engineering, they care about the feature.

1. Monotonicity (and immutability)
2. Pre- and post-conditions (assumed to be true just before the runs, post-conditions are things that are assumed to be true just after the function returns)
3. Invariants: things that should be true before, during and after that code runs.
4. Isolation: every change has a "blast radius" - a change to one part of the code may necessitate a change to another part to ensure the consistency/correctness of the whole system.
5. Induction: a proof technique for handling recursive structures

As second recommendation: "you should try to write your code in a form that's easy to write little proofs about"

C'est une opportunité pour les créateurs de produits pour sûr.

Là où avant le “technical founder” passait tout son temps à coder le produit et vivait la tête dans le guidon avec un gros handicap pour penser long terme sur le produit, gagner du temps me permet de rééquilibrer la balance.
J’adore coder. Mais coder me prenait du temps de cerveau sur la stratégie.
Ce n’est plus le cas.

C'est aussi du temps pour en finir avec les "choses qu'on verra plus tard", qui finalement redevienne possible.

C'est aussi du temps libéré pour se former.

Mais récemment j’ai pu me documenter et écrire des articles sur l’état de l’art autour des questions de modérations sur les plateformes de contenu, je me suis penché sur le fonctionnement des attributions de certificats SSL, le fonctionnement des proof of work sur les captcha. J’ai creusé des sujets comme la parité de pouvoir d’achat.

Cela pousse aussi la productivité horaire vers le haut, entre autres via [l'ennui](http:// https://eventuallycoding.com/p/2023-03-accept-boredom).

S'ensuit ensuite un argumentaire démontrant que l'IA doit éviter de nous aider à faire plus, mais à faire mieux.

Et c’est là où je me demande si le forfait, la facturation au résultat, ne pourrait pas devenir plus avantageux que la facturation au temps passé.

Il s'agirait donc de facturer au résultat, au forfait, au lieu du temps passé.

Un autre biais lié à l'augmentation du coût par l'IA, c'est de penser que l'augmentation de la productivité d'un senior est constante et apporte uniquement des bénéfices. Passer sa journée à vérifier du code, ce n'est pas sain non plus.

Et les managers, les mêmes qui poussent à l’utilisation de délégations, le savent. Très bien. Ils et elles n’ont pas 60 subalternes directs, jamais. Parce qu’encadrer et endosser la responsabilité pour la production d’un tel flux de travail est impossible.

Ajoutez à ça :

• l’érosion des compétences des salarié·es senior, qui est quand même la principale conclusion de l’étude qu’Anthropic a mené ;
• la réduction des embauches des juniors, qui auraient dû être les seniors de demain via le mentorat de leurs pairs

Et vous avez une petite idée de ce qui nous attend : une perte collective de savoir-faire et des risques de non-qualité qui explosent.

Cela ressemble à l'offshoring

The revenue numbers back this up. App Store grew 11% in 2025, Google Play 5%. There's still tons of unmet demand, especially for niche use cases that were never worth building before. Lower development costs mean these niches finally get served.

For apps that run locally—no servers, no cloud costs—subscriptions make no sense anymore. The only real cost is development, and that's becoming negligible.

This sucks for developers trying to make a living from apps. The competitive pressure is going to be brutal. But for users? It's great. People have been complaining about app subscription costs for years. There's that old complaint: "Why do I have to keep paying for software after I already paid $1000 for my iPhone?"

If one employee is using AI

your employer captures 100% of the value from you adopting AI. You get nothing, or at any rate, it ain’t gonna be 9x your salary. And everyone hates you now.

And you’re exhausted. You’re tired, Boss. You got nothing for it.

Compared to the 80', time moved slowly in the sense that news and events were spaced way out and society had time to reflect on them. Now it changes so fast we can’t even keep up, let alone reflect.

Crazy addicted early adopters like me are controlling the narrative and make it unrealistic
You can’t stop reading about it in the news; there’s nowhere to hide from it.
Panicking CEOs are leaning in hard to AI, often whiplashing it into their orgs.
Companies are capitalistic extraction machines and literally don’t know how to ease up.

and we’re all setting unrealistic standards for everyone else.

$/hour. "I told the grumbler group, you can’t control the numerator of this ratio. But you have significant control over the denominator. I pointed at the /hr for dramatic effect."

Why did such an experienced leader make such an terrible mistake?

The promises made didn't hold the reality delivered.

• switching to Perl would unlock the architecture we need, rebuilding from scratch would accelerate hiring and quality)
• velocity collapsed as the team relearned and rebuilt everything, burn rate jumped from 200K to 500K per month

One strategy: how you evaluated other language candidates?

Every technical debate is really two conversations: the visible and marketed one and the (stronger private) invisible one.

The real question is: can you afford to let it make your decisions?

Because the invisible conversation has a price tag. Industry research suggests that technology stack decisions account for 40-60% of total development costs over a product’s lifecycle. Research by Stripe found that developers spend 42% of their time on technical debt.

An better question is "what is this language going to cost us?" in velocity, technical debt, hiring difficulty, operational complexity.

spf13 published a framework to estimate it: https://spf13.com/p/the-9-factors/

"Vibe coding" is a trendy expression for "Automated coding".

Automated programming especially allows me to quickly build the tools I need so fast that every blacksmith that ever existed on this earth would envy me deeply.

With the automated coding, "we can finally get rid of all that middle work. That adapting layer of garbage we blindly accepted during these years. A huge amount of frameworks and libraries and tooling that has completely polluted software engineering, especially in web, mobile and desktop development."

The frameworks claim to solve three problems: simplification, automation and labour cost. "You unlock a feature that has nothing to do with engineering: you no longer need to hire a software engineer. You hire a React Developer.

Software engineering is back in a sense again: We have the chance again to get rid of useless complexity and keep working on the true and welcome complexity of our ideas, our features, our products. The complexity that matters. The complexity that is actually yours.

Automation and boilerplating have never been so cheap to overcome. I’ve been basically never writing twice the same line of code. I’m instantly building small tools I need, purpose built, exactly shaped around the problem at hand. I don’t need any fancy monorepo manager. A simple Makefile covers 100% of my needs for 99% of my use cases.

Bash, makefiles, ...

Think about it

1.There are three states of being. Not knowing, action and completion.00

2. Accept that everything is a draft. It helps to get it done.
3. There is no editing stage.
4. Pretending you know what you’re doing is almost the same as knowing what you are doing, so just 5. Accept that you know what you’re doing even if you don’t and do it.
5. Banish procrastination. If you wait more than a week to get an idea done, abandon it.
6. The point of being done is not to finish but to get other things done.
7. Once you’re done you can throw it away.
8. Laugh at perfection. It’s boring and keeps you from being done.
9. People without dirty hands are wrong. Doing something makes you right.
10. Failure counts as done. So do mistakes.
11. Destruction is a variant of done.
12. If you have an idea and publish it on the internet, that counts as a ghost of done.
13. Done is the engine of more.

There is also an illustration for it

Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

git actually has a simple design, with stable and reasonably well-documented data structures. In fact, I'm a huge proponent of designing your code around the data, rather than the other way around, and I think it's one of the reasons git has been fairly successful

The actionable tip here is to start with the data. Try to reduce code complexity through stricter types on your interfaces or databases. Spend extra time thinking through the data structures ahead of time.