This is a really interesting phenomenon that I've experienced before myself but I hadn't fully understood or appreciated as clearly as the author has.
At my company we put a big emphasis on code reviews. We encourage devs to pull request code fairly regularly to keep PRs relatively small (when possible) -- before so much code has been written that it's not really possible to change course without blowing up deadlines. We encourage our junior devs (who might not be capable of identifying bugs or proposing fixes on code written by a senior) to ask questions in their code reviews -- to verify assumptions, to request an explanation of how something works, confirm that a particular edge case has already been considered, etc. It can be hard to get a junior dev comfortable with doing this (questioning a senior dev), but even if the junior isn't identifying bugs it will often lead the senior to better understand their own code and the architectural concepts that underpin their own coding decisions. Like the author points out, this only happens because the senior dev endeavors to explain their work to the junior dev (Protege effect). Also, a good many times it leads the senior dev to re-consider how they wrote something and they might add a revision to address a possible edge case not previously considered. I hadn't thought of it this way before, but this is the Socratic method that the author talks about.
We also put a big emphasis on in-code comment writing -- largely following the commenting principles laid out by John Ousterhout's "A Philosophy of Software Design". These comments are of course for long-term maintenance purposes, but they also benefit team learning. Class, method and variable naming are obviously important too. Our internal code reviewing mantra is that 'I want to be able to read your code like a story book -- when I get to the end, I at least want to be able to understand what happened'. Not always possible, but a good goal. Writing comments and choosing class/method/variable names in pursuit of that goal massively contributes to the learning of the team. During our code reviews, one of the most common requests by reviewers is for the author to add a comment explaining something that was very difficult (or impossible) for the reviewer to grasp on a first read.
This approach has worked very well for us. Everyone learns and our product quality improves.
You have to be OK getting rid of productive assholes that mess up this culture. The hint of a senior not being open to criticism will instantly halt any ability for a team to have a safe, open dialog.
Yeah, very true, when we're hiring we'll sometimes skip over the most talented candidate and pick a candidate who we feel would be the better communicator, easier to work with and fit in with the team. Easier said than done, but we at least try to hire for that.
This thing with small PRs bothers me somehow.
Where does design happen? Do we just make endless tactical changes?
For juniors this is even worse, they get to wait until PR time to validate their design. With trunk based development this means continually commiting unreachable code with back and forth with more senior staff via PRs, instead of sitting down for an in depth discussion where they'd actually learn how to do this job.
This isn't really aimed at the parent poster, just an observation. I've been working since 2006, GitHub brought in PRs and I think we lost something over night: code reviews where you get to sit with more senior staff and discuss your code.
I've been working through PRs since around 2011 and I don't think I've ever seen a place where PRs were intentionally used to handle design issues. Occasionally design problems will get brought up in PR, but that's always been considered a failure of earlier planning when it happens.
Depending on the company, the design discussion you're talking about has happened:
1. In verbal discussions with other devs before fingers ever touch keyboards
2. In long-form writing (Text docs, then Google docs, then later Notion)
3. In per-project slack channels
4. Out loud, on a whiteboard.
Right now it's very much #4 because my company is 2 devs and a founder. But even here, I wouldn't expect to get anything non-trivial into pull request before figuring out the overall structure with the other dev verbally or in writing.
At my first job a few years back I sat down with a senior dev at least once a week (informal meeting) to discuss my tasks and the code bases we were responsible for in general. It was incredibly helpful. I could also request feedback at any time. At the end of it, the final PR might be large, but it had mostly been discussed and reviewed by then, so doing a final review was more of a formality, dotting the i's and crossing the t's to ensure the criteria had been properly fulfilled.
In addition, writing code that is accessible to juniors (which should apply to a large majority of a code base) increases the velocity of everyone on the team. Readability, modularity, and consistency create standards and examples for a junior to work by, which is a great way to learn and lower the risk of bugs and surprises.
Yup. This is why I favour simple architectures like MVC over complex ones like VIPER.
While there may be exceptions, I default to: if an app is so messy as to consider a more complex architecture, it probably has so much going on as to be difficult for the end user to use it.
Truth is if you are doing the kind of work that fits into code reviews, small PRs and neat deadlines, does any of it matter? You're describing a tech enabled agency, not a startup. Sure customers have alternatives, but in the same sense that we have choices when booking airline tickets: you are describing a development process for a product that is fundamentally fungible, so the main differentiator among producers is costs, not management strategy.
Why on earth would a startup's code not be reviewable?
If I'm doing a big chunk of work, I still do it in small PRs. That first PR (or a design doc) might outline a strategy for the ones that follow, but still try to have small PRs. Or, worst case, I do a big chunk of work and break it out into small logical chunks for review.
I'm still cleaning up after the unsupervised junior two years later.
To me, the definition of junior is someone who needs guidance. If you don't have a good process of defining tasks before they're worked on and real code review before things get merged, you are not set up to work with juniors, and hiring them is doing both yourself and them a huge disservice.
100% this; unfortunately also often seeing junior devs called staff after job hopping for 3 or 4 years never really learning anything.
Junior job titles are nearly as much of a mess as interviewing them.
Particularly in recent hot topics like AI the reality is you want both experienced and less-experienced devs. Most AI teams I see actually lack AI experience and keep falling for the same issues (like quickly getting to 80% working and thinking just a bit more data to 99.9%)
In the Company I work, I constantly find architects, senior and chief architects, who come directly from the university, without any real world experience… sooo nice to work with them
This is a bit confusing to me because I am quite sure nearly everyone <10 YoE needs guidance one way or another. Similarly almost every dev needs real code review. Without code review everyone breaks things all the time.
Seems to me like "the unsupervised junior" isn't participating in the "Socratic method" the article discusses, but your experience does impugn the author's hypothesis that the burden of Junior Developers will drive out a better process ( as a forcing function) eg your "real code review" and "good process of defining tasks".
It might in a lot of places - if anybody even notices that there's a problem and if they then have the political capital to change it.
In this case, nobody really kept an eye on how things were being built, and the person was actually remarkably productive. I really don't have a bad word to say about them: they were given vague tasks and came back, for most of them, with working implementations. We're only a handful of people and everybody was busy elsewhere, but what little guidance and review we could offer was always accepted with much gratitude. They lasted about 18 months before moving to somewhere that offered more support, and I can't blame them at all.
What happened is predictable: things that ought to be in one place end up distributed in little pieces, and existing features got invasively modified to add new features even when that wasn't necessary. Poor separation of concerns, design patterns applied wrong, all of the stuff that over time adds up to a codebase that's hard to work with.
I think a lot of the refactoring we do would make a good book, actually, if any of us were the type to write about programming.
My company's general policy is to only hire junior devs. In fact not even "junior": after the founders, every one of us began here as high school interns, either juniors or seniors in HS.
This has been immensely helpful in New Hampshire because talent is more sparse, and lots of good people would love to stay in NH if only there were jobs at graduation. It turns out plenty are willing to if they have an offer well ahead of time.
This won't work for companies trying to blitz-scale everything, but I bet it would work for a lot more than the amount trying it. And it would especially work for companies located outside major metros.
The thing you are describing is similar to something I do and I think it's a good idea. People who aspire to be good software developers start pretty young, just like with actors, musicians and athletes, and it's no surprise the commonality among 10x developers is very early programming experiences.
But the words you used in your comment are so bad! Communications is your job!
"Policy?" It's a recruiting strategy. Why on Earth did it occur to you to use the word "policy?" It's not a policy!
"Only?" Not true. You mean that you've observed something works for you. Then you've one-armed-bandited it, and it kept working. Which is great!
"Junior?" No dude, don't dump on your people. This is a talent development program. Nobody calls the Mickey Mouse Club "junior" actors.
"New Hampshire because talent is more sparse:" Don't dump on New Hampshire, you live there. Try, "New Hampshire is an underrated community."
"This won't work for companies trying to blitz-scale everything:" Nobody set up this straw man but you.
"...outside major metros." Don't dump on your community!
The miscommunication on "policy" alone got the high-drama people out of the woodwork and derailing an interesting comment thread.
It used to be more common for companies to hire people with no coding experience into development roles, and then train them. In my first two jobs I saw that happen several times with good results.
Even people with university CS programming experience will in reality have only learned a fraction of what's involved in writing and maintaining production code for a business.
that isn't good as you miss out on things outside your org as you become an echo chamber. There needs to be a mix ideally about 20% of those who retire from your org started there as a first job. Enough to prove retention matters, but not so much that you don't learn from elsewhere.
I work with a nonprofit that tries to bridge the gap between bootcamps and the so-called real world. There are so few companies that really understand how to nurture developers, and I am curious how AI will affect this. A lot of learning dev is not about coding, it's about thinking creatively and working with other humans.
Every decision process is discriminatory, by definition.
But it doesn't discriminate on a prohibited basis (the decision to only bring in developers as novice interns itself; if the way you are choosing interns does, sure, that's a problem, but its orthogonal to the issue), so that's not a problem.
In my own mentoring and team building experience, your assessment regarding juniors and generalists is correct.
Specialism vs generalism is very much a mindset of a person and not strictly dependent on their past experience. I suspect it has much more instead to do with their ability and willingness to build a mental abstraction behind the concrete implementation they have experience with.
To refine the conceit: A specialist will see only the tool, but a generalist will see the way the tool solves a specific problem and get an idea for how other tools can solve it.
I'm being a little hard on specialists here; a good specialist may often have a far more thorough understanding of how to wield their chosen tool and come up with a better solution using it... Assuming they aren't trying to hammer in a screw, of course.
Generalist here. They don't list jobs saying "generalist", but most companies with small to medium (<200) engineering orgs very much require generalists even if they don't know it yet. Most of the time if you walk in with a wide set of abilities and a willingness to use them and you'll have plenty of chances to do so.
The jobs aren't rare, but they usually aren't paying as much as an experienced specialist (and certainly not paying more, despite the job covering a larger knowledge area). Since experienced generalists are always still going to have some areas they have more knowledge in than others, I think it leads to them applying for the higher paying specialized positions.
Almost nobody hires junior developers, and those who do have the minimum requirement is 5+ full-stack YoE with 3+ YoE with RDBMS and 2+ YoE of instrumentation, monitoring and DevOps.
I kid you not, it's a real junior-level position description a friend* had sent me just yesterday (was a screenshot, or I would've linked it).
[*] Shameless plug if someone's hiring: my friend is a Pythonista, looking for a junior-level job in the US (she's a green card holder): https://nvp85.net/
This is a tough thing to have a useful discussion about in this industry where people can hardly agree on what a "Junior" and "Senior" developer are.
I don't agree with the dichotomies that the author lays out here, for example the idea that juniors are generalists and seniors are specialists or the claim that you need juniors on your team in order to have a culture of teaching and cross-training. But I do think that hiring juniors is important to the health of the industry and can be beneficial to many orgs.
It seems like everyone wants to hire a senior dev, but nobody wants to train the juniors into seniors.
In my experience, all hiring is a gamble. Hire a bad junior and you run the risk of them being dead weight, or worse, they fuck up your codebase and drain time and resources from your more useful devs. Hire a bad senior and they're about as bad, but you sunk a lot more money into their paychecks. Hire a good junior and you get awesome work for a discount, though you'll need to promote them before they learn their worth and move on. Hire a good senior and you'll have someone who can build whatever you need, diagnose any problem, lead a team, teach skills to their coworkers, and so on.
Also, it will always depend on your org and your team. Some big companies have new grad programs where they have programs to teach and onboard people so that they can effectively absorb huge cohorts of juniors. They've run the numbers and have determined it's worth the investment. On the other hand, some companies simply don't need juniors at all. Think early stage startup or a lean stable small to mid-sized company; at places like that you can really do everything with 10-20 good seniors.
Senior devs create senior devs - I think it's been this way for a long time. The best people self-select to learn more, work harder, get promoted, and lead teams/projects.
Personal development and self (re)search is what makes 'senior' developers along with certain amount of confidence. The latter can be made via faking, though.
Eventually seniors leave. You need people to replace them. You don't want to pay the highest possible price. You want people who know your system already. Hire juniors and train them up. This isn't hard.
Or it can be near impossible. Large orgs can have dedicated onboarding programs for junior developers, this can work quite well. Small or medium orgs can have one or a few senior developers who are passionate about mentoring. This can also work well, but is unusual.
What is much more common is for new hires to encounter a nearly impenetrable wall of “figure it out, don’t bother me”. I have experienced both, and I’m sad to relate I’ve been a wall at times. I found I could only explain a stack trace n times to the same person before I personally noped out of training juniors.
I’m a junior-mid level web dev now and when I first cut my teeth my senior dev was very much a wall. It wasn’t intentional but when you do something for 10 years, you just forget how it feels to not know what you don’t know.
It made me really start to learn on my own and figure out how go from 0 on many different skills. So personally I really think it’s about the junior and how much they’ve figured out their learning style, and being “a wall” like this can sometimes force them to learn by reading through all of your old code. Inadvertently leading by example is still really good
What I'm seeing in the current market is almost zero junior positions. Companies have tightened belts, lowered salaries, and expect mids and seniors to just make do. There is no future for the software industry with this mentality. What happens if the next five years no juniors are converted into mids and seniors?
Readit News
At my company we put a big emphasis on code reviews. We encourage devs to pull request code fairly regularly to keep PRs relatively small (when possible) -- before so much code has been written that it's not really possible to change course without blowing up deadlines. We encourage our junior devs (who might not be capable of identifying bugs or proposing fixes on code written by a senior) to ask questions in their code reviews -- to verify assumptions, to request an explanation of how something works, confirm that a particular edge case has already been considered, etc. It can be hard to get a junior dev comfortable with doing this (questioning a senior dev), but even if the junior isn't identifying bugs it will often lead the senior to better understand their own code and the architectural concepts that underpin their own coding decisions. Like the author points out, this only happens because the senior dev endeavors to explain their work to the junior dev (Protege effect). Also, a good many times it leads the senior dev to re-consider how they wrote something and they might add a revision to address a possible edge case not previously considered. I hadn't thought of it this way before, but this is the Socratic method that the author talks about.
We also put a big emphasis on in-code comment writing -- largely following the commenting principles laid out by John Ousterhout's "A Philosophy of Software Design". These comments are of course for long-term maintenance purposes, but they also benefit team learning. Class, method and variable naming are obviously important too. Our internal code reviewing mantra is that 'I want to be able to read your code like a story book -- when I get to the end, I at least want to be able to understand what happened'. Not always possible, but a good goal. Writing comments and choosing class/method/variable names in pursuit of that goal massively contributes to the learning of the team. During our code reviews, one of the most common requests by reviewers is for the author to add a comment explaining something that was very difficult (or impossible) for the reviewer to grasp on a first read.
This approach has worked very well for us. Everyone learns and our product quality improves.
For juniors this is even worse, they get to wait until PR time to validate their design. With trunk based development this means continually commiting unreachable code with back and forth with more senior staff via PRs, instead of sitting down for an in depth discussion where they'd actually learn how to do this job.
This isn't really aimed at the parent poster, just an observation. I've been working since 2006, GitHub brought in PRs and I think we lost something over night: code reviews where you get to sit with more senior staff and discuss your code.
Depending on the company, the design discussion you're talking about has happened:
1. In verbal discussions with other devs before fingers ever touch keyboards
2. In long-form writing (Text docs, then Google docs, then later Notion)
3. In per-project slack channels
4. Out loud, on a whiteboard.
Right now it's very much #4 because my company is 2 devs and a founder. But even here, I wouldn't expect to get anything non-trivial into pull request before figuring out the overall structure with the other dev verbally or in writing.
I thought it was a great process.
While there may be exceptions, I default to: if an app is so messy as to consider a more complex architecture, it probably has so much going on as to be difficult for the end user to use it.
https://blog.pwkf.org/2022/09/18/always-optimize-for-dummies...
> ...PRs relatively small (when possible)
> ...deadlines
Truth is if you are doing the kind of work that fits into code reviews, small PRs and neat deadlines, does any of it matter? You're describing a tech enabled agency, not a startup. Sure customers have alternatives, but in the same sense that we have choices when booking airline tickets: you are describing a development process for a product that is fundamentally fungible, so the main differentiator among producers is costs, not management strategy.
If I'm doing a big chunk of work, I still do it in small PRs. That first PR (or a design doc) might outline a strategy for the ones that follow, but still try to have small PRs. Or, worst case, I do a big chunk of work and break it out into small logical chunks for review.
And even startups can have deadlines.
To me, the definition of junior is someone who needs guidance. If you don't have a good process of defining tasks before they're worked on and real code review before things get merged, you are not set up to work with juniors, and hiring them is doing both yourself and them a huge disservice.
Junior job titles are nearly as much of a mess as interviewing them.
Particularly in recent hot topics like AI the reality is you want both experienced and less-experienced devs. Most AI teams I see actually lack AI experience and keep falling for the same issues (like quickly getting to 80% working and thinking just a bit more data to 99.9%)
In this case, nobody really kept an eye on how things were being built, and the person was actually remarkably productive. I really don't have a bad word to say about them: they were given vague tasks and came back, for most of them, with working implementations. We're only a handful of people and everybody was busy elsewhere, but what little guidance and review we could offer was always accepted with much gratitude. They lasted about 18 months before moving to somewhere that offered more support, and I can't blame them at all.
What happened is predictable: things that ought to be in one place end up distributed in little pieces, and existing features got invasively modified to add new features even when that wasn't necessary. Poor separation of concerns, design patterns applied wrong, all of the stuff that over time adds up to a codebase that's hard to work with.
I think a lot of the refactoring we do would make a good book, actually, if any of us were the type to write about programming.
This has been immensely helpful in New Hampshire because talent is more sparse, and lots of good people would love to stay in NH if only there were jobs at graduation. It turns out plenty are willing to if they have an offer well ahead of time.
This won't work for companies trying to blitz-scale everything, but I bet it would work for a lot more than the amount trying it. And it would especially work for companies located outside major metros.
I wrote a bit about our process here: https://simonsarris.com/p/growing-software-developers
But the words you used in your comment are so bad! Communications is your job!
"Policy?" It's a recruiting strategy. Why on Earth did it occur to you to use the word "policy?" It's not a policy!
"Only?" Not true. You mean that you've observed something works for you. Then you've one-armed-bandited it, and it kept working. Which is great!
"Junior?" No dude, don't dump on your people. This is a talent development program. Nobody calls the Mickey Mouse Club "junior" actors.
"New Hampshire because talent is more sparse:" Don't dump on New Hampshire, you live there. Try, "New Hampshire is an underrated community."
"This won't work for companies trying to blitz-scale everything:" Nobody set up this straw man but you.
"...outside major metros." Don't dump on your community!
The miscommunication on "policy" alone got the high-drama people out of the woodwork and derailing an interesting comment thread.
Even people with university CS programming experience will in reality have only learned a fraction of what's involved in writing and maintaining production code for a business.
But it doesn't discriminate on a prohibited basis (the decision to only bring in developers as novice interns itself; if the way you are choosing interns does, sure, that's a problem, but its orthogonal to the issue), so that's not a problem.
I don’t think all generalists are juniors nor are all juniors generalists.
Why lump them together here?
We need more experienced generalists in our industry.
Specialism vs generalism is very much a mindset of a person and not strictly dependent on their past experience. I suspect it has much more instead to do with their ability and willingness to build a mental abstraction behind the concrete implementation they have experience with.
To refine the conceit: A specialist will see only the tool, but a generalist will see the way the tool solves a specific problem and get an idea for how other tools can solve it.
I'm being a little hard on specialists here; a good specialist may often have a far more thorough understanding of how to wield their chosen tool and come up with a better solution using it... Assuming they aren't trying to hammer in a screw, of course.
A senior dev is a specialist in your company, a junior often has pretty broad skills that apply across companies.
I kid you not, it's a real junior-level position description a friend* had sent me just yesterday (was a screenshot, or I would've linked it).
[*] Shameless plug if someone's hiring: my friend is a Pythonista, looking for a junior-level job in the US (she's a green card holder): https://nvp85.net/
I don't agree with the dichotomies that the author lays out here, for example the idea that juniors are generalists and seniors are specialists or the claim that you need juniors on your team in order to have a culture of teaching and cross-training. But I do think that hiring juniors is important to the health of the industry and can be beneficial to many orgs.
It seems like everyone wants to hire a senior dev, but nobody wants to train the juniors into seniors.
In my experience, all hiring is a gamble. Hire a bad junior and you run the risk of them being dead weight, or worse, they fuck up your codebase and drain time and resources from your more useful devs. Hire a bad senior and they're about as bad, but you sunk a lot more money into their paychecks. Hire a good junior and you get awesome work for a discount, though you'll need to promote them before they learn their worth and move on. Hire a good senior and you'll have someone who can build whatever you need, diagnose any problem, lead a team, teach skills to their coworkers, and so on.
Also, it will always depend on your org and your team. Some big companies have new grad programs where they have programs to teach and onboard people so that they can effectively absorb huge cohorts of juniors. They've run the numbers and have determined it's worth the investment. On the other hand, some companies simply don't need juniors at all. Think early stage startup or a lean stable small to mid-sized company; at places like that you can really do everything with 10-20 good seniors.
Or it can be near impossible. Large orgs can have dedicated onboarding programs for junior developers, this can work quite well. Small or medium orgs can have one or a few senior developers who are passionate about mentoring. This can also work well, but is unusual.
What is much more common is for new hires to encounter a nearly impenetrable wall of “figure it out, don’t bother me”. I have experienced both, and I’m sad to relate I’ve been a wall at times. I found I could only explain a stack trace n times to the same person before I personally noped out of training juniors.
It made me really start to learn on my own and figure out how go from 0 on many different skills. So personally I really think it’s about the junior and how much they’ve figured out their learning style, and being “a wall” like this can sometimes force them to learn by reading through all of your old code. Inadvertently leading by example is still really good
In short don’t sweat it