1. 42
  1. 32

    Oh boy, I have a lot of feelings about this. Good on the author for bringing it up.

    Junior developers (having been one) are amazing to have around and, if handled properly, are a major force multiplier.

    Personally observed benefits of junior devs:

    • They are hungry. They are looking to get that paycheck, no matter how small it is compared to a senior developer, and since they’re often hourly they’ll actively look for additional work to do if managed properly to pad out beer money or rent or childcare or family care or whatever. Senior devs begin playing a game (if they’re smart) of “I am salaried…how can I exert minimum effort for maximum possible revenue?” Senior devs also know themselves better, and so they can often say “Yeah, $X is enough, I don’t see the personal upside in taking on more work even with a pecuniary benefit”.
    • They don’t know what is hard and what isn’t. They are juniors, and so they attack tasks (architectural and scutwork) with near equal optimism. You can give them something that’s impossible and they’ll come back with solutions that actually are good-enough fudges for business purposes.
    • They want to learn. The only way to become a senior developer is by learning things, and a lot of junior devs have a chip on their shoulder (acknowledged or not) about not knowing enough–so, they’ll go do new things and learn about them and try to show off that learning. Senior devs often go with tried-and-true knowledge because they know how to execute most quickly with it; a junior dev can help uncover better solutions that would be ignored otherwise.
    • They might know things you don’t. Hell, I learned React in from an excellent junior dev.
    • They’ll stick around longer. Similar to being hungry, the friction for a junior dev to switch companies is higher (they underestimate their own knowledge and value, remember?) than for a senior dev. So, if you display even marginal competence and compassion towards them, they probably won’t jump ship. Also, their pay scale starts so much lower so that you can keep giving real raises without worrying about breaking the bank.

    However, there are severe pathologies to junior devs:

    • They suffer extra from morale-stressing situations (modulo life experience). A junior dev can get stuck in a project or stuck with a bad situation and really just ground down by it, where in the same place a senior might go “well, this sucks, but we can see it through”. They haven’t had a lot of history of failed and successful projects, so they can take things too hard.
    • They love learning new things, and want to try them out all the time. Until trained properly, junior devs have very little conservatism in their engineering. They’ll switch from Backbone to Angular to React because they’re learning new and exciting things–even if the original domain just needed a static server-side page.
    • They are really bad at software estimates. Like, even moreso than normal, because they lack the breadth of experience to know what paths in a project are probably most filled with spiders and which ones are tedious but quick.
    • They are bad at managing others. Juniors are just barely getting their own career and projects in order, and usually lack the technical, political, and engineering proficiency to organize and communicate effectively with others in a leadership role. This does not mean they shouldn’t (with careful and direct supervision) be forced into it–after all, that’s how they learn!
    • Modulo life experience, they focus on tech more than customers. Due to their desire for knowledge and improvement, they often miss the essential chatting with customers/users of a software project that can pull out hidden requirements or even allow for shipping partially complete work.
    • They can make a huge mess. Given credentials to production system, or given large foundational architecture work, juniors can do bizarrely well-intentioned things that result in total chaos. Seniors can (and do!) have the same problems, but they’re usually more likely to ask for help or exercise caution.
    • Modulo life experience, they don’t understand themselves. Juniors have a hard time spotting when they’re getting overloaded or burned out, and they have a hard time figuring out why they feel a certain way about technical and interpersonal conflicts. This results in communication problems, chaos, and general bad vibes until addressed.
    • They will dutifully reproduce the dev practices around them. So, if all of the example code for solving something does weird shit, juniors will dutifully continue doing weird shit. If the build process is crackheaded and error-prone, the juniors will dutifully keep running it and running into problems and, as noted above, probably continue creating problems. And they’ll teach other more-junior devs to do the same!

    I’ve got thoughts on the care and feeding of junior devs, but this post is already rather long.

    1. 4

      Thanks for sharing this, you’ve crystallized a lot of my own thoughts on junior devs excellently. I taught at a bootcamp for a while, and my favorite thing about new dev you summed up as, “They don’t know what is hard and what isn’t.” It was so cool to see these fresh students attack problems that I would have immediately dismissed simply because they didn’t know how hard it was. I think this is an excellent lesson for senior devs as well, a kind of “beginner’s mind” that’s hard to obtain.

      I think any project is like this: if you knew how tough it would be at the end, you probably wouldn’t have started it. Our ability to over- and under- estimate can sometimes be a huge boon.

      1. 4

        If you get the urge to write about the care and feeding of junior devs, I would be interested in reading it.

        1. 2

          It’s not totally independent of the items you’ve listed, but one thing I’ve noticed about juniors is that they also don’t stop to think whether the things they build upon are designed to be taken to scale. So with juniors around, it can be dangerous to say “OK, let’s embrace the fact that we have 5-10 of these things currently, so we’ll do something quick that relies on this fact, and we’ll switch to something more sensible when we need to scale in this direction.”. The moment you look away, you’ll find that a junior has written a script to auto-generate thousands of those things and built an entire structure around it without questioning whether the rest of the system was ready for it (however obvious that might seem to you).

          I think the broader point here is that juniors are much more susceptible to tunnel vision, where they only focus on what they’re trying to solve at a given moment without considering the big picture.

        2. 20

          This is something I pushed against a lot at my last job. We wanted to hire Juniors and Associates, but every time we interviewed one we always rejected them as “not experienced enough”. The training is always someone else’s problem.

          We’ve known for a long time how to fix this: train people. Companies don’t like it because they don’t “have the time or money”, but this is the exact opposite of the truth. Edwards Deming calls “emphasis on short term profits over long term consistency” one of the deadly diseases of modern industry.

          One idea I had to make this more palatable to managers is to hire juniors as programming assistants, that spend part of their time doing training and another part doing helpful work for other developers.

          The reality is that most software developers don’t stay one place very long, so maybe it doesn’t make sense to invest a lot in training someone?

          Good thing investing in training leads to higher retention!

          1. 2

            Our industry’s inability to mentor and train people effectively in software engineering is due to the wizard myth that somehow keeps going and going, and is ruining everything from interviews, training, quality, and process.

          2. 11

            Flat org structures are celebrated right now, but they imply high overhead for junior developers since mentoring and management must be entirely ad-hoc. Reversing this trend would require companies to shift mindsets from “a senior developer is a replaceable cog” to “a senior developer is a low level manager who grows more senior developers out of a small, productive team”. I’d bet most startup level companies would read that and think “ew, gross, middle managers”, or “ew, gross, spending money on developing people who will just leave”.

            1. 3

              This rings very true. We resisted the typical hierarchy as much as possible for many years, and we finally relented once we realized that, with junior developers and designers, structure is necessary for their development.

              1. 3

                I’m very lucky to be part of a startup that takes the second interpretation of senior developer, and does a good job of hiring a mix of junior and senior.

              2. 9

                I don’t know that it’s off-base to think that startups shouldn’t hire junior developers. A dev team has to reach a certain size, a certain profitability, and a certain probability of having a future before it can reasonably afford to maintain a developer training pipeline.

                I would suggest that part of the problem with the industry is that there are too many startups. The Paul Graham “do a startup first” method works for the upper end of the developer bell curve, but for a lot of people (and arguably for the industry as a whole) the traditional method of joining a company big enough to have some training infrastructure and doing your apprenticeship there before launching on your own works better.

                1. 7

                  At my current company we started up with a team of ~10 developers, all experienced. It was a terrible mistake in my opinion.

                  Because everyone was experienced and we were a startup under huge pressure to ship, we cut way too many corners. We knew everyone was good enough to deal with the mess we were creating, at least temporarily.

                  But in the long run, we had to pay it all down, and it cost us way more than we initially thought. Write the missing documentation, remove needlessly over-complicated code, untangle a mess of inter-dependencies… We are not even done with it yet, and it has been four years.

                  Had we had a balanced team, that would not have happened. Juniors would have forced us to document more, write more straightforward code they could understand, do code reviews and not have so many parts of the code base owned by a single person with no one else really understanding how it works.

                  I knew it was the problem, because my previous company (also a startup, since then acquired by Google) had been the opposite. Most hires were juniors, trained internally. It resulted in a cohesive team with the same code culture (no clashing styles, useless debates on which tools to use…) and processes that led to much cleaner code, even though the problems we were solving were probably harder. Training sure takes time, but eventually it pays off, especially if you have good retention (which we did).

                  I was just a developer on my current team when I joined, now I am in a position where I am in charge of leading it and preventing those issues in the future. One of my first decisions was to hire juniors, and I can testify that it is working so far.

                  Note that I am not saying that there should not be seniors and that you should never cut corners at a startup. Actually, knowing when and how to cut corners is probably one of the most important skills of a senior developer at a startup in my opinion. When you have to add features to your production code before Tuesday next week because [something something involving VCs], that’s when you need someone who can do that dirty hack that will work short term, but who also knows how to avoid catastrophic bugs without the time to write enough tests, and how the hack will be reversed in the future without too much impact. That is the one situation where you take two or three senior developers you trust, lock yourselves into a room and do your thing. But hopefully, that doesn’t happen too often.

                  1. 2

                    At size 10, it is probably time for more balance. But that experience sounds more like “our experienced developers made a mistake” than “having experienced developers was a mistake”. I mean, experience shouldn’t dictate cutting corners unnecessarily — quite the opposite. If you really had to cut that many corners to survive, then having to manage juniors as well might have been deadly, and cleaning up afterward is the tradeoff you consciously made (and one that most startups have to make).

                    Ideally you aren’t in so much of a race against time and can “plan for success” from the beginning by starting a dev training pipeline right away, but that seems like a luxury you can’t count on at first.

                    All that said, the worse imbalance is to have no sufficiently experienced developers — see any number of bizarrely mismanaged blockchain startups in the news — which is what makes me think “too many startups”.

                    1. 1

                      Oh, it’s another topic entirely, but I certainly agree with that last sentence as well…

                2. 19

                  Who Killed The Junior Developer?

                  Probably all those senior developers who are stuck doing junior-level work for junior-level pay under junior-level conditions.

                  On one team I did most of the mentoring of a junior dev and I felt it was considered less-than the “real” work the other developers did, which later made me reluctant to take on these roles. Yeah, I’m gonna bring gender into it, because I’m a woman and when women take on roles like this they often get pigeonholed into “den mother” stereotypes. That means less prestige and less prestige usually means less pay.

                  I’ve been there.

                  This isn’t only an issue for women. I’m a man, and when I did “female work” like mentoring juniors and standing up for my reports, it got me in trouble, because I was supposed to do the “male work” (basically, being a prick on behalf of executive man-children, so they can be loved and take credit for the good things, while you push their orders and pretend the shit comes from you). Toxic masculinity is a huge problem in the corporate world, but it’s not only women who suffer.

                  I get less of that shit now that I lift. I’m still not an “alpha male”, nor do I especially care to be one, but at least I look it.

                  1. 6

                    we don’t hire junior developers because we can’t afford to have our senior developers mentor them

                    That’s not why we don’t do it: our issue is that junior developers simply aren’t productive enough to warrant the expense.

                    1. 16

                      The other consideration is; expend resources (ie seniors time) training entry level, only to see them leave in a year or two for large pay raises. It’s nearly impossible for business leaders to understand that 100% pay increases are required after a couple of years in this field.

                      1. 4

                        So how does one break the cycle? Junior developers will have to learn somewhere. Are we in a situation similar to the video game industry, where we actually have too many programmers on the market?

                        You can certainly learn a lot outside of work, but there are a lot of things that are best learned on a job.

                        1. 4

                          where we actually have too many programmers on the market?

                          Yes. Absolutely. And every programmer is a special snowflake which makes it impossible for anyone except another programmer to read their CV.

                          1. 0

                            The fact that pay is high is probably an indicator that that isn’t true.

                            1. 2

                              Pay is high in some areas. It’s crap in others. It’s mediocre in others. I think it says more about the practices of businesses in a given industry and geographical area than anything else.

                              1. 2

                                Adjusted for that it’s nearly double the median wage. I would say there are not too many developers.

                                1. 2

                                  Depends on the area. In the Mid-South, there’s plenty of IT people, including programmers, making $12-15 an hour. Minimum wage is just over $7. We obviously have many move from this area but steady stream to fill those positions from colleges. Things that vary this much by area I usually talk about in terms of the area. Otherwise, the generalizations can be meaningless.

                                  Except for when you say there aren’t too many developers. I agree with that if we factor in skill or tech they know about. There’s just not so many companies wanting to invest in junior ones or pay senior ones well.

                                  1. 5

                                    As a southerner I can anecdotally say that’s caused by a lack of labor organization and not a glut of programmers. Low willingness to pay is because they’re hoping to pick up someone who is willing to work for peanuts, not because there are too many developers. In fact they frequently take on business impact because of unfilled positions.

                                    1. 1

                                      That makes sense to me as well (having worked in those sorts of jobs during college in the south and southeast)

                                      1. 1

                                        That sounds about right. You bet I call them out for it, too, if they get high and mighty with the politics. ;)

                        2. 4

                          I’m a solo-preneur, so I’m definitely not qualified to answer the questions here, nor the the one I’m posing:

                          I wonder what the “coding bootcamp bubble” has to do with this. Did the common denominator for “junior” become lower (or maybe just different) during this time?

                          Caveat: I went through one of those bootcamps and used it to start my business, but my (modest) success right now is much more based on my domain-related knowledge/experience/network and not my web dev ability. I’m not trying to crap on bootcamps (clearly), but I have a hunch this may have contributed to it.

                          1. 5

                            There’s also the thing where programming was/is seen as a hot job, mostly because it’s one of the few jobs adults haven’t figured out how to completely ruin yet.

                          2. 4

                            I’m pretty sure it’s just a correction to the glut of entry level hires produced in the last 4 years. When I was in college and grad school, software jobs were rare and not really seen as lucrative (well, not any more so than more respectable/traditional engineering jobs such as hardware/silicon). With the boom in tech companies’ hiring, colleges and boot camps responded by flooding the market with entry level talent. Now the rate at which juniors are being produced is more than there are spots in the industry. Eventually “word” will spread about how hard it is to land an entry level programming job, and fewer students will go into software.

                            1. 1

                              The butler did it.