Forem: Benoit Doyon

Habits of Great Developers: The Underrated Power of Small, Frequent Merge Requests

Benoit Doyon — Tue, 10 Jun 2025 15:31:19 +0000

Trying to measure developer productivity is a famously difficult and often misguided effort. IBM’s historic attempt to gauge output by lines of code written is perhaps the most notorious example. It rewarded verbosity over clarity and activity over outcome.

Yet despite the limitations of rigid metrics, some patterns consistently emerge when you observe highly effective software engineers. At Flare, one habit we’ve seen repeatedly among our best developers is simple and powerful:

They make small and frequent merge requests.

In this post, we’ll unpack why this behavior works so well and how it supports better collaboration, faster iteration, and stronger product delivery.

Why Small, Frequent MRs Work

1. They Reflect Deep Understanding

At Flare, we work within a Shape Up-inspired product development framework. A large part of each cycle is spent on shaping and understanding the problem. By the time execution begins, the scope is usually de-risked and well understood.

When a developer has that deep understanding, they naturally break the work down into clear, manageable chunks. Each merge request becomes one of those chunks: focused, self-contained, and purposeful.

2. They’re Easier to Review and Safer to Ship

Large change sets are difficult to review thoroughly. Even experienced teammates can miss important details when too much is packed into a single MR. In contrast, small MRs:

Surface issues earlier
Make reviews faster and more focused
Reduce the risk of regressions
Are easier to revert if something goes wrong

This supports faster iteration and higher confidence in production releases.

3. They Encourage a Collaborative Mindset

A steady stream of small MRs creates rhythm in a team’s workflow. It encourages collaboration, builds trust, and makes progress visible.

Being stuck on something for too long, however, is a red flag. In one of the most effective teams I’ve worked with, we had a simple rule: if you were blocked for more than 40 minutes, raise a flag. That one principle saved days of frustration and kept momentum high.

What About Big Refactors?

None of this means that large, exploratory change sets have no value. Sometimes, a big refactor is the best way to learn. I often create a scratch branch where I pull apart a system to understand it better.

But that’s not what I submit for review.

Instead, I use that learning to map out a sequence of clean, logical steps. Then I go back and start fresh, delivering the solution through a set of small, testable MRs. That’s when the real progress begins.

Summary: Strong Developers, Small Chunks

Here are a few things you’ll often see among high-performing developers:

Merge requests are small, focused, and submitted regularly
Blockers are raised early and solved collaboratively
Large refactors are used for learning, but final changes are delivered incrementally

Frequent, small merge requests are more than a habit. They’re the outcome of thoughtful problem-solving and deliberate communication. If you want to move fast and build confidently, this is one of the clearest paths forward.

Why LLMs Won't Replace My Junior Developers

Benoit Doyon — Fri, 07 Mar 2025 14:09:53 +0000

We're hiring quite a bit at Flare these days, so I spend a few minutes each day on LinkedIn to scout candidates. It seems that the algorithm has decided that endless posts describing the downfall of the junior developers in the face of machine learning are going to capture my engagement. I guess it's not wrong in a sense, as it has compelled me to explain exactly why LLMs won't be replacing the junior developers in my team anytime soon.

Learning and Growth Require Real Experience

Junior developers aren't here just to ship code. They're learning how to think critically, solve complex problems and collaborate with the team. My AI assistant might write a function given a decent prompt, but it won't be as useful when debugging production, communicating technical ideas, or adapt to ever-changing project requirements. I can't overstate how happy it makes me when I give an assignment to a junior developer and instead of coming up with a flawed merge request, they come back with a question instead.

Context Matters

LLMs are great at generating snippets of code, but they lack the full context of a project's architecture, business logic, and long-term goals. Junior developers, on the other hand, learn the nuances of the codebase, understand why certain design decisions were made, and can make informed contributions that align with the bigger picture. I don't value junior developers as code monkeys, but rather as wielders of a fresh pair of eyes with which to look at a problem.

Over-Reliance on AI Can Be Risky

Using LLMs as a crutch can lead to complacency. Developers, especially those early in their careers, need to understand why code works, not just what code to write. Developing these habits is what allows them to grow into competent senior developers. If juniors skip the learning process and rely solely on AI-generated solutions, they miss out on developing critical problem-solving skills. It's like using a calculator without ever learning basic math. Sure, you might get an answer, but it all breaks down when confronting changing requirements and a nuanced playground. When building products, this basically means all the time.

