13 ms·

> we don’t hire junior developers because we can’t afford to have our senior developers mentor them. That feels too dumb to be real (which is exactly why it's

• giancarlostoro 9y ago
  Sounds like senior devs who can't even do teamwork. At my job I'm a junior and guess what I can ask a senior for help cause if my job fails they also fail because oh guess what? Its a team and we are all on the same boat and wait it gets better! I end up spending my own time helping out senior developers in places they get stuck! (Inconceivable!) Yeah sounds like a management team and a bunch of senior devs who have no concept of a team to me?... Which makes them no-hire types at my job. I help people regardless of what they're working on. If any of us fails it affects all of us in the long run. I love programming and helping others achieve it and working with others to learn is one of the better and more fun parts of it.
  • thepratt 9y ago
    Completely agree, it should always be team first.
    • giancarlostoro 9y ago
      Now I will admit there are exceptions, if helping a junior (or senior : ) takes up your whole day (aside from just helping them get things up and running the first time) unless told to help them 'get it done' by upper management you might want to back off and let them get burned a little bit while you get your own work done.
      • WalterSear 9y ago
        That's still team first, tbh. Team over your teammate.
  • sfpwork 9y ago
    When I was a jr I could not understand how other engineers, jr or especially sr, did not share this passion for helping and learning. Over the years (decades now) I came to accept that even in software development there are all these different types of people. I learned to not get upset by it but still help/share, trying to inspire others and always learning more in this process.
  • megaman22 9y ago
    On the other hand, you have the schmucks that ask the same questions over and iver, make the same mistakes, over and over, and are utterly helpless without their hand being held. It's a spectrum. My suspicion is that anyone my age or older had to do a lot of banging their heads against the wall, alone in a room with the machine, when they were learning their craft. It becomes very tiresome dealing with people that don't even try to figure things out on their own first.
• zemanel 9y ago
  In my current job, for a tech company with less than 12 people, at least 5 are interns. Two of them were recent hires (January) and before they were onboarded, i had a meeting with my boss and the other senior developer regarding the new interns and my boss stated he didn’t want me and other senior dev spending too much time mentoring the interns and that if they couldn’t manage by themselves, he would just let them go (one is software dev intern, relocated from Lithuania). As far as i know, management provided zero training (online courses, conferences, books etc) and the dev intern is receiving 500€/month for 40h work week, which around Amsterdam/Netherlands hardly covers housing expenses in shared accommodation, even though the intern is soon expecting Erasmus support, which will alleviate his situation apparently. Needless to say i find the situation rather vile independently if it’s a common practice or even if non-paid internships are common. Recently i took the dev intern out for dinner and beers, gave him a few tips on how to improve himself to be ready for a decent job (online courses, writing blog posts etc) and told him he could repay me by paying forward to an intern at his next proper jobs. As a note, another intern (part time) is also working on his maybe 5 years old laptop that apparently crashes a lot and can hardly run something like Pycharm. I’m looking for another job :-)
  • expertentipp 9y ago
    He is being paid with generous social security net (for which he doesn’t necessarily qualify) and with the priviledge of living in developed country with extensive infrastructure... /s
    • jjkk0101 9y ago
      I understand your sarcasm, but what is sad some people actually think this way.
  • thepratt 9y ago
    Is there no room to fight management or make them understand?
    • zemanel 9y ago
