14 ms·

Companies need junior devs

130 points by softwaredoug 2y ago

DataDaemon 2y ago
Not anymore, thank you, Cursor.
- drdaeman 2y ago
  LLMs don't replace developers. The difference is that a junior can reason, while a LLM fundamentally can't (although they can mimic reason by parroting, and sometimes do it really well). LLMs are good aide for developers of all skill levels, capable of giving them ready answers to near-textbook questions (which juniors may not know and more senior folks may be just lazy to type).
  - xxs 2y ago
    >LLMs are good aide for developers of all skill levels My experience is: at high skill levels it's harmful, so I'd disagree with 'all skill levels'.
    - rf15 2y ago
      My experience was the opposite: don't let the junior devs use AI, or they learn all kinds of bad habits (including relying on AI). A senior on the other hand might just get a good autocomplete.
    - kroolik 2y ago
      High level devs still do low expertise things every now and then. Or rather, designs need to be implemented, eventually.
    - drdaeman 2y ago
      How so? I treat LLMs just as a fancier keyboard for near-boilerplate. When I give a prompt I know what I want them to output, cycle completions until I get a snippet that looks close enough to my liking, then edit it to fit. Super helpful. Another use case was learning a language and SDKs I've never even dabbled with before (Swift and WatchKit). It generated awful architecture (that I think even a junior developer would realize as stinky) and it had limited knowledge about recent Swift language features (async), but gave me just-good-enough samples to get me started - better than a book could have. Can't say I learned Swift that way (didn't need to) but I made a tiny WatchOS app for personal use over in a single evening because LLM gave me a good boost. And then, LLMs can be just a better autocompleters - it feels nice when you get all arguments correctly listed before you even type the first letter, because LLM had guessed it right from the names (it doesn't always happen, of course). I can imagine that being too lazy and just blindly accepting LLM completions without thinking or double-checking can be a bad habit, but that sounds more like a risk for a junior than a senior.
  - supriyo-biswas 2y ago
    > LLMs are good aide for developers of all skill levels If you’re writing usual CRUD-type applications, that is. Anything more complex, and these LLMs will make something up that looks very close to what you want, but will have subtle bugs in it that’ll take a lot of time to figure out. Some time ago what I was working on was a “textbook” question (as you say) involving binary tree and sets as part of a firewall management script I was writing; and I eagerly accepting that code completion that seemingly looked right caused a lot of traffic to be unintentionally blocked.
    - drdaeman 2y ago
      > Anything more complex For sure, LLMs aren't good at designing things, so accepting large pieces of code is not just risky of having subtle bugs but more likely that it's not going to work at all. But anything complex is made of simple bits, and LLM helps with those small building blocks, realizing the patterns you're following and saving time typing. Figuratively speaking, a LLM won't write you a working DOOM engine, but it can spot when you're going for that fast inverse square root trick. > I eagerly accepting that code completion that seemingly looked right And of course one must proofread, and do it carefully. However, reading is faster than typing - especially when one already knows what they wanted to type, and got a code snippet autocompleted that looks precisely or very closely to it. And, yes, If a snippet looks even slightly different from your vision - it's really important to double-check it (and maybe write a test) and make sure it does the right thing. Subtle bugs are possible (I also had one story like that, when LLM put a wrong variable in one place and I glanced over it without noticing), but they're not that frequent and they're also possible in 100% handcrafted code. LLMs are for the boilerplate.
  - DataDaemon 2y ago
    I have great doubts about juniors' reasoning. Before, seniors asked juniors to write, get sets from the database, loops, if statements, APIs, simple interfaces, and maybe basic regex. Not anymore. LLMS is just right now replacing juniors. Thank you for all the minuses. Solution for juniors? Learn how to use LLMS quickly or go to the construction industry.
dartos 2y ago
> Generalists (juniors) often innovate better than specialists 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.
- softwaredoug 2y ago
  In the context of your company, I think the dichotomy holds. A senior dev is a specialist in your company, a junior often has pretty broad skills that apply across companies.
  - 383toast 2y ago
    I don't see why a senior dev does not have broad skills that apply across companies?
    - bluGill 2y ago
      You will have specific skills related to your industry. There are weird issues in every niche that you build up as you spend time in that niche. Senior devs from outside almost always don't have that.
    - ang_cire 2y ago
      I think the rule is more that a senior dev will have picked up specialized knowledge that they themselves will target in their job applications, because specialized knowledge positions pay more. So while they may also have the generic skills that could get them hired into an unspecialized role, they're likely not applying for those.
      - mystified5016 2y ago
        You're just repeating the same assertion that senior devs are specialists, which is not true. Not all generalists choose to, or even can specialize. They don't cease to exist once they've accrued enough experience. Nor does having a lot of experience mean you're specialized in any one thing. You can be senior, have loads of experience, and still be a generalist.