Junior Developers Bring Long-Term Value

Investing in junior developers isn't just about the present, it's about the future. Today's juniors are tomorrow's leaders. By nurturing their growth, you're building a team that understands your product deeply, values continuous improvement, and can mentor the next generation. More senior developers also gain a lot by having junior members in the team. Flexing those mentoring muscles and learning how to become a multiplier in a team, instead of being a single contributor, is how developers unlock greater potential.

Final Thoughts

LLMs are powerful tools, and I encourage my team to explore them as a way to enhance productivity. But they're just that—tools. They can't replace the curiosity, growth potential, and human connection that junior developers bring.

If you're interested in fostering an environment where junior developers can thrive, we're currently hiring a lead for our platform team. Send me a message and I'll be happy to chat about building an engineering culture where humans are at the center of everything.

https://flare.bamboohr.com/hiring/jobs/73

Why A Great Developer Onboarding Matters

Benoit Doyon — Tue, 18 Feb 2025 13:32:24 +0000

I think most technical onboarding experiences throughout my career have looked something like:

Receive a company laptop
Clone the code repository
Find the latest person who's been through the painful process of setting up a local environment, and hope that they remember what they're doing, especially when trying to attempt to debug the inevitable errors

A poor onboarding process can lead to confusion and frustration, setting the wrong tone for a developer's experience at your company. On the other hand, a well-structured onboarding process ensures they start with clarity and confidence. At Flare, I believe we've found the key to effective onboarding: structured guidance, hands-on experience, and continuous support. And to be honest, it's nothing complicated. These small investments will go a long way to get developers started on the right foot.

The Cost of Poor Onboarding

Hiring great developers is hard. Once you hire someone who's excited to get started, the last thing you want to do is to be a hurdle to their momentum.

Long ramp-up times – New hires spend weeks or months just figuring out where things are and how to get started.
Frustration and disengagement – Without clear guidance, new developers can feel lost or undervalued.
Higher turnover – If onboarding is disorganized, developers may leave before they ever hit their stride.
Team slowdowns – A poorly onboarded developer pulls others away from their work for constant questions and troubleshooting.

On the flip side, a strong onboarding process accelerates learning, boosts confidence, and makes developers feel like they belong.

What Makes a Great Developer Onboarding Experience?

A great onboarding process goes beyond just documentation and checklists. Here’s what truly makes a difference:

1. Clear Expectations from Day One

Developers should know exactly what’s expected of them, what success looks like, and how they’ll get there. A structured onboarding plan with milestones helps keep everything on track. At Flare, since we work with Shape Up cycles, new developers typically follow a specific learning curve. You spend one cycle onboarding and learning, you spend one cycle executing and contributing within a team, and finally you are ready to lead a cycle and champion a project.

2. Easy Access to Tools and Information

Nothing slows down a new hire like missing credentials or outdated documentation. We make sure to automate setup where possible and ensure essential resources (like API keys, test environments, and architecture diagrams) are easy to find. As part of our onboarding, the new hire updates the onboarding documents to ensure they remain accurate and relevant. This ensures that they are always up-to-date, and free of any ambiguity.

3. Hands-on Learning and Small Wins

Instead of drowning developers in documentation, we let them start with small, meaningful tasks. Fixing a minor bug or improving documentation in their first week builds confidence and helps them understand the codebase faster. The way we do this at Flare is with something we call quests, which are sample tasks that everyone does (ex: change the color of a button in the UI, implement a new API listing feature flags). This way you can get relevant comments from everyone on the team, while also making sure your development setup functions correctly in a controlled environment.

4. Mentorship and Support

Assigning a buddy or mentor gives new hires a go-to person for questions and guidance. This helps them integrate socially and technically into the team more smoothly. On top of the buddy system, we make sure new developers spend a day shadowing each member of the team during their second week. This gives them exposure to different workflows, coding styles, and problem-solving approaches, helping them understand how various parts of the team collaborate and function together.

5. Team and Culture Integration

Onboarding isn’t just about code. We want to help new developers connect with their team, understand the company’s culture, and feel like they belong. Casual introductions, team lunches, and pairing sessions make a big difference. We tend to group new hires in cohorts, and we plan a welcome lunch, as well as introductions during the weekly company all-hands.

