It’s not always easy to keep these separate, especially when one’s vocation transcends mere occupation to become a genuine passion and source of fulfillment.

The job [...] starts with great enthusiasm, but may evolve to reveal fundamental incompatibilities.

it seems almost predictable that when someone works defining design principles for their clients all day, they don’t necessarily stop and think: Oh, maybe I should apply these same methods to my own life as well.

“One of the choices I’m most proud of is that early on, I realized that what success looks like for me is freedom and curiosity and the ability to follow whatever path I take.”

Freedom, Curiosity, Happiness, Authenticity, Love

It made them a subscription model:
▫️ Lust → Tinder
▫️ Gluttony → Uber Eats
▫️ Greed → Amazon
▫️ Sloth → Netflix
▫️ Wrath → X
▫️ Envy → Instagram
▫️ Pride → LinkedIn

I like the menu at the bottom, and the simple yet clear introduction.

While copying the code, the right abstraction reveals itself.

If you start too early, you might end up with a bad abstraction that doesn’t fit the problem. You know it’s wrong because it feels clunky. Some typical symptoms include:

Removing a wrong abstraction is hard work.

Clean up afterwards :)

Part 1: https://shaarli.lyokolux.space/shaare/-zGjpg

1. Stop doing the agile theater. Drop the ceremonies that aren’t helping. Cancel one meeting. Stop pointing stories if it just leads to negotiation and resentment.
2. Show real things: monitoring and alerting. When teams know they’ll see when something breaks, they get bolder. Safer. Smarter. They write better tests. They clean things up before shipping. And they stop emailing the ops team after hours.
3. Give a damn about the again again. Refactoring is how teams stay healthy. The minute a team has to ask permission to fix something they just touched, you’ve lost. Every line they don’t improve is a tax on the next change. And the next. Until nobody knows how it works and your best developer ragequits into a DevRel job.
4. Put the Product back in the room: a good Product Owner is available. They answer questions. They clarify intent. They help you understand why a feature matters. When product and engineering work together like adults, you don’t need a sprint review to get aligned.
5. Stop scaling, start coordinating
6. Eventually the process quietly disappears- That’s when we realized Agile wasn’t the thing helping us anymore—we were just doing the work.

What It Feels Like When It’s Working?

It’s quiet. Calm. Focused.

People are talking, but not in meetings.
They’re shipping, but not sweating it.
The process is invisible, because it’s doing its job.

Nobody says “Agile” anymore, because they don’t have to.
They’re just building good software—together—and getting better every week.

Changer d'entreprise après 25 ans

Upon closer examination, these analogies hold: What does the pragmatist prioritize less? Quality. (Note: “less,” not “not at all.”) What about someone driven by passion? They likely sacrifice speed. And the perfectionist? Is aware of and ready to foot the increased cost.

https://www.ouvretaferme.org/

C'est plus une plateforme d'aide. Je remarque que tout informaticien qui se reconverti peut apporter son expérience et développer un produit en adéquation avec ses besoins.

We ended up deciding: what the heck, we might as well meet the market demand. So we put together a bespoke ASCII tab importer (which was near the bottom of my “Software I expected to write in 2025” list). And we changed the UI copy in our scanning system to tell people about that feature.

I am not sure it's a market demand, but only a ChatGPT hallucination.

Deleting lines of code for optimisation and better maintainability.

I’m a web developer with ADHD, and I help people build the web better.

Builder of Kelp UI.

Blog: https://gomakethings.com/articles/

Instead of asking: I’m hungry, let’s go to McDonald’s

Why not: I’m hungry, let’s go eat: McDonald’s?

A “no, because” statement instead of a plain “no” moves the problem from a blocker into an opportunity.

1. In Rust, this struct is 16 bytes (on x86_64, again) and in C, it is 24. This is because Rust is free to reorder the fields to optimize for size, while C is not.
2. Social factor: it is more convenient to write a bite more dangerous code than in the equivalent C. Firefox failed two times to parallelize Firefox's style layout twice. They get it right the third time with Rust. Does a junior write faster production code in Rust than in C?
3. Compile time vs runtime: Rust provides a bit of safety at runtime (index access)

If C is the fastest language, is there any inherent reason why Rust could not do the same things? At the fundamental level, the answer is “there’s no difference between the two.”

But projects does not work only on the fundamentals, "We’re usually talking about something in the context of engineering, a specific project, with specific developers, with specific time constraints, and so on. I think that there are so many variables that it is difficult to draw generalized conclusions."

Do not accept “we’ll figure that out later” as a response to pointing out meaningful problems. It’s a con.

Solve the problems or abandon the project.