drdaeman 2y ago
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/ https://nvp85.net/
ramijames 2y ago
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.
- le-mark 2y ago
  > 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.
  - almd 2y ago
    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 In short don’t sweat it
  - ramijames 2y ago
    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?
- robjan 2y ago
  I find seniors more stable and juniors more jumpy to be honest.
TrackerFF 2y ago
Everyone wants senior devs, but no one wants to create senior devs. Dunno how that is going to work out.
- _dark_matter_ 2y ago
  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.
  - xyproto 2y ago
    Not everyone wants to become a manager, though.
    - spiralpolitik 2y ago
      To get anywhere beyond senior engineer you'll need to be able to explain and convince people that your idea is solid. The best way to learn these skills is to mentor and interact with junior engineers. The further you go beyond senior engineer, the wider the audience, but you start developing the skills at the 1-1 level.
  - xboxnolifes 2y ago
    What does this even mean?
- xxs 2y ago
  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.
- ballenf 2y ago
  Seniors get more and more expensive until the work gets offshored or companies give in and hire less experienced.
rvense 2y ago
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.
- grumpy_coder 2y ago
  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%)
  - theshrike79 2y ago
    1 year of experience 4 times vs 4 years of experience
    - rvense 2y ago
      Yarh, I thought about this a lot when recently our electric cargo bike passed 10.000 kilometers. It is used, almost exclusively, to bring our son to school, 5km away.
  - f1shy 2y ago
    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
- gavmor 2y ago
  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".
simonsarris 2y ago
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. I wrote a bit about our process here: https://simonsarris.com/p/growing-software-developers https://simonsarris.com/p/growing-software-developers
- bluGill 2y ago
  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.
- pylua 2y ago
  You have to be careful with this. It could be discriminatory.
  - dragonwriter 2y ago
    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.
    - Arainach 2y ago
      Age is in fact a protected class, and if their intent is to only hire high schoolers that would run afoul of the rules.
dgunay 2y ago
I'm finding it nearly impossible to push for this at my workplace as a senior dev. There's perpetually so much fear around a junior hire not being effective and burning too much of our runway. I want to be part of the solution to this industry-wide problem; it pains me to see people I'm mentoring struggle to break into the industry now after I got a new lease on life from a few key folks deciding to give me an opportunity as an unproven dev. The ladder is being pulled up, but I don't know how to help push it back down without career changing into leadership.
- lll-o-lll 2y ago
  Only senior leadership can change this. The best you can do is either get into that position yourself, or influence those that are there. I’m fortunate to work at a company that has this infused from high school -> university -> fresh grads, but this is an intentional activity coming from the CEO down. It’s a form of investment, and needs to be viewed as such.
EB66 2y ago
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.
- softwaredoug 2y ago
  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.
phendrenad2 2y ago
Hire good junior developers (meaning: smart but lack knowledge), give them challenging tasks but tell them it's okay if they need help, give them infinite time with the senior developers, ask them to demo their projects, pay attention to parts they tell you are "too hard" and simplify those parts of your stack. You'll be mega-successful. Everyone else thinks junior devs are replaceable with AI but that's stupid.
jmward01 2y ago
I think a big missing point is Junior people force an org to write better, more obvious, code and more durable systems in general. "If you can't explain it to a 5 year old..." applies here. The other major missing point is that the industry needs to grow the next generation to be healthy. If your company really will be the Next Big Thing then not having a talent pipeline will be a huge problem later on.
383toast 2y ago
False dichotomy, it is possible to have a team of seniors that have a culture of sharing knowledge/open to feedback with no juniors though.
marcinzm 2y ago
> Generalists often innovate better than specialists So hire generalist seniors? They exist. Sounds like the author wants to patch a broken hiring system (only specialists get hired as seniors) by throwing juniors at it. Throwing juniors is a time-honored solution to many problems but while it tends to be somewhat viable and quick to implement it's also a sub-optimal solution.
alphazard 2y ago
Of course this comes down to what you consider "junior" and the particulars of your company. Only the largest organizations with stable income can afford to teach people how to do their job. That's not a sensible path for any business burning runway. There are plenty of recent grads out there who already know how to build software, will work for cheap, and will grow faster than the business increases their salary. That has historically been the selling point for "junior" devs. The opposite is true of hiring senior devs. Many of them will not have learned enough to justify the premium that they demand in the market. They entered the workforce sooner, but that's about it. Like "value investing" this is "value hiring", go long on people who are undervalued by the market, go short on people who are overvalued by the market. This is what the best hiring managers do.
- heavenlyblue 2y ago
  > The opposite is true of hiring senior devs. Many of them will not have learned enough to justify the premium that they demand in the market. They entered the workforce sooner, but that's about it. Senior dev is about skill mot time in industry