The Payoff: Faster, Happier, and More Effective Teams

Investing in great onboarding isn’t just about making new hires feel good, it’s about making your entire team more effective. Developers ramp up faster, contribute sooner, and stay longer. A smooth onboarding experience signals that your company values its people and sets them up for success from day one.

If you want a stronger, more engaged engineering team, start with how you welcome them. Investing in great onboarding leads to faster productivity, higher retention, and a more cohesive team. Take the time to refine your process, and you’ll see the impact in every aspect of your development culture. Onboarding isn’t just the first step, it’s the foundation for everything that follows.

Why (and how) we hire software development interns

Benoit Doyon — Fri, 23 Aug 2024 15:16:47 +0000

Intern recruitment season is upon us! At Flare, we typically hire 2-3 interns each semester, with one joining one of our development teams. As we prepare to welcome a new cohort, we’re also gearing up to recruit for the following semester. Here’s an inside look at what an engineering internship at Flare entails, the benefits we gain as an organization, and how we ensure we recruit top-quality candidates.

What an Internship at Flare Looks Like

Before an intern starts at Flare, we’ve already identified a team that aligns well with their skills and interests. During the interview process, we discuss their previous experience, areas of interest, and what they hope to learn. However, once they’re more familiar with what we do at Flare, they’re free to choose the team they wish to join.

Interns undergo the same onboarding process as our full-time developers. The onboarding starts with an introduction to the company, where they learn about our mission, meet leadership from every department, and get a comprehensive overview of our operations. Following this, they dive into developer-specific onboarding, which includes a series of "quests." These quests are essentially sample tasks that cover various aspects of development, ensuring that interns have correctly set up their environment and tools. Throughout this process, they are guided by a "buddy" and supported by their assigned team. Typically, within the first two weeks, interns are ready to tackle a real issue.

Once onboarded, interns are fully integrated into their development teams, participating in our development cycle (see our ShapeUp article for more details). During their semester at Flare, interns work on two full development cycles. This means they will contribute to two meaningul and time-bound projects. The first project helps them get up to speed, gradually taking on larger tasks as they become more comfortable and independent. By the end of their internship, they’ve gained the experience of delivering two increments of user value—an ideal experience for budding engineers.

In summary, our interns are treated as full team members, working alongside experienced developers on meaningful projects. We set realistic expectations based on their experience level but ensure they are fully immersed in our development process.

Why We Hire Interns

Hiring interns offers numerous benefits beyond just increasing development velocity. While gaining additional hands on deck is valuable, the true benefits lie elsewhere.

Firstly, recruiting interns is an excellent way to engage our team in the recruitment process. It’s a low-stakes entry point that allows team members to gain experience in hiring, particularly those who might be hesitant about recruiting more experienced professionals. Our internship hiring process is shorter and less time-consuming than hiring full-time developers, making it an ideal starting point.

Once interns join the team, it’s a fantastic opportunity for team members to develop mentoring skills. Mentoring is a crucial skill that improves communication, processes, and team interactions far beyond the scope of the internship program. In my view, this is the greatest benefit of having interns.

Moreover, providing a great internship experience is important to us. It not only benefits the interns themselves but also contributes to a positive environment that makes future recruitment easier. It's a great pipeline to cultivate to ensure a steady flow of well-trained junior developers joining the team.

How We Recruit Great Candidates

Our recruitment process for interns consists of two main parts. First, we conduct a one-hour "fit" interview. This interview allows us to discuss the candidate’s experience, explain what an internship at Flare entails, and answer any questions they may have. If there’s a mutual fit, we move on to the next step.

The second step is a technical interview. We believe it’s essential to see interns code to ensure they can be productive within our development teams. Given the steep learning curve and the complexity of our distributed systems, we focus on onboarding interns to our way of doing things rather than teaching the basics of software engineering. Therefore, we prioritize candidates with prior experience and assess their capabilities during this interview.

While coding interviews can be daunting, we strive to make ours as comfortable as possible. We ask candidates to solve a simple problem involving around a dozen lines of code, conducted live over video chat. Though this might seem stressful, we allow candidates to use any programming language, tools, or documentation they’re comfortable with, including Google and language docs. They can also ask questions, and we guide them as needed. Our goal is to simulate real work, where we act more as colleagues than interviewers. Feedback suggests that while candidates may feel nervous initially, they quickly relax and enjoy the exercise.