• dalbasal 9y ago
  The problem I've seen with mentoring, in practice, is the 1 in 3 juniors that takes up all the time. Maybe the particular job doesn't suit them. Maybe they shouldn't be a dev. Maybe it's personality. Some managers, mentors or such seem to deal with this well. But, in the cases that I've seen having an employee that is not producing value is stressful and time consuming. Largely, it's driven by empathy. You don't want them to get fired, or embarrassed. Anyway, the person taking up most mentoring time (including:'leave this part, I'll fix it) is also producing the least of the least important stuff. The best juniors can be left to their devices and everything is ok, but basically the time and effort allocation becomes very inefficient. Mentoring is important, but I disagree with you somewhat. Software is just an ADD industry. Everything is fast. You hire for needs in the next 12 months. Junior devs (all devs, some places) average short stints. Anyway, mentiring, training and such are long term investments. Makes less sense in industry segments that think in shorter horizons and treat everything from office space to employees or even products as 1-2 year solutions. Entire companies are built around 3-6 year horizons from cenception to exit. I see this as a byproduct of product development time. MVP and its associated stuff... It's all about short horizons, clean slates and short term planning. Nothing is free and the cost of this is anything that's part of long term strategy, like hiring and training for long term benefit.
  • virgilp 9y ago
    > You hire for needs in the next 12 months. That's like, your opinion, man. Why can't you hire long-term? If all you plan for is short-term, it will only work short-term, and it should be no surprise if on the longer term you fail or you find yourself in a world of pain. > I see this as a byproduct of product development time. MVP and its associated stuff... It's all about short horizons, I think you severely misunderstand MVP... it's not at all about short horizons, on the contrary. It's about doing the right thing in the longer term. To put "MVP" in a hiring context - the right "MVP" attitude is to hire temporarily to see whether the person is right for the job - and once you determine you've got a good fit, invest massively in that person to make sure you've got a long-term employee (don't just skim him/her for short-term profit, but invest to build a long-lasting relationship). > Entire companies are built around 3-6 year horizons from cenception to exit. I've yet to see that work (and not in the sense that "lottery works" - nobody seriously suggests buying lots of lottery tickets if you want to get rich.