- ang_cire 2y ago
  > Only the largest organizations with stable income can afford to teach people how to do their job. Sure, you can't take someone who's never programmed anything before and train them on the job in a startup... but you can't do that in a large company either. But every company has small tasks and spikes that they can hand to junior employees. If not, the startup is probably not breaking down the work very efficiently. My first job as an engineer, I joined a mid-sized startup with around 150 people. My team had 8 people including me. I was very much a junior engineer (if not entry-level for that role) at that time, but I was given tasks that fit my experience level, as well as leeway to branch out into more challenging projects. Moved from junior role to mid-level, and then on to senior (7+ years later, of course). That company had very low turnover, because people saw the company investing in their growth (and I don't mean paying for training, I mean actively nurturing their skills in their work). Companies who want to hire only mid-level workers or up will likely find the mid-levels bogged down with all the little tasks that junior workers could be handling for them. That makes the mid-levels less productive, which is the worse thing for a startup to be.
elawler24 2y ago
At larger orgs who already have a functional business, yes. Running a 0-1 startup is different. There's barely enough time for senior engineers (usually founders) to build core infrastructure and product - let alone document, onboard, and mentor junior devs. Agencies and consultancies the best places to learn as a junior IC. Reviews, process, and management are built in and there's a ton of variety. You also get opportunities to try a bunch of different hats before deciding where to specialize.
- danjl 2y ago
  Absolutely. Startups should not hire junior engineers. They don't have time to teach people until they are a functioning profitable business. However, I would not encourage learning at an agency or consulting service. The best place to learn by far is at a large corporate company, where you have the time to learn good programming practices, and people to teach you how to do it well. The problem with consulting is that you're always working on a short-term issue, and never learn the value of writing good code for long-term support.
  - lll-o-lll 2y ago
    Large corporate will teach you good practices. What it won’t teach you is how to design and build anything, as that will be the purview of seniors and up. I think the best path for someone starting out is a year or two in a big corporate, then move to something small where you get to do everything. Of course, this seems like a bad thing for big corporates, so they should probably work out how to give devs a better path through their own companies.
SoftTalker 2y ago
When did the word "junior" start appearing in job titles? It's slightly demeaning. When I started out, entry level was called "Staff" and then "Senior" was above that. Above Senior you had at least one foot in management, titles were maybe "Lead" or various manager/director titles.
- robjan 2y ago
  In every company I have worked at, Staff is ranked higher than Senior. Junior roles are usually titled "Associate Engineer" to avoid the term "Junior"