Conclusion

Thanks for sticking with me through this overview of software development internships at Flare! If you’ve got thoughts on our process, I’d love to hear them. And if you’re looking for an internship yourself, don’t hesitate to reach out—we’re always on the lookout for great talent. https://flare.io/company/careers/

ShapeUp at Flare: A Game-Changer for Project Management

Benoit Doyon — Tue, 23 Jul 2024 17:12:29 +0000

I first encountered ShapeUp during one of my initial interviews for a position at Flare. My soon-to-be manager mentioned, “We’re using a methodology that works well for us, but you might not have heard of it before.” With over 10 years of software development experience under my belt, I was skeptical. “If there was a better way to do things, surely I’d have heard of it,” I thought. Little did I know, ShapeUp would fundamentally change my approach to project management and team dynamics.

Before extolling the virtues of ShapeUp, let me provide some context. Throughout my career, I’ve been part of many dysfunctional teams, as well as some exceptional ones that delivered far beyond the norm. I spent a great deal of time thinking about this and trying to replicate those particular conditions in every team I was part of. I was a solid SCRUM advocate. I tend to think that being “agile” works better with a lowercase “a”, and the guiding principle is to craft a process that best suits your situation. However, despite my dedication to SCRUM, I frequently encountered roadblocks in getting teams to perform well.

Enter ShapeUp

ShapeUp, created by BaseCamp, is a methodology that we use to run projects at Flare. The ShapeUp book is a mandatory read for all new employees, and while it’s concise, I’ll outline the key principles we follow:

Work is scheduled in 8-week cycles
- Each cycle consists of a 6-week project period followed by a 2-week cooldown.
No backlog
- Instead, we have a “shaping” process where top-of-mind tasks are defined into projects.
Blurry project definitions
- The problem statement and goals are clear, but the team is trusted to build the solution within the time constraints. Developers are assigned a problem to solve rather than a ticket to complete.
Cooldown periods
- Developers have the freedom to work on whatever they want during the cooldown.

ShapeUp’s simplicity and elegance lie in the details. Here are the main advantages we’ve experienced:

Meaningful increments
- We always focus on the most important tasks, and 6 weeks is sufficient to build something substantial.
Big-picture focus
- Developers are trusted with significant liberty in solving problems, fostering creativity and innovation.
No “just one more sprint…” death march
- With ShapeUp, projects conclude after 6 weeks, preventing endless extensions and allowing for fresh starts in the next cycle.
Protected developer time
- Developers’ time is safeguarded to focus, free from external interruptions during projects and unnecessary justifications during cooldown.

Cooldowns Are Awesome

Cooldowns are a beloved aspect of ShapeUp at Flare. Business stakeholders often remark, “There’s so much great stuff getting done, we should do cooldowns all the time.”

Cooldowns provide the perfect opportunity to:

Conduct retrospectives and plan the next cycle.
De-risk upcoming projects.
Fix bugs, perform meaningful refactorings, and work on passion projects.
Experiment with new technologies.

Developers get really excited about cooldowns, and the business as well. It turns out that if you hire developers that care about their craft and let them run loose for 2 weeks once in a while, they contribute meaningfully.

Additional Advantages

Interns at Flare, typically with us for a 4-month semester, greatly benefit from the ShapeUp cycles. Aligning our cycles with university semesters and holidays allows interns to:

Onboard at the start of a cycle.
Contribute meaningfully to a project.
Apply their knowledge in a subsequent project, experiencing two full cycles during their internship.

Conclusion

Usually seeing is believing, but something feels right even when just being introduced to the concept of ShapeUp. People immediately perk up when we mention how we work during interviews. Candidates we’ve hired that are experiencing ShapeUp for the first time are now becoming ambassadors. After a year with ShapeUp, I know I’m sold.

ShapeUp is more than just a project management approach. It changes the way we approach problem-solving and team dynamics, fostering trust, creativity, and enabling significant progress. If you’re struggling with your current methodology or just curious about alternatives, I highly recommend giving ShapeUp a try. It might just revolutionize your team’s productivity and satisfaction as it has for us at Flare.