career — jd:/dev/blog

How to Be a Great Software Engineer in 2026

Tue, 24 Mar 2026 00:00:00 GMT

Eighteen months ago, I wrote How to Be a Great Software Engineer. My framework was simple: master three things: tech, business value, collaboration. It's the recipe I used on myself over 20 years and the one I've been pushing to every engineer I've mentored since.

Since then, I stopped writing code entirely. And then I went back to shipping it. Not because I missed typing, but because AI changed what "shipping" means. I'm a CEO who merges ten PRs a day, none of them written by hand. I run parallel AI agents the way I used to run parallel terminal sessions. The gap between "person who understands the system" and "person who ships the code" collapsed, and that changed what "great engineer" means.

The three aspects still hold. But the weight shifted.

Tech: from writing to reviewing

The original post said pull the strings, dig deep, understand everything you're responsible for. That hasn't changed. What changed is how you use that skill.

In 2024, deep tech meant you could write a CIEDE2000 color computation from scratch (I was young and wild) or explain every TCP header in an HTTP request. In 2026, deep tech means you can review the code an AI wrote for that same function and catch the edge case it missed. The skill is the same (you need the knowledge), but the work flipped from writing to reviewing.

This is what staff and principal engineers have been doing for years. They stopped writing most of the code a long time ago. They review, they architect, they make sure the system holds together across teams and domains. AI didn't invent this role. It made it the default for everyone.

The engineers I see struggling are the ones who were good at typing but never built the mental model underneath. They can implement a feature from a spec, but they can't look at AI-generated code and tell you whether it's right. That requires understanding the system, not just the syntax. No amount of prompting skill makes up for missing fundamentals.

The 10,000 hours argument from my original post gets complicated here. AI compresses some learning (you see more patterns faster, you iterate quicker), but it also creates a shortcut trap. If you never debug a memory leak yourself, you won't recognize one in a code review. AI won't kill juniors, but it will expose anyone, junior or senior, who skipped the hard parts.

Business value: the filter got sharper

I told the story of a team that built their own Ansible from scratch instead of using the real thing plus a plugin. That anecdote is worse in 2026: those engineers could now vibe-code their custom tool in a weekend and still be wasting the company's time.

AI made the "how" cheap. At Mergify, our output per engineer almost doubled in two years. That means the difference is entirely in the "what." Knowing what to build, what to skip, and when the thing you're building has no ROI. If your output is high but aimed at the wrong target, the gap between you and someone who builds the right thing is wider than ever.

Waste also shows up faster. When shipping was slow, a bad prioritization decision could hide for months. Now you build, ship, and get user feedback in the same week. Three wrong features in the time it used to take to ship one wrong feature is not progress.

The engineers who get this are the ones who ask "should we build this?" before "how do we build this?" That was always the right instinct. Now it's the only one that matters.

Collaboration: the 100x multiplier

This is where the biggest shift happened.

My original post quoted: "If you want to go fast, go alone. If you want to go far, go together." I was talking about teammates. In 2026, "together" includes AI agents.

Managing AI agents is a communication skill. You have to write clear briefs. You have to decompose problems into pieces an agent can execute. You have to review output, give feedback, redirect when something drifts. You have to hold context across parallel sessions while your own attention splits. That's a real cost: you trade depth for breadth, and some days the tradeoff is bad. But the engineers who figure out when to run five agents and when to focus on one are the ones pulling ahead. That's not a prompting trick. That's the same skill set you need to lead a team of humans.

