• think about naming
• don't be afraid to say "no"
• code review is communication
• use multiple iterations of reviews
• don’t be a jerk
• try to run the code
• an opportunity to learn things
• avoid nitpicking
• ask stupid questions
• ask for feedback on the review style

I used to be on a team that was responsible for the care and feeding of a great many Linux boxes which together constituted the "web tier" for a giant social network.

At some point, I realized that if I wrote a wiki page and documented the things that we were willing to support, I could wait about six months and then it would be like it had always been there. Enough people went through the revolving doors of that place such that six months' worth of employee turnover was sufficient to make it look like a whole other company. All I had to do was write it, wait a bit, then start citing it when needed.

One near-quote from that page did escape into the outside world. It has to do with the "non-compliant host" actions: "Note: any of these many happen without prior notification to experiment owners in the interest of keeping the site healthy. Drain first, investigate second."

So the author created a list of actions; methods to apply for any given events.

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."

Being competitive, to me, means:

• being able to work on most of the issues I want in the company in some fashion
• having accumulated a certain stature and respect from both the engineering and business side which I can trade for space and agency
• being in a place where I can break company soft/hard rules to get things done.

Looking back at the process to get to that place trying to reverse-engineer it, a lot of it boils down to building relationships, maximizing knowledge acquisition and shipping.

The author describes a strategy for identifying and learning from the most impactful people in a company. He first tries to find the company’s “wizards” — the small group of people who contribute disproportionately to important work. This involves evaluating:

• How others perceive and talk about them
• What they actually do and how closely their work connects to the company’s core systems
• The quality and impact of their code or output
  After identifying these high performers, the author studies them closely by following their communication, reading their work, reviewing their projects, and understanding their areas of expertise and relationships across the organization.
  The ultimate goal is to learn from these people, absorb their knowledge and skills, build strong working relationships, and become someone they want to collaborate with. The key idea is that proximity to exceptional people accelerates personal growth and effectiveness.