Upgrade Flutter juniors 10x faster with this simple system
Put them on the frontline, let them fix real user’s bugs
Flutter is still relatively new, which means there are a lot of beginners, that eventually end up as junior developers.
Today I want to share with you the framework that I used to turn 6 junior Flutter developers into reliable intermediate developers.
Using this framework you can guide juniors in your team and turn them into more reliable developers 10x faster.
Put them on the frontline. Let them deal with real bugs in production.
This post will show you:
What junior developers lack
Building their confidence through experience
Growing their knowledge through paired teaching
Without this system, I would have hired 6 juniors that did not increase my company's output. But because of it, I was able to scale quickly to meet the demand we had and deliver on every single project we worked on.
Let’s get started.
What junior developers lack
It sounds obvious, but junior developers lack experience.
Not experience in years. I’ve always had a problem with experience counted in years because time doing something does not mean you’re better at it. Experience as a developer is very concrete and is all dependent on your tasks, responsibilities, and how much guidance you are given.
In most cases, the junior developers who are hired into teams have the knowledge of the language or framework they’re working with. They’ve done many, many tutorials that show them how to build features, but it still leaves them a junior.
You see, building is only the first step on the software engineer ladder, and as you improve your developer level your perspective changes. Perspective is the way we see our job as a developer, experience is the lens through which we see it. This means, that as your experience increases, your perspective changes.
Here are the different perspectives developers have to go through as they grow as an engineer:
Building - writing new code for a feature. This is where juniors are.
Maintaining - writing code to fix issues occurring in production when users use the app
Building for maintenance - engineering software to deliver fast, and reduce maintenance.
Building with lessons from maintenance - effectively avoiding pitfalls from previous experience
Building for automation - writing code to help the entire team move faster
From this breakdown, it’s clear to see what junior developers lack. Experience in maintenance and identifying real bugs, with the responsibility of fixing them.
Building confidence through experience
Juniors only build, they don’t know that it’s just the first step in the process, but it’s our responsibility to show them.
Here’s what I did:
Make a junior responsible for setting up crash reporting - Even this step gives them insight, most likely overlooked previously. Making them aware of monitoring code health in production is the first step. Now they’ll have an attachment to the “feature” and feel a sense of responsibility to engage with it.
Set up a code health check routine - This doesn’t take long. I used to spend 15-30 minutes in the morning going through reports with one or two juniors and brainstorming with them about what could have caused the crash. This allowed me to see how well they know the codebase. In this time they also get to hear some of my reasoning around trying to understand the bug.
Assign them the bug to fix - This is arguably the most important part. They need to be fixing bugs, real ones, that are impactful. Now this is quite scary, especially with critical bugs. You want it out fast, you want the best developer on it. That’s fine, but in those cases where they can’t be given 1-2 days to fix the bug, you’ll pair them up with your good developer, or yourself.
This is where knowledge sharing comes into play.
Growing knowledge through pair programming activities
The biggest jump in developer output and programming confidence came through pairing up when appropriate and sharing knowledge.
I had many calls with all the juniors, together, sometimes 1-on-1 to explain how I fixed something, what I found, and the process I used to get there. There are many ways to “naturally” team up, but not all of them involve blocking out 1-2 hours every 2 weeks to program together. Here are the places where I taught the most impactful lessons to junior developers:
Pair programming: 1-on-1 viewing of bug fixing and talking through fixing problems
Plan approval system: This is less time-intensive than pair programming for you as the senior. Ask the developer to write a document before writing code. It should include:
What the problem is, in plain English
How we’re going to fix/implement it, plain English
How we’re going to fix/implement it, in programming terms
How we’re going to test it, all the use cases it must cover
Code reviews: A natural part of the development process, and a great place to teach juniors. Enforce your team-wide opinion, and give clear instructions on HOW and WHY to make the changes you’re asking for.
Having systems like these in place might feel cumbersome, but a system produces consistent results. This works, and all the developers that came from FilledStacks have received praise, from the first day they started at their new positions.
Companies reached out to me to thank me for how skilled my original FilledStacks team was.
But all of this only gets you to the intermediate level. To add additional experience to the juniors that get them to write code that reduces maintenance, read this article on how to write excellent Flutter code.
Let’s work together
Book a 1-on-1 call with me to take the next steps for your Flutter project.