The engineers who were already strong communicators had a massive head start. Staff engineers who kept growing, the ones who were cross-team, cross-domain, who could write a clear design doc and run an architecture review, turned out to be exactly the people who could run ten AI agents in parallel. Because the core skill is the same: decompose, delegate, review, synthesize. (The ones who stopped growing at the wrong layer didn't fare as well.)

Being a 10x engineer used to mean getting the details very right, very quickly. Being a 100x engineer means doing that across ten agents. Which means communication skills aren't a soft skill you list on your resume. They're the actual multiplier.

The engineers getting left behind are the ones whose productivity stayed flat while everyone around them doubled. Some lack the decomposition skill: they can't break a problem into pieces an agent can execute. Others resist the workflow entirely. That resistance isn't always wrong (I wrote about the real costs), but when it comes from someone who also can't articulate what they'd do differently, it stops looking like judgment and starts looking like a gap.

The new baseline

Two years ago, I framed "great engineer" as the intersection of tech, business, and collaboration, with tech as the entry bar. Today, AI gave everyone the output floor for free. Any engineer can produce working code. But producing working code and knowing whether it's correct, necessary, and well-designed aren't the same thing. The judgment floor is still earned.

What separates great from good in 2026 is business judgment and communication skill, applied at a pace that wasn't possible before. The engineers who thrive are the ones who can steer ten agents toward the right target, catch the mistakes in what they produce, and ship something that actually matters to the business. Every day.

The three aspects haven't changed. But you used to be able to hide a weak one behind strong technical output. AI took that cover away.

The Flow Is Gone

Tue, 10 Mar 2026 00:00:00 GMT

I have seven Claude Code terminals open right now. Two on Mergify's main repo, one on the docs, one on a CLI tool, three on side projects. Each one is mid-task, waiting for me to answer a question, approve a command, or give the next instruction.

Nobody forced me to work this way. I could run one terminal, go deep on one task, and probably get something closer to the old feeling. But the leverage of running seven in parallel is too high to ignore. So I chose throughput over depth, and I keep choosing it every morning.

This is what that choice costs.

What I Said a Month Ago

In February, I wrote that "the flow state people mourn isn't gone. It's just moving. [...] The flow will come back. It'll just be at a different altitude."

I was wrong.

A month of working this way changed my mind. The flow didn't migrate to a higher altitude. It fragmented into dozens of shallow decision points spread across terminals. Briefing, reviewing, approving, redirecting. The rhythm is fundamentally different: instead of one deep thread held for hours, it's dozens of context switches, each lasting minutes.

The output is enormous. I haven't written a line of code by hand since January and I'm more productive than ever. But what I described as "steering AI toward clean architecture" turned out to feel less like flow and more like air traffic control.

What Flow Actually Was

If you've coded for long enough, you know the state. Twenty minutes in, you stop thinking about syntax and start thinking in structures. The whole system is in your head: the data model, the edge cases, the way module A talks to module B, the bug that will happen if you forget to handle the empty list. You're not reading code, you're seeing it.

"This is why you shouldn't interrupt a programmer" by Jason Heeris

That's flow. Deep immersion, total absorption, time disappearing. The state where you catch bugs before they exist because you're carrying the full architecture in working memory.

I spent twenty years in that state. It's where the best code came from. Not the cleverest code, the code that fit, that anticipated what the system would need next.

The Fuzzy Mental Model

Now I context-switch. Constantly. Terminal one needs a decision about error handling. Terminal three just finished a feature and wants me to review the diff. Terminal five hit a permission prompt. Terminal seven is waiting for a brief on the next task.

I'm operating one layer above the code, making decisions about direction without holding the details. That works when the decisions are small. It breaks when they're not.

Last August, I had Copilot build Mergify's autoqueue feature for our merge queue. Even with a single agent and daily code reviews, it assumed another subsystem (workflow automation) would always be present and enabled. That assumption was invisible in the diff. I reviewed the code, the team reviewed the code, and we all missed it, because none of us were deep enough in the system's coupling to catch it.

The bug shipped to production. Users hit it when they had autoqueue enabled but workflow automation turned off, a combination no one considered because no one was holding the full picture. We fixed it, but not before real users were affected. That was with one agent. Now multiply by seven.

That's the cost of the fuzzy mental model. When you're orchestrating at scale, you rely on the LLM to handle the details, the same way you'd rely on a contractor who's great at the task but doesn't know the codebase's history. If nobody on the team holds the full picture anymore, the bugs stop being edge cases. We haven't hit that wall yet at Mergify, but I can see the trajectory.

The Orchestrator's Dopamine

The satisfaction of building something is still there. I still feel like I built it. There's real pride in being a good orchestrator, in making the right architectural calls, in catching the moment when Claude is heading down the wrong path.

What's different is where the dopamine comes from. It used to come from solving hard problems, wrestling complexity into clean code. Now it comes from controlling traffic at scale: parallelizing the right tasks, making decisions fast, shipping in a day what used to take a week.

There's also something new: a feeling of raw power. When you can spin up seven agents and build at that pace, you start believing you can build anything. That's why you see developers shipping new projects every day on X. Creation got cheap. (Maintenance didn't.)

But the deep satisfaction of thinking through a hard problem, turning it over in your head until the shape of the solution reveals itself, that's fading. Not because I chose to let it go, but because why would I? Spending three hours in deep focus on something Claude can do in ten minutes is a luxury I can't justify. Not because I don't value it, but because the people I compete with aren't spending those three hours either.

What Gets Better From Here

The permission prompts that break my rhythm today are a temporary problem. Models get faster, sandboxing gets smarter, trust boundaries expand. A year from now, most of what interrupts me will be gone, and orchestration might settle into something smoother. Not flow, but a rhythm of its own.

And there's an upside I didn't expect: orchestration forces simplicity. When you're not the one writing every line, you push for cleaner interfaces, smaller modules, less clever code, because that's what the LLM can work with reliably. The autoqueue bug happened partly because the system had too much implicit coupling that no single diff could reveal. Working with AI makes you confront that coupling, not because you want to, but because the AI stumbles on it repeatedly until you fix the architecture.

What Doesn't Come Back

But the flow state itself, in the form I knew it? Gone.

A generation of developers is about to start their careers with AI from day one. They'll be natural orchestrators. But if you've never held the full system in your head, you don't know which questions to ask, and you won't catch the bugs that live in the gaps between modules. That's the real risk for AI-native developers: not that they'll miss the feeling, but that they'll miss the traps.

I'm not sure they'll see it that way. But I do. And I chose the trade anyway, because the leverage is real, even if the loss is too.

42 Lessons at 42

Fri, 24 Oct 2025 00:00:00 GMT

Turning 42 felt like a good time to pause and reflect.

Not on milestones or ARR charts. But on what actually matters after two decades of building, shipping, leading, and living.

So if 42 is the answer to everything, here’s what I’ve learned so far 👇

🧍‍♂️ Life, growth & happiness

The definition of happiness changes with age. And that’s okay.
The more you learn, the more you realize how little you know.
Curiosity is infinite; boredom is optional.
You can’t optimize life like you optimize code.
If you chase success, it runs faster. If you enjoy the run, it slows down.
Peace beats growth. Every time.
Wealth is freedom, not Ferraris.
Desire is a contract to be unhappy until you get what you want. Cancel it often.
Run more. Read more. Scroll less.
Sleep is the most underrated productivity hack on Earth.

💼 Building, leading & learning

Startups are people, not ideas.
Leading by example is the hardest thing you’ll ever do.
Leadership is 80% conversations you didn’t want to have.
Hire slow. Fire fast. Then sleep well.
Focus is a superpower. Protect it like oxygen.
The first job of a leader is clarity. The second is repetition.
Nobody cares how much you know; they care how you make them feel.
Feedback given late is just resentment with a bow on it.
The most complex skill for a CEO to learn is knowing when to remain silent.
You can’t delegate judgment.

⚙️ Building products & companies

Quality compounds like interest. So does mediocrity. (Why we still care about quality.)
Success is rarely a pivot; it’s iteration with taste.
Great engineers fix root causes. Average ones fix symptoms.
The perfect product doesn’t exist: the one you can evolve does.
Simplicity scales. Complexity invoices.
Don’t chase vanity metrics: chase user trust.
Code reviews are easy. People reviews aren’t.
Build systems, not heroics.
The best feature is one you can delete later.
Tech debt is fine. Moral debt isn’t.

🧩 Mindset & philosophy

The only person you need to impress is your future self.
Gratitude is the antidote to burnout.
Meditation isn’t for everyone. Long runs count.
You can be kind and still have high standards.
It’s okay to be wrong, just not stubborn.
The right “no” beats a thousand “maybes.”
Compromise kills clarity. Choose, don’t blend.
Every problem looks smaller after a good meal.
Don’t overthink purpose. Build, love, repeat.
Curiosity never retires.

❤️ Family, friends & the long game

Family first. Always. The best way to disconnect is to be needed by your kids.
You can’t buy time, but you can decide how to spend it.

At 42, I’ve realized something simple but not easy:

Life isn’t a sprint to a finish line. It’s an ongoing debugging session. You fix a few things, break a few others, and hopefully push a slightly better version of yourself every year.

The same applies to building a company, raising children, or simply trying to be a decent person. You never “ship it” and move on. You iterate. You learn. You acknowledge that the next release will likely also contain bugs. And that’s fine.

For a long time, I thought success meant achieving things: a title, a product, a number in the bank, a milestone on a slide deck. But the more I live, the more I see that peace is the real metric. The ability to wake up excited, to solve interesting problems, to spend time with people you love, and to go to bed proud.

That’s it.

At 20, I wanted to build great code.

At 30, I wanted to build great products.

At 40, I just want to build a great life.

And the funny thing?

It still takes the same skills: focus, iteration, and knowing when to stop optimizing.

So if there’s one thing I’d tell my younger self, it’s this:

Keep learning, keep building, but remember that there’s no final commit.

You don’t get to “win” life. You just get to live it. Version by version.

Not Everything is a Hustle

Tue, 01 Jul 2025 00:00:00 GMT

This Sunday, I made the mistake of opening LinkedIn.

Among the usual weekend calm, a post caught my eye. A young founder proudly explaining how every morning before heading to the office, he cold-DMs 15 people. Every day. Rain or shine.

He then listed all the amazing outcomes of this habit: high-paid jobs, startup funding, conference invites, customer meetings, top hires, you name it.

I couldn’t help but roll my eyes.

So I reshared their post, wrote this instead, and published it on LinkedIn:

Every morning before I head to my home office,
I bring my kids to school.
It’s literally the single most important habit I’ve built.
Want to learn how I do it?
Comment “school” and I’ll tell you my secret.

Boom. Thousands of views.

Because here’s the truth: not everyone is under 30, lives in San Francisco, works at a startup with no users that raised millions, and spends their weekends writing cold emails to VCs and their evening eating pizzas with the team, crushing the latest release.

Some of us are in our 40s.

Some of us are building real companies.

Some of us are taking our kids to school, going for a run at lunch, playing music on the weekends, and still—yes, still—shipping, raising, hiring, and growing.

We don’t brag about skipping meals or sleeping 4 hours.

We don’t show our productivity hacks on a treadmill desk.

We don’t post about cold-DMing 15 people a day.

We just don’t need to turn every moment into content.

So if LinkedIn makes you feel like you’re not doing enough, or not doing it right, just know this:

You’re not alone. You’re not late.

And success can look very, very different.

Take a breath. Pick up your kids. Go for that run.

Enjoy the ride.

Why Stock Options are Terrible for Employees

Tue, 08 Oct 2024 00:00:00 GMT

Imagine you’re joining a startup, excited by the potential to share in its future success. You’ve just been offered stock options. What do they actually mean for you?

You’re not sure if you need to negotiate these terms, or even what they imply. Once you’re in, someone mentions them during a coffee break, and you’re confused all over again. Whatever—you decide to see how it plays out. Maybe you’ll get filthy rich without understanding why. Maybe you’ll get screwed over. Who knows?

As a tech employee, tech entrepreneur, and investor, I’ve had my share of discussions with fellows about stock options over the last decade.

Stock options are a great leverage for founders to share future value with their (early) employees. The intention behind it is noble, but using them has terrible drawbacks.

Understanding What You Get

When I joined Datadog a few years ago, they offered different packages that you had to choose from:

Option 1: a small salary, a large number of stock options;
Option 2: a medium salary, a medium number of stock options;
Option 3: a large salary and a small number of stock options.

I believe many tech companies use the same template.

A few months after I joined, the company IPO’ed. I went to a coffee break and chatted with one of my colleagues. The recent IPO and the rising stock values sparked the conversation. They asked me, “Which option did you pick when you joined?” I replied that I was looking for a venture back then, focusing on wealth creation, so I picked option 1—the salary was enough for me to live.

They replied that they now regretted picking option 3.

I suspect that most employees were more attracted to larger salaries than stock options. I wish somebody from HR could confirm the stats about what I observed, but I doubt they would. The truth is, even HR did not understand what they were doing.

When I got offered the 3 packages above, I asked what the value of the stock options was. Stock options are options (no shit), meaning they offer you the right to buy shares of a company. My natural question was: what was the price of this option, what was the company's value back then, and what was the total number of outstanding prices?

The recruiter’s answer was: 😳

Nonetheless, I insisted, and they escalated my question to an HR director. The director ended up reaching out to the US side of the company. They finally showed me a spreadsheet with the number I was asking, easing my final decision.

The lesson? Always ask for clarity on the value of your options before deciding. If even the recruiter is unsure, push until you understand what you’re getting.

Not Everyone is an Investor

If you ask people what investing is all about, they’ll reply with “finance and maths.” That’s true, but it’s only one part of the equation. Investing is also a very psychological discipline; not everyone’s ready for that.

When I was working at Red Hat, the company used to distribute RSU (Restricted Stock Units) to its employees. RSUs are basically free stocks. You’d get a bunch of those every year and could keep them, therefore becoming a shareholder, or sell them on the market and get cash in exchange.

As the company was on a growth trajectory back then, the stock would keep climbing every month or so.

Red Hat stock history before being bought by IBM in 2019.

Most people I worked with were young engineers and not investors. They had no clue why the stock would fluctuate.

One day, I was chatting with a colleague over a beer, and they seemed worried. I asked what was wrong, and they explained that they had lost thousands of dollars over the last month because Red Hat stocks had plunged. They had received RSUs over the last years and were so happy with their growth that they never sold them and didn’t think they could crash. Now, they were upset and did not know what to do.

Of course, they did not know what to do.

They had no way to know if the stock was overvalued or undervalued.

They had no idea if the market would continue its bull run or if a bear market was upcoming.

They were no investors. They had no plan, and the uncertainty left them feeling lost.

How to Approach Stock Options as an Employee

Owning stock options (or RSUs) means one thing: you are becoming an investor. It means that you now own (potentially, in the case of options) a part of a company with a market value and an intrinsic value. If you cannot assess the value or form an opinion on your company’s stock, you probably shouldn’t be a shareholder.

I know. It’s not your fault. You didn’t ask for it, but this is what happens if you stick to your stock. You are transformed.

As an employee, should you keep or sell your Airbnb Inc. stock? When do you sell? Why?

→ Once you vest your RSUs, if don’t sell them immediately in exchange for cash, you’re effectively becoming an investor.

→ When a liquidity event occurs, and you choose not to exercise your stock options, you are deciding to become an investor.

It’s great to be an investor, for sure. But that comes with many questions: what’s my allocation policy? What’s my exit strategy? What is my risk tolerance? What is my investment horizon? What are the tax implications? How well do I understand the business model? Do I trust the leadership team? What’s my plan if things go wrong? How does this investment fit into my overall financial plan?

Investing isn’t just about understanding finances; you also need to handle fear, greed, and uncertainty. Most people aren’t ready for the psychological strain of watching their savings plummet overnight.

CrowdStrike shares lost 50% of their value during the incident in 2024.

Stock options can be a powerful motivator, but they aren’t for everyone. Next time you’re offered stock options, think like an investor—ask the tough questions, seek clarity, and ensure you’re prepared for both the financial and emotional aspects of investing.

If you then plan to stick to your stock, decide whether you truly want to become an investor and learn the trade. If you don’t, it’s fine; just get your money and enjoy it. ✌️

How to Be a Great Software Engineer

Tue, 03 Sep 2024 00:00:00 GMT

I did not write for the last few weeks as I enjoyed taking a break. Ha! That’s probably the first point I could write about being a great software engineer: taking breaks.

Nevermind.

What do I know, after all? I’m not a software engineer anymore. I’m a CEO, god damn it.

Not my role model.

At least being a CEO gives me some excuse to dispense some pieces of advice regularly. It turns out that over the last couple of years, I had to become a manager of people — and many people in my team are software engineers. The only thing I knew about management so far was being managed, which taught me many things, such as:

how to manage;
how not to manage;
how to be managed.

I don’t want to talk about the first two points here, but I’d like to write about the latter. I regularly have to give feedback to people on my team, and they often rely on the Great Engineer Framework that I built in my mind.

It’s time to write that down.

Expectations

Since I started my career as a software engineer 20 years ago, I always wondered how to improve. My initial appeal for this career was typing code on a keyboard, so I decided that the best way to become a great engineer was to be the best at technical stuff.

I coded days and nights, learned everything I could, and became amazing. I Debian-packaged hundreds of software, wrote C code for a window manager, Linux and CPython, wrote CIEDE2000 color space computation functions in Lisp, wrote thousands of lines of Python to do crazy stuff, implemented XML binding for the X11 protocol, built a scalable time-series database based on object storage, etc; you name it. I did many tech-crazy things and thought I was a great engineer.

It turns out I was only 33% good. As I grew into the tech and startup ecosystem, I started to understand whatever was around me, the industry, the business, the people. And I soon realized that this was not enough, even if I was among the best engineers you could probably find (sorry for bragging).

Aspects

After a few years, I built a mental model that I still use nowadays to give feedback to engineers in my team, based on 3 aspects that you must master to become a great engineer — like the 10x engineer they all talk about:

Tech
Business value
Collaboration

Tech

I just discussed tech. You have to be amazing at it, which means you have to dig deep into it. As my co-founder Mehdi says, great engineers pull the strings. This means that you’re not just there to paper over the problem; you’re here to understand it fully, to grasp it entirely, from top to bottom, and to fix it forever because you understand it.

Many junior engineers are not able to do that. They just tinker with their code until “well, it works, tests pass, whatever.” The rise of AI tooling is supporting that, and engineers working this way will have to step up their game, or they’ll disappear.

It takes a large amount of time to achieve this expertise, and as common sense says, maybe 10,000 hours. This is actually a major issue for people switching to tech after another career; 10,000 hours of coding 25 hours a week (if you just do it on the job) in a typical 45-week year is more than 8 years before starting to “know what you’re talking about.” If you start at 18 years old, tinkering with computers 60 hours a week for fun, you’ll be pretty good at it by 21. I know that’s not fair, but I see this as a major roadblock for hiring tech talents coming from a career change.

So: do tech. Don’t stop until you understand everything of what you are responsible for. I remember 15 years ago being screened by a recruiter at Google who’d ask me what happened when I typed google.com in my Web browser. Being able to explain everything, from the keyboard input to the DNS requests and TCP headers of the packet sent, to the HTTP server made me pass without a blink.

Business Value

This sounds totally stupid, and I might be slightly biased by my French experience, but there are too many engineers who do not understand business value. It actually took me a few years to understand this, probably because I was only focused on tech. Let me give you a good anecdote to illustrate this.

Ten years ago, I was called by a senior manager to help with a Python project in a media company. I go to the meeting and meet the manager. He comes from a famous French tech school — one where they learn the C standard library from scratch in their first year — and so do most of the engineers in his team. They’re managing hundreds of servers, and after evaluating various software to do that (Puppet, Ansible, etc) they didn’t find anything that suited 100% of their needs, so they built their own. They invested hundreds of hours in it, and now they’d need help maintaining it.

It turns out that what they needed was probably Ansible plus a custom plugin to reach 98% of their need in a tenth of the time, but they didn’t see it that way. They just built an entire tech project, not related to their core business, from the ground up, investing hours of time. This is the kind of similar experience I talked about in my previous post, Solving Build vs Buy. I skipped that project and moved on to other things. I had no interest in maintaining a project that was not providing core value to the business. That’d have been a great way to be ditch as soon as somebody smarter in the company realized the amount of wasted time that project might have been.

This kind of behaviour applies everywhere. Engineers would spend hours trying to implement perfect systems that will scale to millions of users. While the business might have no user — yet. Engineers would spend hours building a feature or solving a problem that would impact 0.1% of users. It’s true that engineering might not be entirely responsible for the roadmap directly, but they are responsible for the time they spend on how far they go into implementing systems and features.

We live in a world where economy is the driver, which means you have to maximum throughput and minimize input. Input is your coding time, and throughput is the (extra) money the company that hires you can make with you work.

Collaboration

I could probably summarize this aspect with just:

If you want to go fast, go alone. If you want to go far, go together.

That’s entirely true. Considering the team is a problem for many engineers who are frustrated by members of their team. It does take time to deal with people, and they are not as easy to understand as computers. However, in the long run, they are the best way to provide you with leverage to achieve amazing things. Maybe another secret of 10x engineers, who knows?

Therefore, you’ll need to understand the dynamics that make your teamwork. You have to make sure your work is not isolated and is not the only correct piece of code hidden in its own corner. You need to connect both your piece of software and your brain to other pieces of software and people. I know it requires a lot of effort for some people, especially because it can feel annoying and inefficient to talk or write things for other engineers to understand what you’re achieving.

But until we can all Neuralink, yes, you’ll have to pause and do something that seems like a waste of time: talking to your teammates, your manager, or customers.

Always remember: this is an investment. In the long run, it will pay off.

Conclusion

Those three aspects are always the ones that I use to drive my feedback on performance reviews to engineers in the team. Not everyone is always 10/10 in every aspect, so it eases providing feedback and drives them to where they should improve next. They are probably not exhaustive, but they are a great way to spot great and inadequate behaviors.

Discovering the Tech Community in Toulouse: A Three-Year Journey

Tue, 25 Jun 2024 00:00:00 GMT

When I moved to Toulouse three years ago, I knew almost no one. My only connection was my cofounder, Mehdi. It was an intimidating start, but thanks to the magic of LinkedIn, my presence in the city didn't go unnoticed. Soon, people reached out to me, giving me my first glimpse into the tech scene here. Among those early connections were Denis and Cédric, whose introductions helped bootstrap my network at an impressive speed.

In case you have never heard of Toulouse, it’s the fourth largest city in France (soon to be third), with 0.5 million inhabitants, and the home of Airbus.

Mergify is a remote-first company, so we don’t have an office where I can commute every day and rely on colleagues to easily have a social network. That forced me to go out and expand my social network out in the unknown.

In 2022, I decided to reboot the Toulouse Python Meetup. Despite having over 800 members in the group at the time, the event had gone dormant since COVID 19. I reached out to the previous (idle) organizers, and with the support of Hugo at Mergify, we organized our first meetup. (I wrote more about attending conferences and how my approach changed over the years.) I prepared a quick return of experience talk, which I presented to the three attendees who showed up (!) how we deployed mypy at Mergify.

It was a humble beginning, but it was a start. Reviving in-person events was still challenging, but we persisted, organizing more meetups until the community began to grow. This effort eventually led us to Wannes, who now runs the events, allowing me to focus on other commitments. It’s tough to get people to attend events nowadays, possibly due to the lingering effects of COVID and the convenience of YouTube.

Joining the Tech.Rocks a couple of years ago was another significant milestone. Through this community, I discovered a substantial number of tech professionals in and around Toulouse. Remote work has made it possible for people to work far from their office, and I met people working at companies such as Datadog, Elastic, Spotify, OVHcloud, Ankorstore, AWS, Scaleway, MongoDB, ManoMano, Malt, Zenchef, GitLab — and there are many others I have yet to meet. I regularly organize lunches and dinners with tech folks from this community to foster stronger bonds, which has been incredibly rewarding.

I've had the pleasure of meeting remarkable people, from experienced engineers to startup founders. Toulouse boasts a vibrant ecosystem, smaller than Paris but thriving nonetheless. While it's easy to joke about the tech economy here being heavily dependent on Airbus and its providers, that's not entirely true. There's a diverse range of companies, though the prevalence of service companies (ESNs) in France is notable, with a scarcity of product-based firms.

One of the highlights of the tech calendar here is DevFest, an annual conference organized by the Google Developers Group (GDG). It's one of the most active meetups, although the connection to Google isn't always clear. Nonetheless, it's a fantastic event that brings the community together.

As a business angel, I've had the opportunity to meet incredible founders and teams from startups like Munity, Kotzilla, Roundtable, and more. It's inspiring to see startups in Toulouse that aren't solely focused on aerospace or IoT. There's a budding entrepreneurial spirit here that’s encouraging to witness.

Finally, I must mention IoT Valley — it took me three years to understand what was that IoT Valley I heard about all the time. Originally centered around SigFox, the community has evolved and now encompasses a broader range of startups. I recently had the chance to host a dinner and podcast episode there, giving me a deeper understanding of its scope. Located near Toulouse in Labège, IoT Valley houses numerous companies, many still focused on IoT, but expanding into other areas as well. They might benefit from a rebrand, but marketing isn't typically a strong suit in French tech. Sharing my experiences of building Mergify and working as an entrepreneur and business angel was a highlight, and I look forward to the podcast episode going live.

IoT Valley Founder Dinner

You can listen to the podcast I recorded here.

<iframe style="border-radius:12px" src="https://widget.ausha.co/index.html?podcastId=yX4JgC5WWna7&color=%23ffffff&v=3" width="100%" frameborder="0" scrolling="no"></iframe>

In conclusion, Toulouse's tech scene is dynamic and growing. For anyone considering a move to this city, you'll find a community that's welcoming, innovative, and full of opportunities. Whether you're looking to network, learn, or launch your next venture, Toulouse has something to offer.

And if you move there, send me a mail!

Attending Conferences

Tue, 04 Jun 2024 00:00:00 GMT

There’s a lot to say about tech conferences, shows, and exhibits in any form. I’ve been to a few of them over the last decade, and I probably can't count anymore at this point.

I thought it’d be interesting to write a thing or two about them and how my experience changed from my first participation in a gathering of tech people to the most recent one.

Goals

What especially changed for me over the last 15 years is the expectation of conferences.

I remember that the first conferences I went to appeared especially exciting because of the content. I was utterly interested in hearing about new technologies, discovering new features, and learning new practices. My goal as a young software engineer was to become the best at my craft, so I’d go there and attend as many lectures as I could.

Sometimes, that would be very challenging. Take the FOSDEM, one of the largest open-source conferences in Europe, with thousands of geeks attending. I attended FOSDEM numerous times. The buildings they use to run the conference have been the same all along those years, and are known to be way too small to welcome many people to most conferences. There are fantastic talks done by some of the world's greatest hackers, but there are more people waiting in the hall to access the talk than people in the room listening to it.

Regular FOSDEM attendance

You could think that this would ruin the conference for most people, but I think it does not. It shows the other very important aspect of conferences: social interaction.

I know there are so many stereotypes about tech guys not interacting with each other. The truth is, as human beings, we crave social connections, and events are a great source of those. Attending my first OpenStack Summit in 2013 allowed me to meet people I only chatted with over IRC, and it was a real game changer later on.

As my engineering career grew, there was not much interesting to learn from the talks. Many lectures became boring or déjà-vu.

I quickly switched sides and became the one giving talks and sharing knowledge. This was great. It gave me a great sense of recognition, validation, fear, and adrenaline. It’s a significant boost for anyone’s career. It was a game changer for me.

COVID

When COVID happened, everything changed.

I remember receiving a phone call in early March 2020 from Sylvain Zimmer, organizer of the dotConferences. I was booked to speak at dotPy, and my talk on Python performances and profiling was ready to go in a couple of days. I would be live on stage in a Parisian theater in front of hundreds of people. Sylvain explained that something was happening, that they couldn’t risk having this event run, and that they had to cancel.

For the next months, every event was canceled, and people shifted to online, remote work, etc. — you know it all. This broke local communities and the habit of many people going to conferences.

I think this shows overall as there are fewer people going to events today than there used to be. People got used to accessing content over the Internet, webinars bloomed, and since many conferences published their lectures online, interest in traveling to a conference reduced a lot.

I relaunched the Python Toulouse meetup group 18 months ago. There were more than 800 members on that group when we announced that we were scheduling a new session in October 2022—3 years after the last one.

We got only 5 attendees.

Since then, we have continued pushing the event every couple of months, and the event has grown back to more than 40 attendees (and I have stepped down from the organizers).

I think this shows well how bad the COVID hit conferences and meetups in general.

Attending Conferences

As I started running Mergify a few years ago, my expectations of conferences shifted again. As we are building a developer tool, so the developer is now a persona we want to reach to make us aware of what we’re building.

There are two ways of doing that, and most developer-focused companies do one or both:

speak at conferences;
expose at conferences (sponsoring).

I’ll write something about event sponsoring some other time. (Update: I did.)

Winning a slot to speak at conferences is not easy: it requires expertise (we have) and time and focus (we don’t have much). In my case, we encourage folks at Mergify to respond to calls for papers, teach other developers the problems we solve, or share our experience on various topics. This is not always working; unfortunately, we are not experts at playing the CfP game—another topic I should write about.

First, I noticed that while there are more and more software engineers, many of them don’t care about going to conferences. They know most of the talks are already online or will be. As the CfP game is getting professional, many talks you see at conferences have already been lectured, filmed, and published online. Engineers valuing their time might not go to conferences in the end.

Some conferences are trying to fix that by not publishing their talks online. I think it can be a good strategy in certain cases, but as many conferences invite speakers with talks running for months if not years, it’s likely you can already watch the content online anyway.

Second, many events and conferences still overpromise the number of people actually attending. It’s likely the pre-COVID level is not back everywhere.

Last, the average technical level of expertise of both speakers and attendees fluctuates a lot. However, the more I think about it, the less I see a pattern. Some community-run conferences have great and poor content simultaneously; some professional conferences have attendees with low-skill but great speakers. It’s hard to have a rule, and I think it’s really on a case-by-case basis—and it might be subjective, after all.

Those issues might be anecdotic for most, though they’re not for me as they explain partly why Mergify's sponsoring of events has been mostly a failure over the last year.

But I’ll talk about that later.

Interview: The Performance of Python

Mon, 11 May 2020 00:00:00 GMT

Earlier this year, I was supposed to participate to dotPy, a one-day Python conference happening in Paris. This event has unfortunately been cancelled due to the COVID-19 pandemic.

Both Victor Stinner and me were supposed to attend that event. Victor had prepared a presentation about Python performances, while I was planning on talking about profiling.

Rather than being completely discouraged, Victor and I sat down (remotely) with Anne Laure from Behind the Code (a blog ran by Welcome to the Jungle, the organizers of the dotPy conference).

We discuss Python performance, profiling, speed, projects, problems, analysis, optimization and the GIL.

You can read the interview here.

Being in Charge

Fri, 17 Apr 2020 00:00:00 GMT

If you never heard of the 10x engineer myth, it's a pretty great concept. It boils down to the idea where an engineer could be 10x more efficient than a random engineer. I find this fantastically twisted.

Last week, I sat and chat with Alexis Monville in Le Podcast — a podcast that equips you to make positive change in your organization. We talked about that 10x Engineer myth, and from there we digressed on how to grow your career and handle the different aspects of it.

This was a very interesting exchange. Alexis is actually going to publish a new book next month (May 2020) entitled I am a Software Engineer and I am in charge.

Lucky me, this week, I had the chance to be able to read the book before everybody else — which means I actually read after our recording. I understood why Alexis said that a lot of what I was talking about during our podcast resonated with him. I send a detailed review of the book to Alexis and Michael if you're curious. I'm definitely recommending this book if you want to stop complaining about your job and start understanding how to pull the strings.

I wish I had this book available 10 years ago! 😅

My interview with Cool Python Codes

Thu, 05 Oct 2017 00:00:00 GMT

A few days ago, I've recently been contacted by Godson Rapture from Cool Python codes to answer a few questions about what I work on in open source. Godson regularly interview developers and I invite you to check out his website!

Here's a copy of my original interview. Enjoy!

Good day, Julien Danjou, welcome to Cool Python Codes. Thanks for taking your precious time to be here.

You’re welcome!

Could you kindly tell us about yourself like your full name, hobbies, nationality, education, and experience in programming?

Sure. I’m Julien Danjou, I’m French and live in Paris, France. I studied Computer science for 5 years around 15 years ago, and continued my career in that field since then, specializing in open source projects.

Those last years, I’ve been working as a software engineer at Red Hat. I’ve spent the last 10 years working with the Python programming language. Now I work on the Gnocchi project which is a time series database.

When I’m not coding, I enjoy running half-marathon and playing FPS games.

Can you narrate your first programming experience and what got you to start learning to program?

I started programming around 2001, and my first serious programs were in Perl. I was contributing to a hosting platform for free software named VHFFS. It was a free software project itself, and I enjoyed being able to learn from other more experienced developers and being able to contribute back to it. That’s what got me stuck into that world of open source projects.

Which programming language do you know and which is your favorite?

I know quite a few, I’ve been doing serious programming in Perl, C, Lua, Common Lisp, Emacs Lisp and Python.

Obviously, my favorite is Common Lisp, but I was never able to use it for any serious project, for various reasons. So I spend most of my time hacking with Python, which I really enjoy as it is close to Lisp, in some ways. I see it as a small subset of Lisp.

What inspired you to venture into the world of programming and drove you to learn a handful of programming languages?

It was mostly scratching my own itches when I started. Each time I saw something I wanted to do or a feature I wanted in an existing software, I learned what I needed to get going and get it working.

I studied C and Lua while writing awesome- the window manager that I created 10 years ago and used for a while. I learned Emacs Lisp while writing extensions that I wanted to see in Emacs, etc. It’s the best way to start.

What is your blog about?

My blog is a platform where I write about what I work on most of the time. Nowadays, it’s mostly about Python and the main project I contribute to,
Gnocchi.

When writing about Gnocchi, I usually try to explain what part of the project I worked on, what new features we achieved, etc.

On Python, I try to share solutions to common problems I encountered or identified while doing e.g. code reviews. Or presenting a new library I created!

Tell us more about your book, The Hacker’s Guide to Python.

It’s a compilation of everything I learned those last years building large Python applications. I spent the last 6 years developing on a large code base with thousands of other developers.

I’ve reviewed tons of code and identified the biggest issues, mistakes, and bad practice that developers tend to have. I decided to compile that in a guide, helping developers that played a bit with Python to learn the stages to get really productive with Python.

OpenStack is the biggest open source project in Python, Can you tell us more about OpenStack?

OpenStack is a cloud computing platform, started 7 years ago now. Its goal is to provide a programmatic platform to manage your infrastructure while being open source and avoiding vendor lock-in.

Who uses OpenStack? Is it for programmers, website owners?

It’s used by a lot of different organizations – not really by individuals. It’s a big piece of software. You can find it in some famous public cloud providers (Dreamhost, Rackspace…), and also as a private cloud in a lot of different organizations, from Bloomberg to eBay or the CERN in Switzerland, a big OpenStack user. Tons of telecom providers also leverages OpenStack for their own internal infrastructure.

Have you participated in any OpenStack conference? What did you speak on if
you did?

I’ve attended the last 9 OpenStack summits and a few other OpenStack events around the world. I’ve been engaged in the upstream community for the last 6 years now.

My area of expertise is telemetry, the stack of software that is in charge of collecting and storing metrics from the various OpenStack components. This is what I regularly talk about during those events.

How can one join the OpenStack community?

There’s an entire documentation about that, called the Developer’s Guide. It explains how to setup your environment to send patches, how to join the community using the mailing-lists or IRC.

What makes your book, The Hacker’s Guide to Python stand out from other Python books? Also, who exactly did you write this book for?

I wrote the book that I always wanted to read about Python, but never found. It’s not a book for people that want to learn Python from scratch. It’s a great guide for those who know the language but don’t know the details that experienced developers know and that make the difference. The best practice, the elegant solutions to common problems, etc. That’s why it also includes interviews with prominent Python developers, so they can share their advice on different areas.

How can someone get your book?

I’ve decided to self-publish my book, so he does not have an editor like you can be used to see. The best place to get it is online at where you can pick the format you want, electronic or paper.

What do you mean when you say you hack with Python?

Unfortunately, most people refer to hacking as the activity of some bad guys trying to get access to whatever they’re not supposed to see. In the book title, I mean “hacking” as the elegant way of writing code and making things worse smoothly even when you were not expecting to make it.

You mentioned earlier that Gnocchi is a time series database. Can you please be more elaborate about Gnocchi? Is there also any documentation about Gnocchi?

So Gnocchi is a project I started a few years ago to store time series at large scale. Timeseries are basically a series of tuple composed of a timestamp and a value.

Imagine you wanted to store the temperature of all the rooms of the world at any point of time. You’d need a dedicated database for that with the right data structure. This is what Gnocchi does: it provides this data structure storage at very, very large scale.

The primary use case is infrastructure monitoring, so most people use it to store tons of metrics about their hardware, software, etc. It’s fully documented on its website.

How can a programmer without much experience contribute to open source projects?

The best way to start is to try to fix something that irritates you in some way. It might be a bug, it might be a missing feature. Start small. Don’t try big things first or you could be discouraged.

Never stop.

Also, don’t plunge right away in the community and start poking random people or spam them with questions. Do your homework, and listen to the community for a while to get a sense of how things are going. That can be joining IRC and lurking or following the mailing lists for example.

Big open source communities dedicate programs to help you become engaged. It might be worth a try. Generic programs like Outreachy or Google Summer of Code are a great way to start if you don’t feel confident enough to jump by your own means in a community.

Just out of curiosity, do you write code in French?

Never ever. I think it’s acceptable to write in your language if you are sure that your code will never be open sourced and that your whole team is talking in that language, no matter what – but it’s a ballsy assumption, clearly.

Truth is that if you do open source, English is the standard, so go with it. Be sad if you want, but please be pragmatic.

I’ve seen projects being open sourced by companies where all the code source comments were in Korean. It was impossible for any non-Korean people to get a glance of what the code and the project was doing, so it just failed and disappeared.

How does a team of programmers handle bugs in a large open source project?

I wish there was some magic recipe, but I don’t think it’s the case. What you want is to have a place where your users can feel safe reporting bugs. Include a template so they don’t forget any details: how to reproduce the bugs, what they expected, etc. The worst thing is to have users reporting “That does not work.” with no details. It’s a waste of time.

What tool to use to log all of that really depends on the team size and culture.

Once that works, the actual fixing of bug doesn’t follow any rule. Most developers fix the bug they encounter or the ones that are the most critical for users. Smaller problems might not be fixed for a long time.

Can you tell us about the new book you are working on and when do we expect
to get it?

That new book is entitled “Scaling Python” and it provides insight into how to build largely scalable and distributed applications using Python.

It is also based on my experience in building this kind of software during the past years. This book also includes interviews of great Python hackers who work on scalable system or know a thing or two about writing applications for performance – an important point to have scalable applications.

The book is in its final stage now, and it should be out at the beginning of 2018.

How can someone get in contact with you?

I’m reachable at julien@danjou.info by email or via Twitter, @juldanjou.

Running an open source and upstream oriented team in agile mode

Tue, 18 Oct 2016 00:00:00 GMT

For the last 3 years, I've been working in the OpenStack Telemetry team at eNovance, and then at Red Hat. Our mission is to maintain the OpenStack Telemetry stack, both upstream and downstream (i.e. inside Red Hat products). Besides the technical challenges, the organization of the team always have played a major role in our accomplishments.

Here, I'd like to share some of my hindsight with you, faithful readers.

Meet the team

The team I work in changed a bit during those 3 years, but the core components always have been the same: a few software engineers, a QE engineer, a product owner, and an engineering manager. That meant the team size has been always been between 6 and 8 people.

I cannot emphasize enough how team size is important. Not having more than 8 persons in a team fits with the two pizzas rule from Jeff Bezzos, which turned out to be key in our team composition.

The group dynamic that is applied by teams not bigger than this is excellent. It offers the possibility to know and connect with everyone – each time member has only up to 7 people to talk to on a daily basis, which means only 28 communication axis between people. Having a team of e.g. 16 people means 120 different links in your team. Double your team size, and multiply by 4 your communication overhead. My experience shows that the less communication axis you have in a team, the less overhead your will have and the swifter your team will be.

All team members being remote workers, is is even more challenging to build relationship and bound. We had the opportunity to know each other during the OpenStack summit twice a year and doing regular video-conference via Google Hangout or BlueJeans really helped.

The atmosphere you set-up in your team will also forge the outcome of your team work. Run your team with trust, peace and humor (remember I'm on the team 🤣) and awesome things will happen. Run your team with fear, pressure, and finger-pointing, nothing good will happen.

There's little chance that when a team is built, everyone will be on the same level. We were no exception, we had more and less experienced engineers. But the most experienced engineers took the time needed to invest and mentor the less experienced. That also helped to build trust and communication links between members of the team. And over the long run, everyone is getting more efficient: the less experienced engineers are getting better and the more experienced can delegate a lot of stuff to their fellows.

Then they can chill or work on bigger stuff. Win-win.

It's actually no more different than that the way you should run an open source team, as I already claimed in a previous article on FOSS projects management.

Practicing agility

I might be bad at practicing agility: contrary to many people, I don't see agility as a set of processes. I see that as a state of mind, as a team organization based on empowerment. No more, no less.

And each time I meet people and explain that our team is "agile", they start shivering, explaining how they hate sprints, daily stand-ups, scrum, and planning poker, that this is all a waste of time and energy.

Well, it turns out that you can be agile without all of that.

Planning poker

In our team, we tried at first to run 2-weeks sprints and used planning poker to schedule our user stories from our product backlog (= todo list). It never worked as expected.

First, most people had the feeling to lose their time because they already knew exactly what they were supposed to do. Having any doubt, they would have just gone and talked to the product owner or another fellow engineer.

Secondly, some stories were really specialized and only one of the team member was able to understand it in details and evaluate it. So most of the time, a lot of the team members playing planning poker would just vote a random number based on the length of the explanation of the story teller. For example, if an engineer said "I just need to change that flag in the configuration file" then everyone would vote 1. If they started rambling for 5 minutes about "how the configuration option is easy to switch, but that there might be other things to change at the same time, and things to check for impact bigger than expected, and code refactoring to do", then most people would just announce a score of 13 on that story. Just because the guy talked for 3 minutes straight and everything sounded complicated and out of their scope.

That meant that the poker score had no meaning to us. We never managed to have a number of points that we knew we could accomplish during a sprint (the team velocity as they call it).

The only benefit that we identified from planning poker, in our case, is that it forces people to keep sit down and communicate about a user story. Though, it turned out that making people communicate was not a problem we needed to solve in our team, so we decided to stop doing that. But it can be a pretty good tool to make people talking to each other.

Therefore, the 2-weeks sprint never made much sense as we were unable to schedule our work reliably. Furthermore, doing most of our daily job in open source communities, we were unable to schedule anything. When sending patches to an upstream project, you have no clue when they will be reviewed. What you know for sure, is that in order to maximize your code merge throughput with this high latency of code review, you need to parallelize your patch submission a lot. So as soon as you receive some feedback from your reviewers, you need to (almost) drop everything, rework your code and resubmit it.

There's no need to explain what this does not absolutely work with a sprint approach. Most of the scrum framework lays on the fact that you own workflow from top to bottom, which is far from being true when working in open source communities.

Daily stand-up meetings

We used to run a daily stand-up meeting every day, then every other day. Doing that remotely kills the stand-up part, obviously, so there is less guarantee the meeting will be short. Considering all team members are working remotely in different time zones, with some freedom to organize their schedule, it was very difficult to synchronize those meetings. With member spread from the US to Eastern Europe, the meeting was in the middle of the afternoon for me. I found it frustrating to have to stop my activities in the middle of every afternoon to chat with my team. We all know the cost of context switching to us, humans.

So we drifted from our 10 minutes daily meeting to a one-hour weekly meeting with the whole team. It's way easier to synchronize for a large chunk of time once a week and to have this high-throughput communication channel.

Our (own) agile framework

Drifting from the original scrum implementation, we ended up running our own agility framework. It turned out to have similarity with kanban – you don't always have to invent new things!

Our main support is a Trello board that we share with the whole team. It consists of different columns, where we put card representing small user stories or simple to-do items. Each column is the state of the current card, and we move them left to right:

Ideas: where we put things we'd like to do or dig into, but there's no urgency. It might lead to new, smaller ideas, in the "To Do" column.
To Do: where we put real things we need to do. We might run a grooming session with our product manager if we need help prioritizing things, but it's usually not necessary.
Epic: here we create a few bigger cards that regroup several To Do items. We don't move them around, we just archive them when they are fully implemented. There are only 5-6 big cards here at max, which are the long term goals we work on.
Doing: where we move cards from To Do when we start doing them. At this stage, we also add people working on the task to the card, so we see a little face of people involved.
Under review: 90% of our job being done upstream, we usually move cards done and waiting for feedback from the community to this column. When the patches are approved and the card is complete, we move the card to Done. If a patch needs further improvement, we move back the card to Doing and work on it, and then move it back to Under review when resubmitted.
On hold / blocked: some of the tasks we work on might be blocked by external factors. We move cards there to keep track of them.
Done during week #XX: we create a new list every Monday to stack our done cards by week. This is just easier to display and it allows us to see the cards that we complete each week. We archive lists older than a month, from time to time. It gives a great visual feedback and what has been accomplished and merged every week.

We started to automate some of our Trello workflow in a tool called Trelloha. For example, it allows us to track upstream patches sent through Gerrit or GitHub and tick the checkbox items in any card when those are merged.

We actually don't put many efforts on our Trello board. It's just a slightly organized chaos, as are upstream projects. We use it as a lightweight system for taking notes, organizing our thought and letting know what we're doing and why we're doing it. That's where Trello is wonderful because using it has a very low friction: creating, updating and moving card is a one click operation.

One bias of most engineers is to overthink and over-engineer their workflow, trying to rationalize it. Most of the time, they end up automating which means building processes and bureaucracy. It just slows things down and builds frustration upon everyone. Just embrace chaos and spend time on what matters.

Most of the things we do are linked to external Launchpad bugs, Gerrit reviews or GitHub issues. That means the cards in Trello carry very little information, as everything happens outside, in the wild Internet of open source communities.

This is very important as we need to avoid any kind of retention of knowledge and information from contributors outside the company. This also makes sure that our internal way of running does not leak outside and (badly) influence outside communities.

Retrospectives

We also run a retrospective every 2 weeks, which might be the only thing we kept from the scrum practice. It's actually a good opportunity for us to share our feelings, concerns or jokes. We used to do it using the six thinking hats method, but it slowly faded away. In the end, we now use a different Trello board with those columns:

Good 😄
Hopes and Wishes 🎁
Puzzles and Challenges 🌊
To improve 😡
Action Items 🤘

All teammates fill the board with the card they want, and everyone is free to add themselves to any card. We then run through each card and let people who added their name to it talk about it. The column "Action Items" is usually filled as we speak and discover we should do things. We can then move cards created there to our regular board, in the To Do column.

Central communication

Sure, people have different roles in a team, but we dislike bottleneck and single point of failure. Therefore, we are using an internal mailing list where we ask people to send their request and messages to. If people send things related to our team job to one of us personally, we just forward or Cc the list when replying so everyone is aware of what one might be talking about with people external to the team.

This is very important, as it emphasizes that no team member should be considered special. Nobody owns more information and knowledge than others, and anybody can jump into a conversation if it has valuable knowledge to share.

The same applies for our internal IRC channel.

We also make sure that we discuss only company-specific things on this list or on our internal IRC channel. Everything that can be public and is related to upstream is discussed on external communication medium (IRC, upstream mailing list, etc). This is very important to make sure that we are not blocking anybody outside the Red Hat to join us and contribute to the projects or ideas we work on. We also want to make sure that people working in our company are no more special than other contributors.

Improvement

We're pretty happy with our set-up right now, and the team runs pretty smoothly since a few months. We're still trying to improve, and having a general sense of trust among team members make sure we can openly speak about whatever problem we might have.

Feel free to share your feedback and own experience of running your own teams in the comment section.

My interview in le Journal du Hacker

Thu, 17 Sep 2015 00:00:00 GMT

A few days ago, the French equivalent of Hacker News, called "Le Journal du Hacker", interviewed me about my work on OpenStack, my job at Red Hat and my self-published book The Hacker's Guide to Python. I've spent some time translating it into English so you can read it if you don't understand French! I hope you'll enjoy it.

Hi Julien, and thanks for participating in this interview for the Journal du Hacker. For our readers who don't know you, can you introduce you briefly?

You're welcome! My name is Julien, I'm 31 years old, and I live in Paris. I now have been developing free software for around fifteen years. I had the pleasure to work (among other things) on Debian, Emacs and awesome these last years, and more recently on OpenStack. Since a few months now, I work at Red Hat, as a Principal Software Engineer on OpenStack. I am in charge of doing upstream development for that cloud-computing platform, mainly around the Ceilometer, Aodh and Gnocchi projects.

Being myself a system architect, I follow your work in OpenStack since a while. It's uncommon to have the point of view of someone as implied as you are. Can you give us a summary of the state of the project, and then detail your activities in this project?

The OpenStack project has grown and changed a lot since I started 4 years ago. It started as a few projects providing the basics, like Nova (compute), Swift (object storage), Cinder (volume), Keystone (identity) or even Neutron (network) who are basis for a cloud-computing platform, and finally became composed of a lot more projects.

For a while, the inclusion of projects was the subject of a strict review from the technical committee. But since a few months, the rules have been relaxed, and we see a lot more projects connected to cloud-computing joining us.

As far as I'm concerned, I've started with a few others people the Ceilometer project in 2012, devoted to handling metrics of OpenStack platforms. Our goal is to be able to collect all the metrics and record them to analyze them later. We also have a module providing the ability to trigger actions on threshold crossing (alarm).

The project grew in a monolithic way, and in a linear way for the number of contributors, during the first two years. I was the PTL (Project Technical Leader) for a year. This leader position asks for a lot of time for bureaucratic things and people management, so I decided to leave my spot in order to be able to spend more time solving the technical challenges that Ceilometer offered.

I've started the Gnocchi project in 2014. The first stable version (1.0.0) was released a few months ago. It's a timeseries database offering a REST API and a strong ability to scale. It was a necessary development to solve the problems tied to the large amount of metrics created by a cloud-computing platform, where tens of thousands of virtual machines have to be metered as often as possible. This project works as a standalone deployment or with the rest of OpenStack.

More recently, I've started Aodh, the result of moving out the code and features of Ceilometer related to threshold action triggering (alarming). That's the logical suite to what we started with Gnocchi. It means Ceilometer is to be split into independent modules that can work together – with or without OpenStack. It seems to me that the features provided by Ceilometer, Aodh and Gnocchi can also be interesting for operators running more classical infrastructures. That's why I've pushed the projects into that direction, and also to have a more service-oriented architecture (SOA).

I'd like to stop for a moment on Ceilometer. I think that this solution was very expected, especially by the cloud-computing providers using OpenStack for billing resources sold to their customers. I remember reading a blog post where you were talking about the high-speed construction of this brick, and features that were not supposed to be there. Nowadays, with Gnocchi and Aodh, what is the quality of the brick Ceilometer and the programs it relies on?

Indeed, one of the first use-case for Ceilometer was tied to the ability to get metrics to feed a billing tool. That's now a reached goal since we have billing tools for OpenStack using Ceilometer, such as CloudKitty.

However, other use-cases appeared rapidly, such as the ability to trigger alarms. This feature was necessary, for example, to implement the auto scaling feature that Heat needed. At the time, for technical and political reasons, it was not possible to implement this feature in a new project, and the functionality ended up in Ceilometer, since it was using the metrics collected and stored by Ceilometer itself.

Though, like I said, this feature is now in its own project, Aodh. The alarm feature is used since a few cycles in production, and the Aodh project brings new features on the table. It allows to trigger threshold actions and is one of the few solutions able to work at high scale with several thousands of alarms.
It's impossible to make Nagios run with millions of instances to fetch metrics and triggers alarms. Ceilometer and Aodh can do that easily on a few tens of nodes automatically.

On the other side, Ceilometer has been for a long time painted as slow and complicated to use, because its metrics storage system was by default using MongoDB. Clearly, the data structure model picked was not optimal for what the users were doing with the data.

That's why I started Gnocchi last year, which is perfectly designed for this use case. It allows linear access time to metrics (O(1) complexity) and fast access time to the resources data via an index.

Today, with 3 projects having their own perimeter of features defined – and which can work together – Ceilometer, Aodh and Gnocchi finally erased the biggest problems and defects of the initial project.

To end with OpenStack, one last question. You're a Python developer for a long time and a fervent user of software testing and test-driven development. Several of your blogs posts point how important their usage are. Can you tell us more about the usage of tests in OpenStack, and the test prerequisites to contribute to OpenStack?

I don't know any project that is as tested on every layer as OpenStack is. At the start of the project, there was a vague test coverage, made of a few unit tests. For each release, a bunch of new features were provided, and you had to keep your fingers crossed to have them working. That's already almost unacceptable. But the big issue was that there was also a lot of regressions, et things that were working were not anymore. It was often corner cases that developers forgot about that stopped working.

Then the project decided to change its policy and started to refuse all patches – new features or bug fix – that would not implement a minimal set of unit tests, proving the patch would work. Quickly, regressions were history, and the number of bugs largely reduced months after months.

Then came the functional tests, with the Tempest project, which runs a test battery on a complete OpenStack deployment.

OpenStack now possesses a complete test infrastructure, with operators hired full-time to maintain them. The developers have to write the test, and the operators maintain an architecture based on Gerrit, Zuul, and Jenkins, which runs the test battery of each project for each patch sent.

Indeed, for each version of a patch sent, a full OpenStack is deployed into a virtual machine, and a battery of thousands of unit and functional tests is run to check that no regressions are possible.

To contribute to OpenStack, you need to know how to write a unit test – the policy on functional tests is laxer. The tools used are standard Python tools, unittest for the framework and tox to run a virtual environment (venv) and run them.

It's also possible to use DevStack to deploy an OpenStack platform on a virtual machine and run functional tests. However, since the project infrastructure also do that when a patch is submitted, it's not mandatory to do that yourself locally.

The tools and tests you write for OpenStack are written in Python, a language which is very popular today. You seem to like it more than you have to, since you wrote a book about it, The Hacker's Guide to Python, that I really enjoyed. Can you explain what brought you to Python, the main strong points you attribute to this language (quickly) and how you went from developer to author?

I stumbled upon Python by chance, around 2005. I don't remember how I hear about it, but I bought a first book to discover it and started toying with that language. At that time, I didn't find any project to contribute to or to start. My first project with Python was rebuildd for Debian in 2007, a bit later.

I like Python for its simplicity, its object orientation rather clean, its easiness to be deployed and its rich open source ecosystem. Once you get the basics, it's very easy to evolve and to use it for anything, because the ecosystem makes it easy to find libraries to solve any kind of problem.

I became an author by chance, writing blog posts from time to time about Python. I finally realized that after a few years studying Python internals (CPython), I learned a lot of things. While writing a post about
the differences between method types in Python – which is still one of the most read post on my blog – I realized that a lot of things that seemed obvious to me where not for other developers.

I wrote that initial post after thousands of hours spent doing code reviews on OpenStack. I, therefore, decided to note all the developers pain points and to write a book about that. A compilation of what years of experience taught me and taught to the other developers I decided to interview in the book.

I've been very interested by the publication of your book, for the subject itself, but also the process you chose. You self-published the book, which seems very relevant nowadays. Is that a choice from the start? Did you look for an editor? Can you tell use more about that?

I've been lucky to find out about others self-published authors, such as Nathan Barry – who even wrote a book on that subject, called Authority. That's what convinced me it was possible and gave me hints for that project.

I've started to write in August 2013, and I ran the firs interviews with other developers at that time. I started to write the table of contents and then filled the pages with what I knew and what I wanted to share. I manage to finish the book around January 2014. The proof-reading took more time than I expected, so the book was only released in March 2014. I wrote a complete report about that on my blog, where I explain the full process in detail, from writing to launching.

I did not look for editors though I've been proposed some. The idea of self-publishing really convince me, so I decided to go on my own, and I have no regret. It's true that you have to wear two hats at the same time and handle a lot more things, but with a minimal audience and some help from the Internet, anything's possible!

I've been reached by two editors since then, a Chinese and Korean one. I gave them rights to translate and publish the books in their countries, so you can buy the Chinese and Korean version of the first edition of the book out there.

Seeing how successful it was, I decided to launch a second edition in May 2015, and it's likely that a third edition will be released in 2016.

Nowadays, you work for Red Hat, a company that represents the success of using Free Software as a commercial business model. This company fascinates a lot in our community. What can you say about your employer from your point of view?

It only has been a year since I joined Red Hat (when they bought eNovance), so my experience is quite recent.

Though, Red Hat is really a special company on every level. It's hard to see from the outside how open it is, and how it works. It's really close to and it really looks like an open source project. For more details, you should read The Open Organization, a book wrote by Jim Whitehurst (CEO of Red Hat), which he just published. It describes perfectly how Red Hat works. To summarize, meritocracy and the lack of organization in silos is what makes Red Hat a strong organization and puts them as
one of the most innovative company.

In the end, I'm lucky enough to be autonomous for the project I work on with my team around OpenStack, and I can spend 100% working upstream and enhance the Python ecosystem.

My interview about software tests and Python

Mon, 11 May 2015 00:00:00 GMT

I've recently been contacted by Johannes Hubertz, who is writing a new book about Python in German called "Softwaretests mit Python" which will be published by Open Source Press, Munich this summer. His book will feature some interviews, and he was kind enough to let me write a bit about software testing. This is the interview that I gave for his book. Johannes translated to German and it will be included in Johannes' book, and I decided to publish it on my blog today. Following is the original version.

How did you come to Python?

I don't recall exactly, but around ten years ago, I saw more and more people using it and decided to take a look. Back then, I was more used to Perl. I didn't really like Perl and was not getting a good grip on its object system.

As soon as I found an idea to work on – if I remember correctly that was rebuildd – I started to code in Python, learning the language at the same time.

I liked how Python worked, and how fast I was to able to develop and learn it, so I decided to keep using it for my next projects. I ended up diving into Python core for some reasons, even doing things like briefly hacking on projects like Cython at some point, and finally ended up working on OpenStack.

OpenStack is a cloud computing platform entirely written in Python. So I've been writing Python every day since working on it.

That's what pushed me to write The Hacker's Guide to Python in 2013 and then self-publish it a year later in 2014, a book where I talk about doing smart and efficient Python.

It had a great success, has even been translated in Chinese and Korean, so I'm currently working on a second edition of the book. It has been an amazing adventure!

Zen of Python: Which line is the most important for you and why?

I like the "There should be one – and preferably only one – obvious way to do it". The opposite is probably something that scared me in languages like Perl. But having one obvious way to do it is and something I tend to like in functional languages like Lisp, which are in my humble opinion, even better at that.

For a python newbie, what are the most difficult subjects in Python?

I haven't been a newbie since a while, so it's hard for me to say. I don't think the language is hard to learn. There are some subtlety in the language itself when you deeply dive into the internals, but for beginners most of the concept are pretty straight-forward. If I had to pick, in the language basics, the most difficult thing would be around the generator objects (yield).

Nowadays I think the most difficult subject for new comers is what version of Python to use, which libraries to rely on, and how to package and distribute projects. Though things get better, fortunately.

When did you start using Test Driven Development and why?

I learned unit testing and TDD at school where teachers forced me to learn Java, and I hated it. The frameworks looked complicated, and I had the impression I was losing my time. Which I actually was, since I was writing disposable programs – that's the only thing you do at school.

Years later, when I started to write real and bigger programs (e.g. rebuildd), I quickly ended up fixing bugs… I already fixed. That recalled me about unit tests and that it may be a good idea to start using them to stop fixing the same things over and over again.

For a few years, I wrote less Python and more C code and Lua (for the awesome window manager), and I didn't use any testing. I probably lost hundreds of hours testing manually and fixing regressions – that was a good lesson. Though I had good excuses at that time – it is/was way harder to do testing in C/Lua than in Python.

Since that period, I have never stopped writing "tests". When I started to hack on OpenStack, the project was adopting a "no test? no merge!" policy due to the high number of regressions it had during the first releases.

I honestly don't think I could work on any project that does not have – at least a minimal – test coverage. It's impossible to hack efficiently on a code base that you're not able to test in just a simple command. It's also a real problem for new comers in the open source world. When there are no test, you can hack something and send a patch, and get a "you broke this" in response.

Nowadays, this kind of response sounds unacceptable to me: if there is no test, then I didn't break anything!

In the end, it's just too much frustration to work on non tested projects as I demonstrated in my study of whisper source code.

What do you think to be the most often seen pitfalls of TDD and how to avoid them best?

The biggest problems are when and at what rate writing tests.

On one hand, some people starts to write too precise tests way too soon. Doing that slows you down, especially when you are prototyping some idea or concept you just had. That does not mean that you should not do test at all, but you should probably start with a light coverage, until you are pretty sure that you're not going to rip every thing and start over. On the other hand, some people postpone writing tests for ever, and end up with no test all or a too thin layer of test. Which makes the project with a pretty low coverage.

Basically, your test coverage should reflect the state of your project. If it's just starting, you should build a thin layer of test so you can hack it on it easily and remodel it if needed. The more your project grow, the more you should make it sold and lay more tests.

Having too detailed tests is painful to make the project evolve at the start. Having not enough in a big project makes it painful to maintain it.

Do you think, TDD fits and scales well for the big projects like OpenStack?

Not only I think it fits and scales well, but I also think it's just impossible to not use TDD in such big projects.

When unit and functional tests coverage was weak in OpenStack – at its beginning – it was just impossible to fix a bug or write a new feature without breaking a lot of things without even noticing. We would release version N, and a ton of old bugs present in N-2 – but fixed in N-1 – were reopened.

For big projects, with a lot of different use cases, configuration options, etc, you need belt and braces. You cannot throw code in a repository thinking it's going to work ever, and you can't afford to test everything manually at each commit. That's just insane.

Making the jump: working freelance

Mon, 02 Jul 2012 00:00:00 GMT

For the last 10 years, I've been working on many Free Software projects. From Debian to OpenStack, through awesome, Emacs, XCB and many more. This obviously allowed me to enhance my technical skills, but it also taught me about Free Software and Open Source development processes, and how to work with and close to the community.

Working for almost 6 years at Easter-eggs taught me how to work in an autonomous manner, how to lead and manage a project. And how to run a company, thanks to the cooperative status of this great one.

These are the reasons why I decided to leave my latest job and run my own company to work as a freelance consultant & developer specialized in Free Software, starting today.

Therefore, I am now able and available to provide expertise and development on Free Software, including upstream contribution. Especially on projects I already worked on recently, like OpenStack.

New job, new blog

Wed, 07 Dec 2011 00:00:00 GMT

It has been a while since I blogged but I've been very busy, with my new job and this new blog!

New job!

I quitted my job last September, and found another one that I started in October. I'm now the lead developer of eNovance Labs, where I work on the OpenStack project. So far, this allowed me to contribute heavily to the Debian packaging of OpenStack.

New blog!

In the meantime, I took some time to redesign my personal homepage and this blog, which is now using Hyde, the Python equivalent of Jekyll, which is in Ruby. Since I dislike Ruby (sorry), I preferred to use a Python based generator, and I admit Hyde is really cool.
Since I really suck at Web design, this one is obviously based on Twitter's bootstrap

Quitting my job

Mon, 29 Aug 2011 00:00:00 GMT

After more than 5 years at Easter-eggs as a system engineer, I'll be leaving my job soon.

It has been a fabulous adventure, also due to the "cooperative" nature of the company. I've enjoyed worked here, with great people. I do wish them luck for the future. Looking at the numerous things I did for the past years, it has been quite productive!

Therefore, I'll be looking for a new job in the next weeks, which will probably keep me busy a bit. :-)

TODO list management

Fri, 10 Jul 2009 00:00:00 GMT

My fellow Debian developer Steve Kemp told us about his TODO list management.

While reading his post, I was constantly thinking "been there, been there buddy". Yeah, I've been.

I had the same problem since months, impossibility to track the things I had to do, being computer related stuff or real life ones. The bad thing is that until you write them down, you keep them in mind, and that's exhausting. You know you have, let's say 5, things to do, but unless you write this 5 items down in a TODO list, you will keep thinking about it once in a while. And that's a real lost time.

And that's totally inefficient: imagine you though "it'd be nice if I could buy a USB stick next time I buy some hardware". Well, unless you actually write this somewhere and have the habit to check the "To Buy" category of your TODO list, you're going to buy a replacement hard drive in a hurry some day, and forget about your USB stick.

I think the good practice, which I really recommend to everyone, is to write down as soon as possible what you think you have to do. Don't write it on a small paper you will lose, write it in a TODO list, a paper or electronic one, whatever, but write it, and stop thinking about it. When you'll have time, you'll get your TODO list from your pocket and give a look at it, doing what you can do at that moment. Once in a while, you check that list.

Personally, the tool I chose to handle my TODO list is a Palm Centro phone, which I got for only a hundred of euros. It runs the good old PalmOS, which basically know how to handle TODO list and plannings better than all phones I saw so far (and yes, probably better than your iPhone).

My choice was based on the fact that I've random ideas almost everywhere: that means while hacking, but also while walking in the street, while being in the train or while sleeping (yeah, already happened). And the only thing I always carry with me is my phone, in my pocket.

However, Steve choice may be nice if you have Internet access on your phone, which I haven't since it's too expensive for what it is, in my opinion. :-)