4 min read
A familiar story
Imagine you wanted to get your house re-wired, or have your kitchen renovated. You'd call a contractor, and you'd probably expect a journeyman with 10+ years of experience to come in and get the job done.
But what if, instead of sending an experienced journeyman, the contracting company sent you 3 apprentices with 2 months of school and no practical experience under their belt to figure it out as they go? That wouldn't fly, would it?
Now imagine the software world. You have a potential project, and you need to hire some developers to get the job done. Would you insist on hiring a journeyman with 10+ years of experience who has built many systems similar to yours before? Maybe not. More often than I'd like to see, inexperienced devs with 1-5 years of experience are chosen.
Why?
Why do we trust inexperience to build complex systems in software but not in other areas? My guess is it's simply due to the fact that software development is still a young field — i.e. we haven't collectively learned that just like the traditional skilled trades, experience has an enormous effect on the result of your project.
My other guess is that this might be also driven by the ambiguity of programming experience — people are either a programmer or they're not. There's no "apprentice" designation like there is for carpenters or electricians. Maybe there should be! And maybe it should take 4 or 5 years of experience to complete, just like the traditional trades!
Experience vs inexperience: The results
I've seen both ends of this spectrum multiple times throughout my career. I've seen codebases which were built and architected by journeymen, and I've seen codebases which were built and architected by juniors and intermediates. The difference is consistent and significant:
| Jr/Int architected | Journeyman architected | |
|---|---|---|
| Dev team sentiment | Unhappy/frustrated | Happy/productive |
| Product development speed | Slow and grindy | Smooth and consistent |
| Scalability | Refactoring/rewriting necessary | Scalable |
| Business health | Consistently blocked by engineering team | Rarely blocked by engineering team |
The solution: A lesson from the skilled trades
- Ensure there's a journeyman working on or overseeing every project
- Grow jrs/ints into journeymen with apprenticeship training
- Ensure every jr/int has a journeyman to learn from. Apprenticeship is non-negotiable!
FAQs
How many years of experience should I aim for?
If you were building a house, how many years of experience would you want your general contractor to have?
You need at least one developer with 5 or more years of experience, but 7 or more years is ideal. You get what you pay for.
I'm a tech leader. Do I count?
If you're confident you're at the level of a 5yrs experience dev or better, and are going to be able to dedicate the time to be involved in the project, then sure, you count. You can hire a jr or intermediate and guide them.
I've seen many tech leaders whose skills are stale or underdeveloped, so be honest with yourself.
Senior devs are too expensive
Long term, jrs/ints without journeyman mentorship are more expensive.
My jr/int dev says they can handle this project
A journeyman will handle it better!
I had a jr/int build my project and it's great
Building the project isn't the hard part. Maintaining, extending, and supporting it over time in a scalable way is. You'll likely run into issues as you continue supporting your project over time.
My jr/int dev is uniquely talented
In my experience, even the most talented jr/int devs are orders of magnitude below your average senior/staff devs.
When should I hire jrs/ints?
When your journeyman needs support with routine tasks that they can oversee and mentor.
I don't believe it
Then go hire a team of apprentice tradespeople to build you a house!