_glass 2y ago
Junior's are so fast seniors nowadays, at least in my world of management systems, e.g., Salesforce, SAP. One year, and they are senior. But it takes courage and guidance from the company. I think it is a real weakness to concentrate on losing out on the young devs, that have a new perspective on things. Also it is quite hard to get good senior people, but someone really good fresh out of college is quite easy to hire.
jmclnx 2y ago
>Junior Talent forces your team to teach, coach, collaborate Plus you may learn something. A couple of bright Junior Developers showed me some nice tricks I was uaware of.
jt2190 2y ago
> Junior Talent forces your team to teach, coach, collaborate Then we’re going about it all wrong, and shouldn’t have “senior” devs hiring “junior” devs but “teacher” devs hiring “student” devs. And when I say “student” I mean someone who is willing to go through the pain of not knowing, who will keep an open mind and give new things a try. And when I say “teacher” I mean someone who will study teaching to the same level that they study tech, who will be patient and empathetic. But this is not how most companies operate, nor is it how most people want to work. Consider promotions for example: Juniors are highly incentivized to work independently to become seniors. And seniors compete with each other to have their solutions adopted, rather than agree to explore a new approach and reevaluate if necessary.
snovymgodym 2y ago
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.
giancarlostoro 2y ago
If you want a good team make sure everyone gets along as a #1. Keeping around some insane genius nobody can work with is a net negative. People who are not humble enough to say when they hit a limit (but know that there's always a solution) are a red flag depending. You need people mature enough to acknowledge that their code is the problem, not everyone else and their code. Soft skills is more important than developer skills in my eyes, but not the only requirement. For Juniors, its probably the highest, followed by an ability to learn and adapt to new technology.
jay-barronville 2y ago
I don’t think I’ve ever seen an argument promoting junior engineers so well articulated. Upvoted! I fully agree with the author’s sentiment. Many companies see junior engineers as burdens who’ll suck up valuable time and resources of the company and their senior colleagues, and completely miss the point that junior engineers bring some invaluable but intangible benefits to a team. Sometimes, it’s the junior eyes who’ll notice something those of us who can be a bit stuck in our ways wouldn’t immediately notice. This youthful energy is the same reason why a lot of startups can enter markets already dominated by huge, experienced, and well-resourced players, and start eating their lunch. The best and most underrated value I think a team gets from junior engineers—which the author highlights—is learning how to break down and explain things. The ability to collaborate and teach is something many folks may underestimate until you end up in an environment that sucks at both. That said, it’s probably not ideal to bring junior engineers into an environment that’s not prepared to deal with them. You need to be prepared to really invest in them and their success to see the true value they can bring to your team.
kkfx 2y ago
Mh... Acknowledging that generalists are more innovative than specialist, since they see the big picture, and prizing junior devs seems to be a bit an oxymoron. Surely a junior typically want to learn, so he/she explore the world, without much prejudices, but hardly have "the big picture" in mind especially current junior devs out of a schooling system who forge at best useful idiots[1] not fresh and curious people. Personally my take is that company need a different architecture with NO MANAGEMENT AT THE TOP, meaning companies must be driven by entrepreneurs not beancounters, and technicians must be at the same level of managers because anyone have only a partial vision and the entrepreneur do the synthesis. [1] https://www.theatlantic.com/ideas/archive/2020/08/i-was-useful-idiot-capitalism/615031/ https://www.theatlantic.com/ideas/archive/2020/08/i-was-usef...

130 points by softwaredoug 2y ago

DataDaemon 2y ago

Not anymore, thank you, Cursor.

drdaeman 2y ago
LLMs don't replace developers. The difference is that a junior can reason, while a LLM fundamentally can't (although they can mimic reason by parroting, and sometimes do it really well). LLMs are good aide for developers of all skill levels, capable of giving them ready answers to near-textbook questions (which juniors may not know and more senior folks may be just lazy to type).
- xxs 2y ago
  >LLMs are good aide for developers of all skill levels My experience is: at high skill levels it's harmful, so I'd disagree with 'all skill levels'.
  - rf15 2y ago
    My experience was the opposite: don't let the junior devs use AI, or they learn all kinds of bad habits (including relying on AI). A senior on the other hand might just get a good autocomplete.
  - kroolik 2y ago
    High level devs still do low expertise things every now and then. Or rather, designs need to be implemented, eventually.
  - drdaeman 2y ago
    How so? I treat LLMs just as a fancier keyboard for near-boilerplate. When I give a prompt I know what I want them to output, cycle completions until I get a snippet that looks close enough to my liking, then edit it to fit. Super helpful. Another use case was learning a language and SDKs I've never even dabbled with before (Swift and WatchKit). It generated awful architecture (that I think even a junior developer would realize as stinky) and it had limited knowledge about recent Swift language features (async), but gave me just-good-enough samples to get me started - better than a book could have. Can't say I learned Swift that way (didn't need to) but I made a tiny WatchOS app for personal use over in a single evening because LLM gave me a good boost. And then, LLMs can be just a better autocompleters - it feels nice when you get all arguments correctly listed before you even type the first letter, because LLM had guessed it right from the names (it doesn't always happen, of course). I can imagine that being too lazy and just blindly accepting LLM completions without thinking or double-checking can be a bad habit, but that sounds more like a risk for a junior than a senior.