• friendzis 9y ago
  Actually, the cost of mentoring is not necessarily only cost of lost productivity. Sometimes (I hope, more likely mostly) there are pieces of old, arcane, barely and wrongly documented pieces of codebase that there is exactly one senior in the company who knows how it works. Assigning said senior from coding literally means pushing deadlines. So it is kind of tragedy of the commons.
  • swiley 9y ago
    One of the good reasons to have junior devs around is that (if they're motivated) they'll find holes in the documentation and help prevent this. I usually write many pages of text to document problems and unwritten ideas at my internships.
  • tixocloud 9y ago
    This is probably the biggest difference between companies who excel and those who don't. Some companies get that employees are assets and training them is worth it even if they might leave.
  • virgilp 9y ago
    That's like, a great motivation to assign said senior AWAY from coding! "Single points of failures" are your greatest enemy, your senior my get a better offer. Or might get sick. Or might get in a car accident. Why would you want to bet your entire company on a single person? I mean... sometimes you have to do it because there's no other way, but it's a big warning sign, and you should diligently work to get out of that situation ASAP. "Pushing deadlines" might very well be a price worth paying in a situation like that.
• g051051 9y ago
  > good junior devs can code not only "just as fast", but probably faster too! Pfft. I'm about as "senior" as it gets and I'm generally the fastest developer in any team I'm on. I've never met a junior dev that could hold a candle to me, and most senior devs I know are the same...we're coding monsters.
  • darkerside 9y ago
    > I'm about as "senior" as it gets Senior developers make sure to question their assumptions on a regular basis, FYI
  • moreless 9y ago
    True. But the team as a whole would probably still achieve much more if you were mostly guiding other (less experienced) devs.
    • g051051 9y ago
      I do. But I'm still faster than them in head to head coding throughput (code produced, error counts, etc). I've got decades of experience in developing software. No way someone fresh out of college is going to equal, let alone out-code me. That's not to say they're not good, but the assertion: > can code not only "just as fast", but probably faster too! is pure BS.
      • virgilp 9y ago
        I am flabbergasted that you're senior and measure your productivity in "code produced". What is that, LOC? Can type faster than a recent graduate? Good junior devs will be more skilled in some areas than you are. Maybe it's stuff you're not interested in; or just stuff they're really interested in. The only way a good junior dev doesn't "out-code" you, ever - is if you're only skilled in a very narrow niche (bonus points if only few people are interested in it, at all). Junior devs absolutely can, and often do, build "wrong things" faster than senior devs. The measure of seniority is in my mind about knowing what to NOT build, in the first place.
• nkrisc 9y ago
  As a non-developer who works directly with devs, I've always thought this: I've heard that being a dev is 90% thinking about code and 10% writing it. In my experience you hire senior devs to do the thinking part and junior devs to do the writing part while learning how to do the thinking part.
  • kbwt 9y ago
    The communication ends up being such a bottleneck that your senior devs might as well do the 10% writing. Incidentally also the reason why outsourcing software doesn't work if you're trying to do anything innovative.
  • mywittyname 9y ago
    Hiring devs to just think is part of what creates these convoluted mess of systems. It's impossible to convey and idea well enough that another person could implement it in the same fashion. Look at language specifications: they are written by top-tier developers, but when implemented by other equally top-tier developers, there is an inevitable difference of opinion. Senior developers should be writing code for important systems, and juniors should be writing the less important bits. That way, they get the opportunity to experiment without the company being stuck with a critical system written by a person who reinvented Yet Another Elliptical Wheel. Mentoring is important and all, but at some point, you just have to start working.
• tboyd47 9y ago
  > good junior devs can code not only "just as fast", but probably faster too! For at least 2 companies I've worked at, this is false. Junior devs cannot complete their work at all without help. This may be the real problem: there is no way to learn the skills to do the job without actually getting a job first and learning the skills as you go.
  • DontGiveTwoFlux 9y ago
    But the ‘learning the skills as you go’ part is where the seniors come in. I’ve benefited immensely from the code reviews which took things that technically worked but we’re convoluted and transformed them into code that could be maintained and read easily. Now that I’ve had some mentorship I can be productive on my own, but yeah, it took some work. The senior devs get pulled into meetings, customer escalations, bug reviews, etc. all the time. The juniors, now trained and competent are free to code all day and get the work done because they have fewer responsibilities. Yes, it takes work to get there, but it’s worth the effort.
  • virgilp 9y ago
    Good junior devs are fairly rare, too - I wasn't claiming you find them everywhere.
  • alistairSH 9y ago
    This is where a high quality on-boarding program comes into play. Yes, a dev fresh out of college or code boot camp, with little or no real world experience, is going to be unproductive individually. As the employer/manager, you need to work to minimize the period of time this is the case and ensure those junior devs quickly get to a point where they can work individually. I mentioned it elsewhere in this discussion - we have a 1 month on-boarding program for new devs. They all arrive at the same time (summer after graduation), stay near HQ, and work through all the common training together (some tech, some culture, some "how to be an adult", etc). They also work through a simple, but in-depth (UI, API, build pipeline, etc), group project. And wrap up with a two day hackathon for fun (done in common with the summer interns).
• snarf21 9y ago
  I agree with you and this is the thing that gets lost on both sides. How fast you type and how many lines of code you write and test per day aren't the right metrics. It is about adding value, it isn't an assembly line. There is a major problem with middle/upper management understanding this. However, there is also a large group of people who view themselves as top developers who talk about having too many distractions and wanting a private office so they can lay down a lot of code each day. I'm not saying that isn't how some might be able to add the most value but code/day doesn't guarantee that maximum. Mentoring team members, documenting architecture, building automated tests, talking to customers, etc. will very likely yield more value in everything but the very near term. All this to say that we need to be careful that we don't point the finger too hard at management and miss our own failings. Software done well is incredibly hard and increasingly complex. Focusing on adding value and not on code/day can help us all stay focused on the real goal and what is best for us and the company and the customers. </r>
• commandlinefan 9y ago
  > You hire senior devs to guide you WHAT and HOW to code. Every organization I've worked at (for the past 25 years) has relegated that rule to the much lower prestige, much lower paying, zero career path role of either "business analyst" or "project manager". If you can produce code, you'll be producing code - and by and large, that's the only way to have anything resembling a future unless you're on an upper management track.
• Kalium 9y ago
  A lot of shops view senior devs as the people who write more, better, faster code. Not the people who think about what and how. That's for architectural councils, which meet in misty glades in dark robes at midnight or something.
• 0027 9y ago
  > You don't hire senior devs to code - good junior devs can code not only "just as fast", but probably faster too! I think this is a stereotype that will lead to more harm than good. What if a junior dev doesn't code just as fast or faster? Does that mean we hired the wrong junior dev? I agree we can should be open to junior developers, just implanting this stereotype is harmful
• Fire-Dragon-DoL 9y ago
  I'm not sure what juniors you talk about, but most juniors I've met can code "barely enough", get stuck often and code pretty bad so the pull request will stay there for quite a while before all corrections are applied