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

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/