- supriyo-biswas 2y ago
  > LLMs are good aide for developers of all skill levels If you’re writing usual CRUD-type applications, that is. Anything more complex, and these LLMs will make something up that looks very close to what you want, but will have subtle bugs in it that’ll take a lot of time to figure out. Some time ago what I was working on was a “textbook” question (as you say) involving binary tree and sets as part of a firewall management script I was writing; and I eagerly accepting that code completion that seemingly looked right caused a lot of traffic to be unintentionally blocked.
  - drdaeman 2y ago
    > Anything more complex For sure, LLMs aren't good at designing things, so accepting large pieces of code is not just risky of having subtle bugs but more likely that it's not going to work at all. But anything complex is made of simple bits, and LLM helps with those small building blocks, realizing the patterns you're following and saving time typing. Figuratively speaking, a LLM won't write you a working DOOM engine, but it can spot when you're going for that fast inverse square root trick. > I eagerly accepting that code completion that seemingly looked right And of course one must proofread, and do it carefully. However, reading is faster than typing - especially when one already knows what they wanted to type, and got a code snippet autocompleted that looks precisely or very closely to it. And, yes, If a snippet looks even slightly different from your vision - it's really important to double-check it (and maybe write a test) and make sure it does the right thing. Subtle bugs are possible (I also had one story like that, when LLM put a wrong variable in one place and I glanced over it without noticing), but they're not that frequent and they're also possible in 100% handcrafted code. LLMs are for the boilerplate.
- DataDaemon 2y ago
  I have great doubts about juniors' reasoning. Before, seniors asked juniors to write, get sets from the database, loops, if statements, APIs, simple interfaces, and maybe basic regex. Not anymore. LLMS is just right now replacing juniors. Thank you for all the minuses. Solution for juniors? Learn how to use LLMS quickly or go to the construction industry.

dartos 2y ago

> Generalists (juniors) often innovate better than specialists 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.

softwaredoug 2y ago
In the context of your company, I think the dichotomy holds. A senior dev is a specialist in your company, a junior often has pretty broad skills that apply across companies.
- 383toast 2y ago
  I don't see why a senior dev does not have broad skills that apply across companies?
  - bluGill 2y ago
    You will have specific skills related to your industry. There are weird issues in every niche that you build up as you spend time in that niche. Senior devs from outside almost always don't have that.
  - ang_cire 2y ago
    I think the rule is more that a senior dev will have picked up specialized knowledge that they themselves will target in their job applications, because specialized knowledge positions pay more. So while they may also have the generic skills that could get them hired into an unspecialized role, they're likely not applying for those.
    - mystified5016 2y ago
      You're just repeating the same assertion that senior devs are specialists, which is not true. Not all generalists choose to, or even can specialize. They don't cease to exist once they've accrued enough experience. Nor does having a lot of experience mean you're specialized in any one thing. You can be senior, have loads of experience, and still be a generalist.

drdaeman 2y ago

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/ https://nvp85.net/

ramijames 2y ago

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.

le-mark 2y ago
> 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.
- almd 2y ago
  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 In short don’t sweat it
- ramijames 2y ago
  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?
robjan 2y ago
I find seniors more stable and juniors more jumpy to be honest.

TrackerFF 2y ago

Everyone wants senior devs, but no one wants to create senior devs. Dunno how that is going to work out.

_dark_matter_ 2y ago
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.
- xyproto 2y ago
  Not everyone wants to become a manager, though.
  - spiralpolitik 2y ago
    To get anywhere beyond senior engineer you'll need to be able to explain and convince people that your idea is solid. The best way to learn these skills is to mentor and interact with junior engineers. The further you go beyond senior engineer, the wider the audience, but you start developing the skills at the 1-1 level.
- xboxnolifes 2y ago
  What does this even mean?
xxs 2y ago
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.
ballenf 2y ago
Seniors get more and more expensive until the work gets offshored or companies give in and hire less experienced.

rvense 2y ago

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.

grumpy_coder 2y ago
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%)
- theshrike79 2y ago
  1 year of experience 4 times vs 4 years of experience
  - rvense 2y ago
    Yarh, I thought about this a lot when recently our electric cargo bike passed 10.000 kilometers. It is used, almost exclusively, to bring our son to school, 5km away.
- f1shy 2y ago
  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
gavmor 2y ago
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".

simonsarris 2y ago

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. I wrote a bit about our process here: https://simonsarris.com/p/growing-software-developers https://simonsarris.com/p/growing-software-developers

bluGill 2y ago
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.
pylua 2y ago
You have to be careful with this. It could be discriminatory.
- dragonwriter 2y ago
  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.
  - Arainach 2y ago
    Age is in fact a protected class, and if their intent is to only hire high schoolers that would run afoul of the rules.

dgunay 2y ago

I'm finding it nearly impossible to push for this at my workplace as a senior dev. There's perpetually so much fear around a junior hire not being effective and burning too much of our runway. I want to be part of the solution to this industry-wide problem; it pains me to see people I'm mentoring struggle to break into the industry now after I got a new lease on life from a few key folks deciding to give me an opportunity as an unproven dev. The ladder is being pulled up, but I don't know how to help push it back down without career changing into leadership.

lll-o-lll 2y ago
Only senior leadership can change this. The best you can do is either get into that position yourself, or influence those that are there. I’m fortunate to work at a company that has this infused from high school -> university -> fresh grads, but this is an intentional activity coming from the CEO down. It’s a form of investment, and needs to be viewed as such.

EB66 2y ago

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.

softwaredoug 2y ago
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.

phendrenad2 2y ago

Hire good junior developers (meaning: smart but lack knowledge), give them challenging tasks but tell them it's okay if they need help, give them infinite time with the senior developers, ask them to demo their projects, pay attention to parts they tell you are "too hard" and simplify those parts of your stack. You'll be mega-successful. Everyone else thinks junior devs are replaceable with AI but that's stupid.

jmward01 2y ago

I think a big missing point is Junior people force an org to write better, more obvious, code and more durable systems in general. "If you can't explain it to a 5 year old..." applies here. The other major missing point is that the industry needs to grow the next generation to be healthy. If your company really will be the Next Big Thing then not having a talent pipeline will be a huge problem later on.

383toast 2y ago

False dichotomy, it is possible to have a team of seniors that have a culture of sharing knowledge/open to feedback with no juniors though.

marcinzm 2y ago

> Generalists often innovate better than specialists So hire generalist seniors? They exist. Sounds like the author wants to patch a broken hiring system (only specialists get hired as seniors) by throwing juniors at it. Throwing juniors is a time-honored solution to many problems but while it tends to be somewhat viable and quick to implement it's also a sub-optimal solution.

alphazard 2y ago

Of course this comes down to what you consider "junior" and the particulars of your company. Only the largest organizations with stable income can afford to teach people how to do their job. That's not a sensible path for any business burning runway. There are plenty of recent grads out there who already know how to build software, will work for cheap, and will grow faster than the business increases their salary. That has historically been the selling point for "junior" devs. The opposite is true of hiring senior devs. Many of them will not have learned enough to justify the premium that they demand in the market. They entered the workforce sooner, but that's about it. Like "value investing" this is "value hiring", go long on people who are undervalued by the market, go short on people who are overvalued by the market. This is what the best hiring managers do.

heavenlyblue 2y ago
> The opposite is true of hiring senior devs. Many of them will not have learned enough to justify the premium that they demand in the market. They entered the workforce sooner, but that's about it. Senior dev is about skill mot time in industry
ang_cire 2y ago
> Only the largest organizations with stable income can afford to teach people how to do their job. Sure, you can't take someone who's never programmed anything before and train them on the job in a startup... but you can't do that in a large company either. But every company has small tasks and spikes that they can hand to junior employees. If not, the startup is probably not breaking down the work very efficiently. My first job as an engineer, I joined a mid-sized startup with around 150 people. My team had 8 people including me. I was very much a junior engineer (if not entry-level for that role) at that time, but I was given tasks that fit my experience level, as well as leeway to branch out into more challenging projects. Moved from junior role to mid-level, and then on to senior (7+ years later, of course). That company had very low turnover, because people saw the company investing in their growth (and I don't mean paying for training, I mean actively nurturing their skills in their work). Companies who want to hire only mid-level workers or up will likely find the mid-levels bogged down with all the little tasks that junior workers could be handling for them. That makes the mid-levels less productive, which is the worse thing for a startup to be.

elawler24 2y ago

At larger orgs who already have a functional business, yes. Running a 0-1 startup is different. There's barely enough time for senior engineers (usually founders) to build core infrastructure and product - let alone document, onboard, and mentor junior devs. Agencies and consultancies the best places to learn as a junior IC. Reviews, process, and management are built in and there's a ton of variety. You also get opportunities to try a bunch of different hats before deciding where to specialize.

danjl 2y ago
Absolutely. Startups should not hire junior engineers. They don't have time to teach people until they are a functioning profitable business. However, I would not encourage learning at an agency or consulting service. The best place to learn by far is at a large corporate company, where you have the time to learn good programming practices, and people to teach you how to do it well. The problem with consulting is that you're always working on a short-term issue, and never learn the value of writing good code for long-term support.
- lll-o-lll 2y ago
  Large corporate will teach you good practices. What it won’t teach you is how to design and build anything, as that will be the purview of seniors and up. I think the best path for someone starting out is a year or two in a big corporate, then move to something small where you get to do everything. Of course, this seems like a bad thing for big corporates, so they should probably work out how to give devs a better path through their own companies.

SoftTalker 2y ago

When did the word "junior" start appearing in job titles? It's slightly demeaning. When I started out, entry level was called "Staff" and then "Senior" was above that. Above Senior you had at least one foot in management, titles were maybe "Lead" or various manager/director titles.

robjan 2y ago
In every company I have worked at, Staff is ranked higher than Senior. Junior roles are usually titled "Associate Engineer" to avoid the term "Junior"

_glass 2y ago

Junior's are so fast seniors nowadays, at least in my world of management systems, e.g., Salesforce, SAP. One year, and they are senior. But it takes courage and guidance from the company. I think it is a real weakness to concentrate on losing out on the young devs, that have a new perspective on things. Also it is quite hard to get good senior people, but someone really good fresh out of college is quite easy to hire.

jmclnx 2y ago

>Junior Talent forces your team to teach, coach, collaborate Plus you may learn something. A couple of bright Junior Developers showed me some nice tricks I was uaware of.

jt2190 2y ago

> Junior Talent forces your team to teach, coach, collaborate Then we’re going about it all wrong, and shouldn’t have “senior” devs hiring “junior” devs but “teacher” devs hiring “student” devs. And when I say “student” I mean someone who is willing to go through the pain of not knowing, who will keep an open mind and give new things a try. And when I say “teacher” I mean someone who will study teaching to the same level that they study tech, who will be patient and empathetic. But this is not how most companies operate, nor is it how most people want to work. Consider promotions for example: Juniors are highly incentivized to work independently to become seniors. And seniors compete with each other to have their solutions adopted, rather than agree to explore a new approach and reevaluate if necessary.

snovymgodym 2y ago

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.

giancarlostoro 2y ago

If you want a good team make sure everyone gets along as a #1. Keeping around some insane genius nobody can work with is a net negative. People who are not humble enough to say when they hit a limit (but know that there's always a solution) are a red flag depending. You need people mature enough to acknowledge that their code is the problem, not everyone else and their code. Soft skills is more important than developer skills in my eyes, but not the only requirement. For Juniors, its probably the highest, followed by an ability to learn and adapt to new technology.

jay-barronville 2y ago

I don’t think I’ve ever seen an argument promoting junior engineers so well articulated. Upvoted! I fully agree with the author’s sentiment. Many companies see junior engineers as burdens who’ll suck up valuable time and resources of the company and their senior colleagues, and completely miss the point that junior engineers bring some invaluable but intangible benefits to a team. Sometimes, it’s the junior eyes who’ll notice something those of us who can be a bit stuck in our ways wouldn’t immediately notice. This youthful energy is the same reason why a lot of startups can enter markets already dominated by huge, experienced, and well-resourced players, and start eating their lunch. The best and most underrated value I think a team gets from junior engineers—which the author highlights—is learning how to break down and explain things. The ability to collaborate and teach is something many folks may underestimate until you end up in an environment that sucks at both. That said, it’s probably not ideal to bring junior engineers into an environment that’s not prepared to deal with them. You need to be prepared to really invest in them and their success to see the true value they can bring to your team.

kkfx 2y ago

Mh... Acknowledging that generalists are more innovative than specialist, since they see the big picture, and prizing junior devs seems to be a bit an oxymoron. Surely a junior typically want to learn, so he/she explore the world, without much prejudices, but hardly have "the big picture" in mind especially current junior devs out of a schooling system who forge at best useful idiots[1] not fresh and curious people. Personally my take is that company need a different architecture with NO MANAGEMENT AT THE TOP, meaning companies must be driven by entrepreneurs not beancounters, and technicians must be at the same level of managers because anyone have only a partial vision and the entrepreneur do the synthesis. [1] https://www.theatlantic.com/ideas/archive/2020/08/i-was-useful-idiot-capitalism/615031/ https://www.theatlantic.com/ideas/archive/2020/08/i-was-usef...