Who Killed the Junior Developer?(medium.com)
medium.com
Who Killed the Junior Developer?
https://medium.com/@melissamcewen/who-killed-the-junior-developer-33e9da2dc58c
796 comments
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 :-)
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 :-)
The Netherlands is a special place in Software Hell. Where the non-suits are only a cost.
"Devs can't be cheap enough! We can't find decent devs!"
"Devs can't be cheap enough! We can't find decent devs!"
That's a silly generalization. I've got a pretty good overview of software development in Western Europe and NL isn't a special place for better or worse compared to the surrounding countries.
If you want to get paid a lot more and you have the right skills the City or Silicon Valley are good options (assuming you are allowed to move there).
If you want to get paid a lot more and you have the right skills the City or Silicon Valley are good options (assuming you are allowed to move there).
Perhaps a bit over generalized but I do feel that there’s an unusual large gap in salary between suits and devs even when comparing to countries like Germany.
It doesn’t need to be a huge tech hub at all. Luckily English resembles Dutch so most Dutch speak it well enough to survive a job abroad.
It doesn’t need to be a huge tech hub at all. Luckily English resembles Dutch so most Dutch speak it well enough to survive a job abroad.
The city-to-city variations in Germany are far larger than the city-to-city variations in NL because of the German history and the presence of Poland. So when you are comparing countries you need to go a bit deeper than that.
I know very well paid developers in NL and very poorly paid ones, it is mostly a matter of knowing what you are worth and refusing to charge less than that. You might find 'your spot' taken by a skilled immigrant but that's a relatively small chance.
I'd hate to have to find a developer job in Spain or Portugal judging by the number of people from there that have moved to either NL or DE. Anything East of the German-Polish border is going to pay a lot worse unless you are willing to move to Finland where there are pockets of start-ups with reasonable compensation.
Dutch developers moving abroad to increase their salary is not a trend as far as I can see.
I know very well paid developers in NL and very poorly paid ones, it is mostly a matter of knowing what you are worth and refusing to charge less than that. You might find 'your spot' taken by a skilled immigrant but that's a relatively small chance.
I'd hate to have to find a developer job in Spain or Portugal judging by the number of people from there that have moved to either NL or DE. Anything East of the German-Polish border is going to pay a lot worse unless you are willing to move to Finland where there are pockets of start-ups with reasonable compensation.
Dutch developers moving abroad to increase their salary is not a trend as far as I can see.
Yet across the Polish border developers are relatively well paid versus the suits and it's actually an attractive profession for people that are career oriented. I always see more women working in IT where the job actually pays well, including the US.
I know well paid developers as well, some niches pay pretty well. SAP for example. Or simply people that have domain knowledge that's irreplaceable and know how to negotiate. But something average like C#, RoR or Node development doesn't really pay well in The Netherlands. It's a decent salary but nothing to brag about.
I know well paid developers as well, some niches pay pretty well. SAP for example. Or simply people that have domain knowledge that's irreplaceable and know how to negotiate. But something average like C#, RoR or Node development doesn't really pay well in The Netherlands. It's a decent salary but nothing to brag about.
> Yet across the Polish border developers are relatively well paid versus the suits and it's actually an attractive profession for people that are career oriented
My take on this: it's so easy for Polish developers to move to and find a job in Western Europe, that local companies have to pay salary that provides at least a roughly comparable living standard (vs the West)- as otherwise talented people would just leave. For "suits", on the other hand, there's far less opportunities abroad, so their wages don't need to track Western standards so much.
This effect is even stronger in Ukraine, where a teacher will be paid $300 (per month) while a dev will make $3000.
My take on this: it's so easy for Polish developers to move to and find a job in Western Europe, that local companies have to pay salary that provides at least a roughly comparable living standard (vs the West)- as otherwise talented people would just leave. For "suits", on the other hand, there's far less opportunities abroad, so their wages don't need to track Western standards so much.
This effect is even stronger in Ukraine, where a teacher will be paid $300 (per month) while a dev will make $3000.
Well, if you're an exploited contractor from India or China or a member of a family that already has residence you should have no problem. If you're a well-educated person from the Netherlands you'll never get in - unless you try moving to Canada and use their point system.
As a Netherlander, I agree. There are so many bad developers here, and that's from somebody who considers himself barely able. Also, as a developer you're expected to do lots of unpaid overtime while getting paid the absolute minimum.
STEM "shortage" in a nutshell.
Just want to point out that often the interns will receive additional compensation from their programs. When we hire interns from Erasmus+, they are given 500 euro from us, as well as 500 euro from their program. Additionally, Erasmus students are eligible for student housing from UvA or the VU. Finally, because they are in a special class, as interns, here in NL, we can actually get in trouble with the government for paying them more than 500 euro. It sounds to me like your management team isn't giving them the resources they need to survive in the city, but know that they are there. We have taken on four interns over the past two years, and after their internships placed them at large companies like Trivago and Elsevier, hired one on fulltime, and are working with the last to land a job in his preffered location. With the proper mentorship, it can be a great deal for students! If you are looking for a company where you are expected to mentor the junior devs and interns, send me a DM and we can see if you would be a good fit :)
I have a hard time believing that you will get in trouble for hiring interns and compensate them more than 500 euros. In the NL you aren't even obliged to give them any compensation and if you are compensating them you are free to do so as much as you'd wish.
Internships in the Netherlands are akin to modern slavery imo. You work full time and with luck you get a compensation of 500 euros a month,though often no compensation is more likely to be the case. You will get a maximum loan of 1100 euros a month from the government, so a lot of students have to take on a second job if they don't get any compensation at all at their internship.
National institute of neuroscience provides no compensation whatsoever, and for applied mathematics students the average compensation is around 200 euros.
Obviously not wholly related to your comment but the internship situation in the Netherlands really grinds my gears.
Internships in the Netherlands are akin to modern slavery imo. You work full time and with luck you get a compensation of 500 euros a month,though often no compensation is more likely to be the case. You will get a maximum loan of 1100 euros a month from the government, so a lot of students have to take on a second job if they don't get any compensation at all at their internship.
National institute of neuroscience provides no compensation whatsoever, and for applied mathematics students the average compensation is around 200 euros.
Obviously not wholly related to your comment but the internship situation in the Netherlands really grinds my gears.
Normative answer (in Dutch), I have no practical experience either way: https://www.rijksoverheid.nl/onderwerpen/minimumloon/vraag-e...
Your employer has no obligation to compensate for your internship, but is not prohibited either. There is no minimum or maximum amount set for this compensation.
The focus for internship should be on training, not work. If the Inspectie SZW (employment auditor) finds that the internship consisted of mostly paid work, the employer will be ordered to salary the intern according to normal wages [effectively, minimum wage].
However, there is a practical limit to compensation: students earning more than E20,000 a year are no longer eligible for the student loans you mention.
Your employer has no obligation to compensate for your internship, but is not prohibited either. There is no minimum or maximum amount set for this compensation.
The focus for internship should be on training, not work. If the Inspectie SZW (employment auditor) finds that the internship consisted of mostly paid work, the employer will be ordered to salary the intern according to normal wages [effectively, minimum wage].
However, there is a practical limit to compensation: students earning more than E20,000 a year are no longer eligible for the student loans you mention.
AFAIK that maximum is only for the "gift" that was superseded by a loan which has no max income limit.
Oh believe me... Coming from the US, the summer between my first and second year, I was compensated 5k for three months of work. When I first heard what was standard in NL I was shocked. Then again, I was also paying 50k per semester for school, soooo yeah, take your pick haha. I wouldn't say slavery, more like indentured servitude. Anyways, I make it my personal goal to give our interns as much of mine and our senior devs' time as possible, as well as support after their internship is over.
> I have a hard time believing that you will get in trouble for hiring interns and compensate them more than 500 euros.
Student visas?
Student visas?
>Finally, because they are in a special class, as interns, here in NL, we can actually get in trouble with the government for paying them more than 500 euro.
Hmm...I don't think you are correct, or possibly you are misconstruing a limited, special case to generally apply.
From my own experience I earned more than 600eur as an intern in the NL, and I had classmates who earned full minimum wage as interns too (~1200eur).
Hmm...I don't think you are correct, or possibly you are misconstruing a limited, special case to generally apply.
From my own experience I earned more than 600eur as an intern in the NL, and I had classmates who earned full minimum wage as interns too (~1200eur).
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
I understand your sarcasm, but what is sad some people actually think this way.
> I’m looking for another job :-)
Good, I was just going to suggest that!
Good, I was just going to suggest that!
Is there no room to fight management or make them understand?
High probability of “not productive effort”, i’m fighting my own rather serious battle with management at the moment.
On further note, before i started the contract i was asked to bring my own laptop as work computer, i didn’t necessarily agree (for all the obvious reasons as security and business/personal risk) but he was being pushy about i said i could take my laptop (at least to get started) and i was expecting to get a working computer. I never did. Management recently purchased brand new macbook pros and iphonex for themselves (which they are in their full right to do).
So i didn’t even dare to criticize them regarding the interns. I already got myself in boiling water by criticizing management in that the way projects and tasks were being managed was highly unprofessional and my only wish is if i could leave a warning sign for interns (and devs) to keep clear of this company (or think really hard on how much they need the job)
Edit: which is unfortunate given that the projects there are interesting in my opinion
On further note, before i started the contract i was asked to bring my own laptop as work computer, i didn’t necessarily agree (for all the obvious reasons as security and business/personal risk) but he was being pushy about i said i could take my laptop (at least to get started) and i was expecting to get a working computer. I never did. Management recently purchased brand new macbook pros and iphonex for themselves (which they are in their full right to do).
So i didn’t even dare to criticize them regarding the interns. I already got myself in boiling water by criticizing management in that the way projects and tasks were being managed was highly unprofessional and my only wish is if i could leave a warning sign for interns (and devs) to keep clear of this company (or think really hard on how much they need the job)
Edit: which is unfortunate given that the projects there are interesting in my opinion
I already got myself in boiling water by criticizing
management in that the way projects and tasks were being
managed was highly unprofessional...
I'm not making any comments on your personal situation, but as a general rule it's important to talk in terms of solutions and not problems. So don't say, "we have a problem and here is my recommendation to solve it". Say instead, "I think we can improve our productivity by...", or "I think we can save some money by...".
Do some calculations to help sell your case. You want to spend time optimising the build process? Record how long it takes to build the code currently. Maybe it takes 5 minutes. Maybe you build the software no fewer than 12 times a day. That's an hour of productivity wasted per developer. Do the maths, convert it into dollars. Then say, "we can save X dollars a week by optimising the build process. We spend a week working on this, we will have made our money back within a month (or whatever it is)."
Your manager will be quite happy to go to the board to tell them that he's improved efficiency by a factor of X.
Highlighting existing problems, even whilst providing solutions can put a manager on the defensive when you really need him to be your ally.
Obviously I'm not saying never highlight problems. Sometimes you have to highlight problems, but it requires delicacy and if you don't need to, then don't. You probably don't need to a lot more than you think. We developers tend to put the problem first and the solution afterwards and it's quite hard to put aside that mindset when talking to stakeholders. Even Elon Musk finds this hard to do when talking to the press. It's quite funny to hear him talking about all of a Tesla's inefficiencies while trying to sell it!
Also be patient. Your manager actually needs to be convinced of what you're saying; he can't just take your word for it. So if you see an example of how your solution would have prevented a problem that just had to be dealt with, point it out. Take him on a journey, to use an old cliché.
This doesn't work if you need help and resources to find solutions to said problems. You cannot solve everyone else's problems and implement solutions for them. You can suggest solutions, but someone has to give the okay and devote the time to implementation. If every problem you see requires you to submit a lengthy solutions proposal to the people who should be solving it themselves, you'll get burned out.
No, but you can solve the problems you can solve. That will give you currency to buy respect, trust, and responsibility.
I'm not suggesting you shouldn't do anything without getting permission first, but for the things you do need permission for, the above advice might help.
I'm not suggesting you shouldn't do anything without getting permission first, but for the things you do need permission for, the above advice might help.
Do you really want to use that currency to buy, trust respect, and responsibility for things outside your job description?
You have to watch out that a "go getter" attitude doesn't result in you just getting overburdened.
You have to watch out that a "go getter" attitude doesn't result in you just getting overburdened.
> which they are in their full right to do
They seem to be scamming the shareholders diverting money from productive investment into their self worth. It's not your problem, but it's not in their full right to do either.
They seem to be scamming the shareholders diverting money from productive investment into their self worth. It's not your problem, but it's not in their full right to do either.
I do not believe they have shareholders. Afaik, the company business model is around providing tech services for humanitarian aid institutions and at least some revenue comes from that type of donor funding
If they don't have money for buying proper productive equipment, but spend what they have in unproductive ostentatious stuff for management, they are very likely defrauding somebody. It may be shareholders, donors, tax-payers, or somebody else, but they are hurting somebody.
It is also almost certainly not the employees (unless it's a cooperative).
It is also almost certainly not the employees (unless it's a cooperative).
That sucks. Posting on Glassdoor could help, unless you risk your position before you have a new one with too much identifiable information. Definitely post after.
I have worked on my own laptop for a while (due to startup lack of money, it was either wage or the laptop at some point due to liquidity issues), with one point made to my employer: All copyright on work done on my laptop belongs to me, and only me. You can 'rent' it by paying me my wage but as soon as I leave, all code on it is mine and I'm taking it with me for future 'reference'. Don't know how this works legally but since I'm not a self employed person who has a business contract, I'm pretty sure you cannot legally force someone to use their own stuff without compensation.
I told them they could pay me a compensation (for using/bringing my own tools) but that is quite expensive since most deductions don't count for this. Even more expensive than buying a proper laptop. Quite quickly I got a proper company laptop after finances improved to resolve the issue.
On another note:
In my experience the term 'middle management' is a synonym for corrupt, useless idiots so getting rid of them saves huge amounts of money since they add no value to any product or to the company as a whole. Unfortunately there is no way to even moderately grow within most companies around here except for a management track which is idiotic since specialists are way more valuable to the gross product of the company.
and: Never underestimate the value of skilled workers and how to keep them or train them. In software they are your main business. Everything else is easily replaceable.
I told them they could pay me a compensation (for using/bringing my own tools) but that is quite expensive since most deductions don't count for this. Even more expensive than buying a proper laptop. Quite quickly I got a proper company laptop after finances improved to resolve the issue.
On another note:
In my experience the term 'middle management' is a synonym for corrupt, useless idiots so getting rid of them saves huge amounts of money since they add no value to any product or to the company as a whole. Unfortunately there is no way to even moderately grow within most companies around here except for a management track which is idiotic since specialists are way more valuable to the gross product of the company.
and: Never underestimate the value of skilled workers and how to keep them or train them. In software they are your main business. Everything else is easily replaceable.
All copyright on work done on my laptop belongs to me, and only me. You can 'rent' it by paying me my wage but as soon as I leave, all code on it is mine and I'm taking it with me for future 'reference'. Don't know how this works legally but since I'm not a self employed person who has a business contract, I'm pretty sure you cannot legally force someone to use their own stuff without compensation.
In the US at least, any work you do for an employer and get paid for is covered under what are called work-for-hire laws which assign the copyright to the company, unless you have a written contract stating otherwise. This is true regardless of what equipment you use, and there’s absolutely zero legal barrier to a company asking you to use your own equipment in the course of a job without any compensation. The fact that your ultimatum wasn’t met with a “lol no” from Legal is pure luck.
In the US at least, any work you do for an employer and get paid for is covered under what are called work-for-hire laws which assign the copyright to the company, unless you have a written contract stating otherwise. This is true regardless of what equipment you use, and there’s absolutely zero legal barrier to a company asking you to use your own equipment in the course of a job without any compensation. The fact that your ultimatum wasn’t met with a “lol no” from Legal is pure luck.
Why are the people who are so cocksure always the ones who know the least? “I’ve (incorrectly) interpreted copyright law, and I admit I don’t know how the law works, but I’m pretty sure I’m right.”
They don't think the rules apply to them, so they don't care what the rules are.
>I'm pretty sure you cannot legally force someone to use their own stuff without compensation.
That's the norm in some professions. Welders and mechanics often have their own tools, which can cost a lot more than a laptop.
That's the norm in some professions. Welders and mechanics often have their own tools, which can cost a lot more than a laptop.
What kind of dev job are you looking for? The company I work for is hiring.
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.
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.
> 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.
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.
..if all you plan for is short-term, it will only work short-term..
My point exactly, only in reverse. In industries (eg, merchant banking, corporate law, industrial engineering) where the plans are longer term, the thinking is longer term. Here you see highly involved onboarding programs with mentorship, in depth training and such.
Uber, FB, snapchat, netflix or whatnot never had plans that really looked past 2-3 years into the future. Ambitions, possibly. That's different to plans. These are on the young/ADD end of the spectrum, but they have cultural influence industry-wide.
I disagree about MVP. First, I don't think short horizon is bad, it's choice with advantages and disadvantages. Second, I do think MVP is part of a wider, shorter horizon planning mentality. That has certainly been my experience. The idea (IMO) is that instead of planning, you evolve. Evolution and planning are at odds with eachother, to an extent. You can make decisions early, and you get a longer term plan to work with. You can make decisions just-in-time (eg after launching an MVP), this gets you more informed decisions. That's not necessarily related to HR. You're hiring and onboarding could be unrelated to your product and engineering plans (or lack thereof). But (again, in practice), I think that mentality is influenced by these things.
^That's like, your opinion, man. ...always ;)
"I've yet to see that work" ... Uber. Netflix' streaming service.... for large, famous examples. Call those lotteries if you want. They're definitely risky. You may not like high risk strategies but they are a big part of the software industry, especially on the culturally influential wing.
My point exactly, only in reverse. In industries (eg, merchant banking, corporate law, industrial engineering) where the plans are longer term, the thinking is longer term. Here you see highly involved onboarding programs with mentorship, in depth training and such.
Uber, FB, snapchat, netflix or whatnot never had plans that really looked past 2-3 years into the future. Ambitions, possibly. That's different to plans. These are on the young/ADD end of the spectrum, but they have cultural influence industry-wide.
I disagree about MVP. First, I don't think short horizon is bad, it's choice with advantages and disadvantages. Second, I do think MVP is part of a wider, shorter horizon planning mentality. That has certainly been my experience. The idea (IMO) is that instead of planning, you evolve. Evolution and planning are at odds with eachother, to an extent. You can make decisions early, and you get a longer term plan to work with. You can make decisions just-in-time (eg after launching an MVP), this gets you more informed decisions. That's not necessarily related to HR. You're hiring and onboarding could be unrelated to your product and engineering plans (or lack thereof). But (again, in practice), I think that mentality is influenced by these things.
^That's like, your opinion, man. ...always ;)
"I've yet to see that work" ... Uber. Netflix' streaming service.... for large, famous examples. Call those lotteries if you want. They're definitely risky. You may not like high risk strategies but they are a big part of the software industry, especially on the culturally influential wing.
> In industries (eg, merchant banking, corporate law, industrial engineering) where the plans are longer term, the thinking is longer term
I work in banking at the moment, and the thinking is anything but longer term. Management is so desperate to hire enough qualified developers that it fills a lot of the vacancies with contractors, which are, by company's definition, temporary. So, in other words, the company is already planning to let go of people who will build its vital systems. That's myopic thinking at its finest.
What's interesting is that big part of enterprise market in, for example, London seems to operate like that - management pretends that people are replaceable cogs that hold no company-specific knowledge and require no ramp-up time. The stupidity of it is mind-boggling.
I work in banking at the moment, and the thinking is anything but longer term. Management is so desperate to hire enough qualified developers that it fills a lot of the vacancies with contractors, which are, by company's definition, temporary. So, in other words, the company is already planning to let go of people who will build its vital systems. That's myopic thinking at its finest.
What's interesting is that big part of enterprise market in, for example, London seems to operate like that - management pretends that people are replaceable cogs that hold no company-specific knowledge and require no ramp-up time. The stupidity of it is mind-boggling.
> Uber. Netflix' streaming service
I really don't think that Uber and Netflix hired for the short term. Especially Netflix. How did you get that? Netflix in particular seems to have been playing the long game for quite a while.
I really don't think that Uber and Netflix hired for the short term. Especially Netflix. How did you get that? Netflix in particular seems to have been playing the long game for quite a while.
Netflix has an unusual hr history, worth looking up if you're interested in that sort of thing.
To be fair to the parent commenter, I think the short time horizons are based on how startups are funded. We get 12-18 months funding per round. Everything starts from that - planning, etc. If you work at a large enterprise, then interns have a different role - normally it's more like a long interview process. But for startups, I don't agree with it, but I understand why there is little mentoring.
> Why can't you hire long-term?
You can, but I have never been offered a multi-year employment contract. Employers seem to prefer the flexibility of being able to terminate employment sooner than that.
You can, but I have never been offered a multi-year employment contract. Employers seem to prefer the flexibility of being able to terminate employment sooner than that.
If someone is on a permanent contract then their employment cannot simply be terminated ever. They can be made redundant, which means that the role cannot be refilled, or they can be fired but only after going through a disciplinary procedure (In the UK these rules only comes into effect after the first 2 years of employment).
So charge the self employed contractor rates then
In my opinion, attitudes similar to yours are toxic to this industry.
I've been working >10 years as a software engineer. If I'd never worked on a (necessarily) complicated system(s), I could maybe understand your viewpoint. Churning out the same CRUD app with minor differences would probably be safe enough to expect a junior dev to 'have at it'.
> Everything is fast
Unfortunately, this is the current 'thinking' on how some un-enlightened people think the industry should work. Ultimately, I think this is a load of nonsense. Software engineering is engineering. Some people may have snuck in & survived as they never had to do something non trivial & deal with the resulting consequences.
I've been working >10 years as a software engineer. If I'd never worked on a (necessarily) complicated system(s), I could maybe understand your viewpoint. Churning out the same CRUD app with minor differences would probably be safe enough to expect a junior dev to 'have at it'.
> Everything is fast
Unfortunately, this is the current 'thinking' on how some un-enlightened people think the industry should work. Ultimately, I think this is a load of nonsense. Software engineering is engineering. Some people may have snuck in & survived as they never had to do something non trivial & deal with the resulting consequences.
Where did I say that?! I never said junior devs should work independently.
Anyway ,it's not about how people think the industry should work it's about how it does work. This is a fast industry, irl. People change jobs more frequently. Companies grow faster. Products go from conception to release faster. Financial horizons are shorter.
A big chunk of the 2018 industry did not exist in 2008. Mobile, for example. Not the companies, not the specializations. It's not philosophy. It's reality. I'm talking about side effects of this reality.
No one at Snapchat thinks "we'll hire this kid, he'll make a great engineering manager in 15 years." They do in some industries. We're on the other end of the spectrum.
Anyway ,it's not about how people think the industry should work it's about how it does work. This is a fast industry, irl. People change jobs more frequently. Companies grow faster. Products go from conception to release faster. Financial horizons are shorter.
A big chunk of the 2018 industry did not exist in 2008. Mobile, for example. Not the companies, not the specializations. It's not philosophy. It's reality. I'm talking about side effects of this reality.
No one at Snapchat thinks "we'll hire this kid, he'll make a great engineering manager in 15 years." They do in some industries. We're on the other end of the spectrum.
If 1/3 of you developers are eating all of your mentoring time I would think that either you've made a hiring mistake, or lack appropriate teaching tools.
In one case you've hired someone who isn't ready to do the tasks you need without excessive scaffolding. In the other you're not providing enough structure and scaffolding for the intern to succeed with help.
Mentoring, particularly in the legal context of what makes an intern, an intern and not a Jr. Developer ought to be a short run project, and frankly if you can't commit time to providing an educational experience you shouldn't be filling your staffing needs with an intern at all.
In one case you've hired someone who isn't ready to do the tasks you need without excessive scaffolding. In the other you're not providing enough structure and scaffolding for the intern to succeed with help.
Mentoring, particularly in the legal context of what makes an intern, an intern and not a Jr. Developer ought to be a short run project, and frankly if you can't commit time to providing an educational experience you shouldn't be filling your staffing needs with an intern at all.
This has happened to me, but what it exposed was the hiring process gave absolutely no indication of whether the person could code. The 3 juniors assigned to me were interviewed by the VP, and I under him had no say or insight into the hiring process. 2 of them did super well and are now senior devs. One of them took up 30-40% of my time (with my putting up boundaries) and the basic understanding of the platform we were using never clicked for him.
The thing is - they got 2 very driven loyal devs out of it, and cheaper than normal at first. They also had an assessment period of 3 months after which the one who would take up all my time was let go. It was absolutely worth it for the company.
The thing is - they got 2 very driven loyal devs out of it, and cheaper than normal at first. They also had an assessment period of 3 months after which the one who would take up all my time was let go. It was absolutely worth it for the company.
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.
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.
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.
I learned to not get upset by it but still help/share, trying to inspire others and always learning more in this process.
Completely agree, it should always be team first.
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.
That's still team first, tbh. Team over your teammate.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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).
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).
Good junior devs are fairly rare, too - I wasn't claiming you find them everywhere.
> 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.
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.
Sr Dev with 26 years of experience. I get my edge not by coding fast. I maximize the amount of work that we don't have to do.
- Better (usually simpler) designs.
- Breaking the problem and choosing the order in which things are implemented.
- Setting up usefull feedback loops.
- etc, etc.
It is a lot about judgment.
- Better (usually simpler) designs.
- Breaking the problem and choosing the order in which things are implemented.
- Setting up usefull feedback loops.
- etc, etc.
It is a lot about judgment.
A deep understanding of your tool set is a huge advantage.
That is "coding fast". Coding fast doesn't mean literally churning out a lot of code and pull requests.
Managers often have trouble recognizing the difference, though. Even if they know the difference, measuring actual productivity is difficult and subjective, measuring number of pull requests or number of JIRA tickets closed is easy and objective.
> easy and objective.
that’s the worst kind of data - gives a meaningless feeling of objectivity.
that’s the worst kind of data - gives a meaningless feeling of objectivity.
Dunning-Kruger called, they want their overblown ego steamroller back.
People get better with practice. So, yes senior developers tend to be significantly faster coders. It's not that they do everything faster, but by getting better at the hard parts they finish complex tasks vastly more quickly.
PS: Most people have never worked closely with someone with 25+ years of experience, but the difference is staggering.
PS: Most people have never worked closely with someone with 25+ years of experience, but the difference is staggering.
Well, I am someone with 25 years of experience, does that count as "worked closely with"?
Good junior devs are... well, by definition, good. They're just younger, and less experienced - but every bit as smart as you are, and pretty skilled in the art of coding. If anything, they have more time than I do and are a lot more eager to "prove themselves".
I don't view the value I add as "can code features faster"...
Good junior devs are... well, by definition, good. They're just younger, and less experienced - but every bit as smart as you are, and pretty skilled in the art of coding. If anything, they have more time than I do and are a lot more eager to "prove themselves".
I don't view the value I add as "can code features faster"...
Good junior devs can also have 15+ years of non professional experience from starting as a kid. It's a wide enough bucket that talking about just the top end is very misleading, however the median jr dev is relatively slow and bug prone.
If they have not done any real coding before going to uni I could understand - this BTW is what the raspberry pi was originally created for.
> I don't view the value I add as "can code features faster"
I do, at least partly. I can code so much faster that my cost per feature is lower than a junior dev.
I do, at least partly. I can code so much faster that my cost per feature is lower than a junior dev.
Your cost is less by being paid more? Seems legit
His projects are most likely successful and profitable. The junior devs is probably a comparative catastrophe. I honestly don't get where this junior devs are faster meme is coming from, it sure doesn't represent my experience.
My cost is less by doing more in the same amount of time.
Which is offset by the fact that you're paid significantly more
The point you keep missing is that the amount I'm paid more isn't equivalent to the amount more I can do than a junior dev. I perform at some X more than the junior dev, but I'm not paid X more.
I have.
It was staggering how they had managed to survive for 25+ years. Every person is different.
It was staggering how they had managed to survive for 25+ years. Every person is different.
He may have been far worse 25 years ago. ¯\_(ツ)_/¯
Having not worked with the same person for 25 years I can only speak of the average case.
Having not worked with the same person for 25 years I can only speak of the average case.
I can point to my well documented track record: code reviews, bonuses, promotions, code longevity, metrics, etc. as evidence. I can code multiple features in the time that a junior dev does one, even with me mentoring them. That doesn't mean they're bad, or even worse than average. It just means that after a career spent honing my craft, I'm much better than average.
I wasn't questioning your seniority.
I pointed out how you decided to pick out a totally irrelevant, rhetorical sentence out of all points that OP made, and then decided to refute that, by claiming how much experience you have, and setting up yourself center stage, instead of adding value to the actual discussion topic at hand, which is the coaching gap.
I pointed out how you decided to pick out a totally irrelevant, rhetorical sentence out of all points that OP made, and then decided to refute that, by claiming how much experience you have, and setting up yourself center stage, instead of adding value to the actual discussion topic at hand, which is the coaching gap.
I directly disputed the central thesis that OP (the person I was responding to, not the article) was putting forth, that senior developers shouldn't be coding:
> You don't hire senior devs to code - good junior devs can code not only "just as fast", but probably faster too!
> "Mentoring" is basically the job you hire a senior dev to do
What other "points" did OP make?
> You don't hire senior devs to code - good junior devs can code not only "just as fast", but probably faster too!
> "Mentoring" is basically the job you hire a senior dev to do
What other "points" did OP make?
Your reading comprehension suffers under your fragile ego.
Nobody said 'senior developers shouldn't be coding'.
The topic is about a lack of mentoring for junior devs. You being a certified 100x rockstar developer is totally fine but irrelevant, because you don't scale.
What would scale is if you were to start coaching junior devs, because if you don't, all the juniors will keep reinventing 'left-pad' in this week's ES201x iteration, while your retirement keeps getting closer.
Instead of adding to the discussion on how to solve the coaching gap, you decided to defend your coding efficiency and how you deliver features faster than a Junior Dev. You missed the point completely. You're part of the problem the article addresses, don't you realize?
The topic is about a lack of mentoring for junior devs. You being a certified 100x rockstar developer is totally fine but irrelevant, because you don't scale.
What would scale is if you were to start coaching junior devs, because if you don't, all the juniors will keep reinventing 'left-pad' in this week's ES201x iteration, while your retirement keeps getting closer.
Instead of adding to the discussion on how to solve the coaching gap, you decided to defend your coding efficiency and how you deliver features faster than a Junior Dev. You missed the point completely. You're part of the problem the article addresses, don't you realize?
> Your reading comprehension suffers under your fragile ego. Nobody said 'senior developers shouldn't be coding'.
That is exactly what the post I was responding to said, and I've quoted it several times. Here it is a gain, since you keep glossing over it:
> You don't hire senior devs to code - good junior devs can code not only "just as fast", but probably faster too!
> "Mentoring" is basically the job you hire a senior dev to do
So, yes, the person I responded to said "senior developers shouldn't be coding'".
> You being a certified 100x rockstar developer is totally fine but irrelevant, because you don't scale.
How so? I'm a mentor as well as a developer. In addition to doing my part to train the next wave of devs, I also code my ass off. What part of that doesn't scale?
> You missed the point completely.
No. That's what you did though. And are increasingly insulting about it as well.
> You're part of the problem the article addresses, don't you realize?
Who's talking about the article? I was talking about the bogus "point" in the post I responded to.
That is exactly what the post I was responding to said, and I've quoted it several times. Here it is a gain, since you keep glossing over it:
> You don't hire senior devs to code - good junior devs can code not only "just as fast", but probably faster too!
> "Mentoring" is basically the job you hire a senior dev to do
So, yes, the person I responded to said "senior developers shouldn't be coding'".
> You being a certified 100x rockstar developer is totally fine but irrelevant, because you don't scale.
How so? I'm a mentor as well as a developer. In addition to doing my part to train the next wave of devs, I also code my ass off. What part of that doesn't scale?
> You missed the point completely.
No. That's what you did though. And are increasingly insulting about it as well.
> You're part of the problem the article addresses, don't you realize?
Who's talking about the article? I was talking about the bogus "point" in the post I responded to.
For what it’s worth I agree with the person you’re replying to. The OP is saying: given two senior applicants with the same coding skill level, the one most suited to the job is the person who can communicate to juniors and delegate effectively.
I’m surprised you mentor, given all the hubris you have displyed on this thread.
I’m surprised you mentor, given all the hubris you have displyed on this thread.
> The OP is saying: given two senior applicants with the same coding skill level, the one most suited to the job is the person who can communicate to juniors and delegate effectively.
If that's what he was saying, I'd be much more in agreement. Instead he said, effectively, that senior devs shouldn't be coding because they can't do it any better than junior devs.
If that's what he was saying, I'd be much more in agreement. Instead he said, effectively, that senior devs shouldn't be coding because they can't do it any better than junior devs.
No. Read it again. What I was saying is two things:
A. GOOD junior devs can (and often do) outperform good senior devs at the metric of "quantity of code produced" (I later added that IMO in fact they should, not just can)
B. (the central point of my argument, really) If you're working on the premise "we can’t afford to have our senior developers mentor juniors" , you're misusing the senior devs. It's not just cost-ineffective (you're paying a senior do to a junior's work), but you also run into other risks as well (juniors that ask questions force seniors to explain stuff, which in turn forces them to think clearly about it; you may have experienced the phenomenon where you understand something much better after explaining it to somebody else)
A. GOOD junior devs can (and often do) outperform good senior devs at the metric of "quantity of code produced" (I later added that IMO in fact they should, not just can)
B. (the central point of my argument, really) If you're working on the premise "we can’t afford to have our senior developers mentor juniors" , you're misusing the senior devs. It's not just cost-ineffective (you're paying a senior do to a junior's work), but you also run into other risks as well (juniors that ask questions force seniors to explain stuff, which in turn forces them to think clearly about it; you may have experienced the phenomenon where you understand something much better after explaining it to somebody else)
And I'm saying that your arguments are wrong. I don't care how good the junior dev is, I can out code them every time.
> If you're working on the premise "we can’t afford to have our senior developers mentor juniors" , you're misusing the senior devs.
Actually, no argument there. Mentoring is indeed a critical function of senior devs.
> It's not just cost-ineffective (you're paying a senior do to a junior's work)
And you lost me there. I'm so much more effective that it's always cheaper to have me do it, assuming I don't have a higher priority task (in which case it's a non-issue, since I'm working on that one). I.E. I'm a 10x (or 100x) developer, but I don't get paid 10x (or 100x).
> If you're working on the premise "we can’t afford to have our senior developers mentor juniors" , you're misusing the senior devs.
Actually, no argument there. Mentoring is indeed a critical function of senior devs.
> It's not just cost-ineffective (you're paying a senior do to a junior's work)
And you lost me there. I'm so much more effective that it's always cheaper to have me do it, assuming I don't have a higher priority task (in which case it's a non-issue, since I'm working on that one). I.E. I'm a 10x (or 100x) developer, but I don't get paid 10x (or 100x).
[deleted]
The Dunning-Kruger effect is a bias and as such deals with probabilities. It doesn't mean any given individual says they're the best (in their neck of the woods) at something is definitely wrong.
True. But the team as a whole would probably still achieve much more if you were mostly guiding other (less experienced) devs.
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.
> can code not only "just as fast", but probably faster too!
is pure BS.
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.
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.
> 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?
Who uses LOC? I'm talking about completed, tested, accepted features, as defined by our project teams.
> Good junior devs will be more skilled in some areas than you are.
Well, yeah...of course. I'm not comparing myself to someone who works in an entirely different field. A junior front-end dev will be better than me at front-end stuff. I'm talking about a junior in my area, who I'd be in a team with or would mentor.
> The measure of seniority is in my mind about knowing what to NOT build, in the first place.
I agree with that statement.
Who uses LOC? I'm talking about completed, tested, accepted features, as defined by our project teams.
> Good junior devs will be more skilled in some areas than you are.
Well, yeah...of course. I'm not comparing myself to someone who works in an entirely different field. A junior front-end dev will be better than me at front-end stuff. I'm talking about a junior in my area, who I'd be in a team with or would mentor.
> The measure of seniority is in my mind about knowing what to NOT build, in the first place.
I agree with that statement.
> I'm talking about completed, tested, accepted features, as defined by our project teams.
Still rather strange metrics for productivity in a senior engineer. This is more what I'm taking about: https://zef.me/the-100x-engineer-6d50a690a866
If you're really senior, you shouldn't be working on the kind of features that get delivered at a rate of "5 per sprint". More like on stuff that gets delivered once every year. The junior SHOULD outperform you in "code produced" - they just shouldn't outperform you in dollars produced (or saved).
Still rather strange metrics for productivity in a senior engineer. This is more what I'm taking about: https://zef.me/the-100x-engineer-6d50a690a866
If you're really senior, you shouldn't be working on the kind of features that get delivered at a rate of "5 per sprint". More like on stuff that gets delivered once every year. The junior SHOULD outperform you in "code produced" - they just shouldn't outperform you in dollars produced (or saved).
You do what your team and company needs. If they need me to work on a big re-engineering project, or build a core framework feature, I do it. If they need me to get onto a regular sprint team for a while and churn out the backlog, I do it.
I believe it. Though my experience is that junior devs can be much faster at producing lines of code, and most of it's junk. Senior devs will always be faster at producing bug free lines of code, and certainly at catching more of the edge cases. Moreover, the best devs I've worked with know when not to code at all to solve a problem, which is a totally foreign concept to junior devs who seem to prefer coding to thinking.
When I look at code written by junior devs I often think 'dear god, how is there so much code that does nothing, and how did it all get witten since I last had a chance to look'.
Makes me wonder if there are parallels in writing. My understanding is that the most prolific authors can only write 8 publishable pages a day. I'd bet that amateur writers can produce more pages than that, but no page could be published without at least as much time spent by an editor.
When I look at code written by junior devs I often think 'dear god, how is there so much code that does nothing, and how did it all get witten since I last had a chance to look'.
Makes me wonder if there are parallels in writing. My understanding is that the most prolific authors can only write 8 publishable pages a day. I'd bet that amateur writers can produce more pages than that, but no page could be published without at least as much time spent by an editor.
> dear god, how is there so much code that does nothing, and how did it all get witten since I last had a chance to look
This, 100 times over! It is simply incredible how much code and how complex systems a junior dev (junior by knowledge, not by years of coding) can produce in a short time while you were looking the other way... :-D
This, 100 times over! It is simply incredible how much code and how complex systems a junior dev (junior by knowledge, not by years of coding) can produce in a short time while you were looking the other way... :-D
> I'm about as "senior" as it gets
Senior developers make sure to question their assumptions on a regular basis, FYI
Senior developers make sure to question their assumptions on a regular basis, FYI
What about cross-discipline? What if a problem comes up that would be better solved with technology Y instead of X and you are an X master but random intern happens to know Y. Are you still the fastest? What if the intern is better at making slides for code reviews that show important trends? Or they can write fantastic documentation? Or tools?
I'm sure you're a quick learner but at least in scenarios I've worked in there are often many, many possible solutions and no specific "right answer."
After all, it's hard for anyone to be right all of the time.
I'm sure you're a quick learner but at least in scenarios I've worked in there are often many, many possible solutions and no specific "right answer."
After all, it's hard for anyone to be right all of the time.
None of that has anything to do with the original blanket assertion of "good junior devs can code not only "just as fast", but probably faster too!".
Aye, but you probably can't code faster if you have to read a manual first? It is easy to construct scenarios where someone from a bootcamp could code "faster" than a principal, senior lead, or CTO of all things. It's just a matter of picking the problem.
A better point is that this drought of new talent is just the other side of the pendulum. In the odd years, the problem is layoffs and difficulty finding work without being a new-grad or knowing the latest tech fad. You've seen some of those summers, too?
A better point is that this drought of new talent is just the other side of the pendulum. In the odd years, the problem is layoffs and difficulty finding work without being a new-grad or knowing the latest tech fad. You've seen some of those summers, too?
> Aye, but you probably can't code faster if you have to read a manual first?
If we both had to read the manual? Yeah, I'd still be faster. It's just as easy to cherry-pick for one side or another.
If we both had to read the manual? Yeah, I'd still be faster. It's just as easy to cherry-pick for one side or another.
The general point he makes is that "if I define what speed means, I always code faster", so yeah, he's right. Sort of :)
Welp, get back to me when you're 50 Mr. Senior and we'll see how you fared over the long haul. Because "coding monster" or not, when you hit 40, companies will be less enthusiastic about hiring you, and by the time you're 50, you'll be out, so I hope you're making bank right now and saving as much of it as you possibly can because there are no do-overs.
Really? I'm 54, and constantly have to turn away recruiters who pester me. Long haul is looking pretty good, right now anyway. Even if you're a junior dev, outlooks can change and shift...it's all about staying relevant and proving your worth.
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>
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>
> 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.
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.
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.
> 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
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
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
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.
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.
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.
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.
There were never any junior dev jobs. You have always had to lie, cheat, and steal your way into the field. I have a buddy who legit cheated his way to the top Magento certification and now cycles through $150k+ jobs where they keep him on long enough to realize he doesn't have any coding skills then they fire him.
Reason is software is always an ancillary concern to the business. You see this in other fields, like say accounting, but the difference is that accountants leave school fully capable of employment. HR understands how to hire and manage accountants.
But programming is this black box in the corporate world that no one knows how to understand, value, or hire for. This is why every company wants rockstars, they're hoping that someone whose at least confident to present themselves as a rockstar won't be a net negative to the company.
Eventually they'll figure it out, took them a decade to figure out how to manage IT. Then companies will learn that they can't skimp on middle management for software developers. Some companies will need to give software a legit seat at the table and hire upper management. The political cover will allow shops to stabilize and with stabilization, you'll finally start seeing small and midsize organizations open up positions for juniors.
But it'll never happen so long as companies don't take software development seriously by giving them political cover. If you are a software developer nearing the middle or end of your career, you're pulling the ladder up behind you if you don't seriously consider moving into management. It's too important a job to ignore to go chase your dreams.
Reason is software is always an ancillary concern to the business. You see this in other fields, like say accounting, but the difference is that accountants leave school fully capable of employment. HR understands how to hire and manage accountants.
But programming is this black box in the corporate world that no one knows how to understand, value, or hire for. This is why every company wants rockstars, they're hoping that someone whose at least confident to present themselves as a rockstar won't be a net negative to the company.
Eventually they'll figure it out, took them a decade to figure out how to manage IT. Then companies will learn that they can't skimp on middle management for software developers. Some companies will need to give software a legit seat at the table and hire upper management. The political cover will allow shops to stabilize and with stabilization, you'll finally start seeing small and midsize organizations open up positions for juniors.
But it'll never happen so long as companies don't take software development seriously by giving them political cover. If you are a software developer nearing the middle or end of your career, you're pulling the ladder up behind you if you don't seriously consider moving into management. It's too important a job to ignore to go chase your dreams.
My "standard" team typically has two jr engineers, and two Sr engineers. When we hire Sr engineers we hire people that like to mentor others and see it as part of being Sr. Jr engineers know that in order to become Sr one of the skills they need to master is mentoring.
This is 100% a management issue, and it starts at the hiring filter.
Hiring Jrs btw is its own skill as you are filtering for potential not skill or knowledge. Identifying the person who is passionate about learning, has dedication to the craft and pride in their work, and has a natural talent for software is hard. Figure it out though and you have a competitive advantage for life as a manager.
Also, half of the Jrs we hire are women. We could never do that if we only hired experienced talent. Not enough women even apply for those roles.
This is 100% a management issue, and it starts at the hiring filter.
Hiring Jrs btw is its own skill as you are filtering for potential not skill or knowledge. Identifying the person who is passionate about learning, has dedication to the craft and pride in their work, and has a natural talent for software is hard. Figure it out though and you have a competitive advantage for life as a manager.
Also, half of the Jrs we hire are women. We could never do that if we only hired experienced talent. Not enough women even apply for those roles.
I'll see your management issue and raise you a leadership one.
At my last job, a $40MM cosmetics and skincare company, the CEO had a great deal of trouble figuring out how to get his e-commerce department properly managed. I was willing to step up, and for a brief time they allowed me to bring in candidates for a position that would report to me, but I didn't have enough political cover over me so that fizzled out.
I cycled through 3 managers in 2 1/2 years at that job, 2 in the "Director of E-Commerce" role, and one in the "VP of E-Commerce" role. All three left for more sane roles.
It's hard to fix management problems at your company when leadership is so confused.
At my last job, a $40MM cosmetics and skincare company, the CEO had a great deal of trouble figuring out how to get his e-commerce department properly managed. I was willing to step up, and for a brief time they allowed me to bring in candidates for a position that would report to me, but I didn't have enough political cover over me so that fizzled out.
I cycled through 3 managers in 2 1/2 years at that job, 2 in the "Director of E-Commerce" role, and one in the "VP of E-Commerce" role. All three left for more sane roles.
It's hard to fix management problems at your company when leadership is so confused.
I never thought about it, but "IT / development is crap in legacy industries" follows as a tautology from your perspective.
If the only way to effectively perform the job (in the broader, department sense) is with political cover.
And if political cover is only apportioned in a zero-sum game of high level positions.
And if there are legacy industries in which those positions are, and have been for decades, apportioned to predefined departments (notably standardized before the information revolution).
Then those legacy industries are going to have insufficient political cover over IT/development. And therefore terrible performance.
My current employer recently had a security epiphany, and they definitely empowered a reorganized security department to make necessary changes. But I'm sure there were many points where "VP of X" could have squashed a necessary security change, had security not been of equal seniority.
If the only way to effectively perform the job (in the broader, department sense) is with political cover.
And if political cover is only apportioned in a zero-sum game of high level positions.
And if there are legacy industries in which those positions are, and have been for decades, apportioned to predefined departments (notably standardized before the information revolution).
Then those legacy industries are going to have insufficient political cover over IT/development. And therefore terrible performance.
My current employer recently had a security epiphany, and they definitely empowered a reorganized security department to make necessary changes. But I'm sure there were many points where "VP of X" could have squashed a necessary security change, had security not been of equal seniority.
E-commerce is unique in that it has such a massive impact on revenue generation, but the skills needed to effectively manage it are rarely inline with the core competencies of the business.
Most companies attempt to tackle this problem in house, but without proper expertise, there is massive waste in hiring and poor execution. As a consultant, I’ve seen teams waste _years_ fumbling in this cycle, only for me to ship a product that immediately increases revenue in a fraction of the time. It generally only takes a few basic UI improvements and timing strategic automatic email tiggers.
Find a consultant that will make more from what you already have, and move on to your business problems. You don’t need to pivot into an internet company to be successful.
Most companies attempt to tackle this problem in house, but without proper expertise, there is massive waste in hiring and poor execution. As a consultant, I’ve seen teams waste _years_ fumbling in this cycle, only for me to ship a product that immediately increases revenue in a fraction of the time. It generally only takes a few basic UI improvements and timing strategic automatic email tiggers.
Find a consultant that will make more from what you already have, and move on to your business problems. You don’t need to pivot into an internet company to be successful.
Hm. I get what you're saying, but I think the three managers they had in my tenure were pretty good in that regard. The team was just me and a front-end guy, and we had no problem keeping up with the workload.
My impression was that we'd squeezed all the blood we could out of the stone, yet the CEO wasn't going to accept "focus on other business problems" as an answer.
Eventually my pleas were heard and they consulted out a new platform. They didn't pick a platform that I wanted to administer, so I moved on. The fourth manager they hired after I left did not appear to have made any purchase on the problem the last time I talked to her.
I naively thought the problem was technology, but the real problem was the expectations of the CEO. There was nothing I could do about it, of course, so it worked out for the best.
My impression was that we'd squeezed all the blood we could out of the stone, yet the CEO wasn't going to accept "focus on other business problems" as an answer.
Eventually my pleas were heard and they consulted out a new platform. They didn't pick a platform that I wanted to administer, so I moved on. The fourth manager they hired after I left did not appear to have made any purchase on the problem the last time I talked to her.
I naively thought the problem was technology, but the real problem was the expectations of the CEO. There was nothing I could do about it, of course, so it worked out for the best.
That is because business regards its technical staff "in comtempt" and that is a direct quote from one of my previous bosses (a director at on of the largest publishers in the world)
"We keep our developers away from sales teams as they tend to be dreamkillers."
A client one time told me in the past. At the time, I wanted to ask, "so, how badly are you treating them?"
A client one time told me in the past. At the time, I wanted to ask, "so, how badly are you treating them?"
I've seen the same issue, only they never tried it in house. Instead they spent a million or so over 5 years with different consultants who all did an extremely poor job and each time through out previous work and requirements.
This problem isn't unique to in house teams. It's hard to find and motivate competent people whether salaried or consulting.
This problem isn't unique to in house teams. It's hard to find and motivate competent people whether salaried or consulting.
Well put.
Do you still do consulting?
Please reach me at brandon {at} brandonreiss {dot} com to explore an opportunity with a small e-commerce retailer/wholesaler.
Do you still do consulting?
Please reach me at brandon {at} brandonreiss {dot} com to explore an opportunity with a small e-commerce retailer/wholesaler.
This is absolutely true. Ive been lucky that the last 17 years of my career have been spent reporting to the CEO and have had a large amount of leeway in my position. That's not always the case and a bad leadership team can't create a good culture.
I should have made a case for reporting to the CEO myself. None of the three managers could figure out how to do it, and I spent more time than I should have trying to coach them on how to handle him. But I wanted to be comfortable and reporting to the CEO would have been the opposite of that.
I am philosophically similar, although I generally hire at a 2 to 1 ratio, senior to junior.
I've found that I'm (as in, the boss guy) the most common blockade to ensuring that mentorship is productive and not disruptive. A 2 to 1 hiring ratio is playing the same game you are but on "Easy" instead of "Normal". So :thumbsup: on maintaining a 1 to 1 ratio.
Regarding how this relates to hiring women -- it's not just women. It has been a general diversity boon to teams where I've employed this practice, increasing diversity not just in the "affirmative action" groups (not to diminish the importance of that) but also in programmer background. I've had junior engineers bring insights far outside my sphere simply because they were previously (e.g.) a copywriter.
I've found that I'm (as in, the boss guy) the most common blockade to ensuring that mentorship is productive and not disruptive. A 2 to 1 hiring ratio is playing the same game you are but on "Easy" instead of "Normal". So :thumbsup: on maintaining a 1 to 1 ratio.
Regarding how this relates to hiring women -- it's not just women. It has been a general diversity boon to teams where I've employed this practice, increasing diversity not just in the "affirmative action" groups (not to diminish the importance of that) but also in programmer background. I've had junior engineers bring insights far outside my sphere simply because they were previously (e.g.) a copywriter.
As a woman currently applying/interviewing for a new grad role, I think you're definitely right about most companies caring only about current knowledge/skill.
Why is that bad? Jobs should be filled based on skill/knowledge. (The ability to learn is a skill too, one that means what you know currently matters less). I take slight offence to your statement. Why is being a woman relevant to anything, unless your company is going for 50/50 male female. But in my opinion that is wrong, and amounts to sex discrimination against men, because if 50% of roles are filled by men, even if there is a better male candidate, then the female will get the role. (And vice versa, but that is generally not the case in my experience). This is wrong. It's about what the person can do, not evening numbers. Sex discrimination gone mad!
This is just the current zeitgeist we live in right now. In my prior career as an electrician, I didn't see any of this brought up by my employer/industry, but now that I'm a software developer, I see it all the time. I think that might be because the work of an electrician is more physical and labor-intensive, and therefore not very enticing to a lot of women looking to enter the workforce.
I think that a women quota is useful in cases where the proportion of female (one could also insert specific cultural backgrounds here) possible applicants for a role (be it junior or leader) is much higher than the proportion in the actual role. For instance, in theatres or hospitals in Germany, a large part of the employees is female whilst the bosses tend to be male. You cannot argue with "but better candidates will be turned down just because they are male" because obviously, the criteria for choosing are heavily unbalanced already.
It's harder to determine whether a quota is useful in jobs the reason for not choosing women might be women not applying for the job. But we won't solve the matter by hating each other over the cause. Let's try to be critical, yet empathic.
The very existence of a quota is sex discrimination against both men and women.
It is. Sex discrimination gone mad. All rich industries have it, IT was the latest bastion to conquer. Please join a group for men’s rights, we only get nothing because men never dare to stand up as a gender.
Building diversity is an important component of forward progress, since it engenders a broader experiential pool to draw from.
In the case of gender, female developers have been shut out of the industry for long enough that corrective action has to be taken to balance the scales. Until such time as that happens, "sex discrimination against men" is impossible.
In the case of gender, female developers have been shut out of the industry for long enough that corrective action has to be taken to balance the scales. Until such time as that happens, "sex discrimination against men" is impossible.
>Building diversity is an important component of forward progress, since it engenders a broader experiential pool to draw from.
Only the pool has to be created in the lower levels (education etc) not imposed at the company level with less good candidates favored just because of their sex.
>Until such time as that happens, "sex discrimination against men" is impossible.
It's very possible, if meritocracy is sidestepped, and the person who gets sidestepped is a man in favor of e.g. 50-50 parity with a woman.
Unless the pool entering the workforce is 50-50 already, then 50-50 hiring requires discrimination.
Only the pool has to be created in the lower levels (education etc) not imposed at the company level with less good candidates favored just because of their sex.
>Until such time as that happens, "sex discrimination against men" is impossible.
It's very possible, if meritocracy is sidestepped, and the person who gets sidestepped is a man in favor of e.g. 50-50 parity with a woman.
Unless the pool entering the workforce is 50-50 already, then 50-50 hiring requires discrimination.
Gender is only one factor. It's what I focused on here because of context. Nationality, native language, childhood population density, and even hobby choices all play a part in experiential makeup.
"Meritocracy" is almost always a flawed idea, because it relies on the principle of those in positions of authority choosing the best candidate for a given role; the key word here is "best." That's a subjective term, and usually favors a small set of criteria over a more holistic view. People, with some exceptions, are bad at seeing the big picture.
With very few exceptions, I will always favor candidates with broader experience over those with narrow strengths.
"Meritocracy" is almost always a flawed idea, because it relies on the principle of those in positions of authority choosing the best candidate for a given role; the key word here is "best." That's a subjective term, and usually favors a small set of criteria over a more holistic view. People, with some exceptions, are bad at seeing the big picture.
With very few exceptions, I will always favor candidates with broader experience over those with narrow strengths.
>"Meritocracy" is almost always a flawed idea, because it relies on the principle of those in positions of authority choosing the best candidate for a given role; the key word here is "best." That's a subjective term, and usually favors a small set of criteria over a more holistic view.
That's the whole idea. When you need a surgeon you don't need a specifically sexed, or colored, or whatever surgeon. You just need a person good at the "small set of criteria" of performing a surgery.
That's the whole idea. When you need a surgeon you don't need a specifically sexed, or colored, or whatever surgeon. You just need a person good at the "small set of criteria" of performing a surgery.
I completely disagree for reasons I already said above. Meritocracy is the basis of life. Including evolution. Men are better at some things and women are better at some things. And you know what? That's fine by me.
Eg. Imagine if I was at the top of a burning building and my family needed rescued. I would want 5 men to try to save us, not 5 women. Does that make be sexist or normal minded?
EDIT: and off course vice versa for tasks that women are best suited.
Eg. Imagine if I was at the top of a burning building and my family needed rescued. I would want 5 men to try to save us, not 5 women. Does that make be sexist or normal minded?
EDIT: and off course vice versa for tasks that women are best suited.
It is still descrimination.
"Discrimination: the act, practice, or an instance of discriminating categorically rather than individually" - Merriam Webster Dictionary
Please don't bend what the word means just because others do. If we have our own meanings for every word, than the words mean nothing.
"Discrimination: the act, practice, or an instance of discriminating categorically rather than individually" - Merriam Webster Dictionary
Please don't bend what the word means just because others do. If we have our own meanings for every word, than the words mean nothing.
Fair enough.
But it's discrimination with a higher purpose.
But it's discrimination with a higher purpose.
I'd like to share a perspective based on an anecdote. The first company that I'd worked for had come to our college to hire interns. They wanted 2. I'd find out later that the CEO had intended one male hire and one female hire, but they ended up hiring 3 (all men) including me.
Two of us that got hired were from financially poor background, had lived in tier 3 cities, went to underfunded-corrupt schools with bad educators (as was common in the region we were from), had taken out huge education loans and were possibly the only source of retirement income for our parents (I'm based out of India, poor people have to rely on their children's success here). There were around 10-15 women in our batch. Most were from well off families, had well-educated parents who were also bankrolling their daughters' education, were from tier-1 cities and were exposed to tech long before us. They'd had better opportunities for growth even before joining college and only equal opportunities after, like the rest of us.
In retrospect I feel that I had been lucky in a certain sense. Thankfully the recruiters weren't people with the >`But it's discrimination with a higher purpose.` mindset. It would've been a very difficult road to recovery for me otherwise.
I would urge you to reconsider the notion that affirmative action is a sustainable solution for anything. It's hack. You only need to look at the current state of India's government, which over the course of more than 50 years of affirmative action (and other varying factors) has managed to convert the government sector into a cesspool of corruption and bad management.
I would urge you to reconsider the notion that affirmative action is a sustainable solution for anything. It's hack. You only need to look at the current state of India's government, which over the course of more than 50 years of affirmative action (and other varying factors) has managed to convert the government sector into a cesspool of corruption and bad management.
>You only need to look at the current state of India's government, which over the course of more than 50 years of affirmative action (and other varying factors) has managed to convert the government sector into a cesspool of corruption and bad management.
This seems to imply that India's government fifty years ago was NOT full of corruption and bad management. The Raj was definitely corrupt but I know little about the two decades after India got its independence - were things really that good fifty years ago? Or was it just that it was less obvious?
This seems to imply that India's government fifty years ago was NOT full of corruption and bad management. The Raj was definitely corrupt but I know little about the two decades after India got its independence - were things really that good fifty years ago? Or was it just that it was less obvious?
No, not implying that. I used `more than 50 years` as a range, as these policies were also proposed as part of the Raj's secession. The introduction of affirmative action wasn't a single event, but a growing set of reservations and quotas included in education, govt sector hiring and other places. Even today, the left leaning political parties use this topic as a leverage to increase their vote bank.
This is probably the most reasoned counterargument I've seen here.
I'm going to step away and do some more reading on the subject before responding. Since this thread will likely be stale by then, I'll put up a blog post or similar with my updated thoughts.
I'm going to step away and do some more reading on the subject before responding. Since this thread will likely be stale by then, I'll put up a blog post or similar with my updated thoughts.
well said.
> Hiring Jrs btw is its own skill as you are filtering for potential not skill or knowledge. Identifying the person who is passionate about learning, has dedication to the craft and pride in their work
I think this is so true of software development roles, but doesn't it actually apply to every hire? unless you have a _very_ specific role with explicit skill set, senior roles need to be just as flexible and able to learn new things quickly.
I think this is so true of software development roles, but doesn't it actually apply to every hire? unless you have a _very_ specific role with explicit skill set, senior roles need to be just as flexible and able to learn new things quickly.
How many women hired would be enough to satisfy those roles you mention?
> Also, half of the Jrs we hire are women. We could never do that if we only hired experienced talent. Not enough women even apply for those roles.
You're giving preferential treatment to your recruits on the basis of their gender?
You're giving preferential treatment to your recruits on the basis of their gender?
No. However we get more applicants that are women for the Jr roles and our hiring criteria matches them roughly as often as it matches men. For the sr positions 80% or more of applicants are men which roughly translates into 80% or more of hires being men. Pretty easy to see the math there without having to introduce any sort of preferential treatment.
I'm not the person you're replying to, but I took it to mean that they end up hiring about half women for those roles, not that the explicitly seek them out.
It seems like men and women are applying to the junior roles in roughly equal proportion, while the applications to the senior roles might be more skewed to the tune of 80/20 or worse.
Just ball-parking numbers, but that's what I got from his post.
Just ball-parking numbers, but that's what I got from his post.
Then you will need two senior devs. This is because rockstar devs rarely want to mentor junior devs nor attend meetings.
Most inventors are not professors.
Then they aren't a rockstar. And frankly, I've spent my career cleaning up the obfuscated, badly documented, untested code of "rockstar" devs.
The idea of a "rockstar" you seem to be referring to has, in my experience, been a dev who can go into a corner and pump out high volumes of code with little supervision or collaboration. That's great, except no one else can make sense of the code they pump out, so when it comes time for the next guy to add a feature to the rockstar's mess it takes 2 to 3 times as long as it should.
I've also had to clean up messes by rockstars who made unilateral decisions about incorporating new technologies into a product. Like building out a single part of the product in React with out asking anyone else. You see, the rockstar didn't like meetings and didn't want to make the case to the rest of the team for why we should all learn React and gradually switch over. Instead, he just stuck it into the code. So now, you have a couple of views built as React components, and the rest of the thing is in Backbone. No one else knows React or has time to learn it, cause we're blazing ahead really fast. They just get very confused when they have to change something in those components and it takes them forever. But the rockstar got to have his fun and play with new tech.
This conception of a "rockstar" isn't a great developer... it's a selfish, cocky developer. When you hear "rockstar" dev, you shouldn't hear great performer. You should think of Keith Moon trashing his hotel room and driving his car into the hotel pool.
A great dev knows the value of documenting their code and writing testable code. A great dev knows the value of taking the extra time to make code easily understood and easily modified -- that sweet spot between spaghetti and over engineering. A great dev loves to mentor junior devs, enjoys walking other devs through their code, is happy to discuss design decisions with the team, and willing to admit when maybe their idea isn't the best one.
A great dev doesn't think they are god's gift to code, they are humble enough to understand they are one part of a team. They put the team first and work hard to teach others what they know, while always remembering they don't know everything.
The idea of a "rockstar" you seem to be referring to has, in my experience, been a dev who can go into a corner and pump out high volumes of code with little supervision or collaboration. That's great, except no one else can make sense of the code they pump out, so when it comes time for the next guy to add a feature to the rockstar's mess it takes 2 to 3 times as long as it should.
I've also had to clean up messes by rockstars who made unilateral decisions about incorporating new technologies into a product. Like building out a single part of the product in React with out asking anyone else. You see, the rockstar didn't like meetings and didn't want to make the case to the rest of the team for why we should all learn React and gradually switch over. Instead, he just stuck it into the code. So now, you have a couple of views built as React components, and the rest of the thing is in Backbone. No one else knows React or has time to learn it, cause we're blazing ahead really fast. They just get very confused when they have to change something in those components and it takes them forever. But the rockstar got to have his fun and play with new tech.
This conception of a "rockstar" isn't a great developer... it's a selfish, cocky developer. When you hear "rockstar" dev, you shouldn't hear great performer. You should think of Keith Moon trashing his hotel room and driving his car into the hotel pool.
A great dev knows the value of documenting their code and writing testable code. A great dev knows the value of taking the extra time to make code easily understood and easily modified -- that sweet spot between spaghetti and over engineering. A great dev loves to mentor junior devs, enjoys walking other devs through their code, is happy to discuss design decisions with the team, and willing to admit when maybe their idea isn't the best one.
A great dev doesn't think they are god's gift to code, they are humble enough to understand they are one part of a team. They put the team first and work hard to teach others what they know, while always remembering they don't know everything.
That's why I've always told people that I'm a "studio musician" developer. Not a rock star, but a competent professional the studio calls when they need to make a record.
That's what I'd been saying for a while -- the best devs are session musicians. They have enough all-around comoetence to deliver what is asked for for that particular recording.
Normaly session musicians are better than rock stars James Jameson (funk brothers) was a better bassist than Paul McCartney, and Paul would admit that.
I have worked with a Musician with Phd in music who taught him self coding after an accident broke all the bones in his feet (drink had been taken)
It was fun in the pub when some hit tracks came on he would say ah I think that's one of mine :-)
I have worked with a Musician with Phd in music who taught him self coding after an accident broke all the bones in his feet (drink had been taken)
It was fun in the pub when some hit tracks came on he would say ah I think that's one of mine :-)
I LOVE THIS MORE THAN YOU COULD EVER BEGIN TO KNOW!
That's great. I like to say I'm a "master carpenter" for the same reason.
Near as I can tell, the term stems from the 80s computer gaming industry, in which the game studio heads got the idea to promote the individual developers by name as if they were rock stars, and oftentimes attempt to treat them to the "rock star lifestyle" (girls, parties, etc.) in order to keep their output from flagging. In those days, games were often written by teams as small as one, and no bigger than a handful -- and the studios themselves were often fly-by-night outfits whose idea of "product packaging" was a Ziploc bag to ship the disk and manual in.
Eventually in the 90s, some developers really took the rock star bit to heart and started plastering their own names all over their output (cf. "John Romero's Daikatana", "American McGee's Whatever-American-McGee-Is-Working-On-Now"), but for the most part, developers at the time hated the rock star characterization.
Eventually in the 90s, some developers really took the rock star bit to heart and started plastering their own names all over their output (cf. "John Romero's Daikatana", "American McGee's Whatever-American-McGee-Is-Working-On-Now"), but for the most part, developers at the time hated the rock star characterization.
Electronic Arts started as an outfit for people like this, as did Activision. It's saddening to see how much their ethos has changed in the ensuing 30-40 years.
Sid Meier's Civilization!
A great dev gets out amongst his user community and finds out the real feelings of those who are using the software. The great dev tries to understand the actual user requirements (not just what has been supplied by the design docs). The great dev listens to the criticisms of the users and discusses what can and can't be done.
I don't disagree with your "great dev" qualities but there is more needed to make a "great dev". Otherwise all the documentation, code ease, mentoring, being a part of the team, etc. is not going to make the code useful to anyone.
I don't disagree with your "great dev" qualities but there is more needed to make a "great dev". Otherwise all the documentation, code ease, mentoring, being a part of the team, etc. is not going to make the code useful to anyone.
The whole "rockstar dev" branding has always made me cringe, but my opinion is software should be made by rock bands. Sometimes you have to play bass and not get laid.
I like to go with master developer and not rockstar for the very reasons you state
Yup, I'll take Gadd over Moon any day.
First off I hate the phrase "Rockstar dev" because it gives the impression that someone can be successful without the support of the team, which is wrong.
Second, I hear this extremely often: Rockstar devs don't like to mentor, Rockstar devs don't like to write documentation, Rockstar devs don't like to write tests.
At what point do you need to reevaluate your definition of a rockstar dev?
The hiring filter is a powerful thing. It allows you to find very special people if you know how to look. It's also a feedback loop. Getting momentum with a program like this is the hardest part. Once it's going it practically self sustains. The biggest part of your role becomes quickly firing any mistakes.
Second, I hear this extremely often: Rockstar devs don't like to mentor, Rockstar devs don't like to write documentation, Rockstar devs don't like to write tests.
At what point do you need to reevaluate your definition of a rockstar dev?
The hiring filter is a powerful thing. It allows you to find very special people if you know how to look. It's also a feedback loop. Getting momentum with a program like this is the hardest part. Once it's going it practically self sustains. The biggest part of your role becomes quickly firing any mistakes.
Related to this: know what you're hiring for.
Are you looking for someone who can parachute in with expertise on a specific tech and churn out working code themselves?
Or are you willing to accept more lag time and less initial code productivity in exchange for a deeper bench and sustainable team?
There are times and places for both of these developer types...
Are you looking for someone who can parachute in with expertise on a specific tech and churn out working code themselves?
Or are you willing to accept more lag time and less initial code productivity in exchange for a deeper bench and sustainable team?
There are times and places for both of these developer types...
You are confusing senior devs and rockstar devs.
Rockstars are lone wolves, write unmaintainable code that works quickly for demos but gives the company pain for years to come as nobody can figure out how to make it stable or maintain it. A rockstar's reputation is self reinforcing because it's easy to get a lot of shit done when one doesn't have to worry about maintainability, communication with the rest of the team members or the company at large, and service.
Senior devs balance development work and "service", a term I'll borrow from academia - hiring, mentoring, speaking, writing docs, etc. They either find fun in these tasks as well (I legit enjoy interviewing and mentoring), or understand this is a necessary part of being a well functioning team player at a senior level.
Rockstars are lone wolves, write unmaintainable code that works quickly for demos but gives the company pain for years to come as nobody can figure out how to make it stable or maintain it. A rockstar's reputation is self reinforcing because it's easy to get a lot of shit done when one doesn't have to worry about maintainability, communication with the rest of the team members or the company at large, and service.
Senior devs balance development work and "service", a term I'll borrow from academia - hiring, mentoring, speaking, writing docs, etc. They either find fun in these tasks as well (I legit enjoy interviewing and mentoring), or understand this is a necessary part of being a well functioning team player at a senior level.
You hire the rockstar to write version 1. That's the one that gets you to market fast, and the one you should be planning on throwing away. It's the one you keep in production as your non-rockstar ninja and guru coders write version 2 from scratch. Once you release version 2, you really need to fire your rockstar. They will never be happy in maintenance mode, and that's fine, because they're usually bad at writing for maintainability.
Then you can hire some boring reliable folks from the khaki-and-polo brigade to help upgrade version 2 to version 3. This is when you have an opportunity to hire juniors and mentor them on what good software actually looks like, and how to make good-enough software better. The ninjas will probably leave at this point, and if they have done their job, the company will never need that level of expertise again in a permanent employee. The gurus will stay on to be an expert in your specific system, and teach the new people how to preserve its grandest traditions.
The problem is that a lot of companies never get to what I call "version 3". They might slap higher release numbers on it every so often, but if they never did a clean re-implementation of the quick-and-dirty prototype, that's still "version 1.X", no matter how high the numbers go. You put a junior in that environment, and they're not going to become a stable maintenance developer, and that's where the majority of the jobs will be for the foreseeable future, especially for inexperienced people.
To sum up: rockstars live fast and die young; ninjas quietly demonstrate incredible skills, and vanish; and gurus are the high priests for your established project, who will eventually pay off all your tech debt, if you let them.
There are different breeds of senior developer, and you really want the gurus teaching juniors when they start to run short of other useful things to do. If you don't have the kind of company that is mature enough to evolve a developer into a guru, you won't be able to handle juniors. And there aren't enough companies that can handle juniors. It may be because they aren't honoring the full software lifecycle that includes the long, long tail of maintenance mode.
Then you can hire some boring reliable folks from the khaki-and-polo brigade to help upgrade version 2 to version 3. This is when you have an opportunity to hire juniors and mentor them on what good software actually looks like, and how to make good-enough software better. The ninjas will probably leave at this point, and if they have done their job, the company will never need that level of expertise again in a permanent employee. The gurus will stay on to be an expert in your specific system, and teach the new people how to preserve its grandest traditions.
The problem is that a lot of companies never get to what I call "version 3". They might slap higher release numbers on it every so often, but if they never did a clean re-implementation of the quick-and-dirty prototype, that's still "version 1.X", no matter how high the numbers go. You put a junior in that environment, and they're not going to become a stable maintenance developer, and that's where the majority of the jobs will be for the foreseeable future, especially for inexperienced people.
To sum up: rockstars live fast and die young; ninjas quietly demonstrate incredible skills, and vanish; and gurus are the high priests for your established project, who will eventually pay off all your tech debt, if you let them.
There are different breeds of senior developer, and you really want the gurus teaching juniors when they start to run short of other useful things to do. If you don't have the kind of company that is mature enough to evolve a developer into a guru, you won't be able to handle juniors. And there aren't enough companies that can handle juniors. It may be because they aren't honoring the full software lifecycle that includes the long, long tail of maintenance mode.
Well said. Especially the "Version 2/3" part.
I think the never getting there often happens because management isn't aware of the current quality of their software vs hypothetical quality of a rewrite.
And I get it: I imagine every one of them has been burned by an overly optimistic developer. "It'll be rewritten in 3 months and run 2x as fast" types.
As a discipline, inculcating "respect that the years of person-work in the current version weren't done by idiots solving unimportant niche use cases" would be very healthy.
I think the never getting there often happens because management isn't aware of the current quality of their software vs hypothetical quality of a rewrite.
And I get it: I imagine every one of them has been burned by an overly optimistic developer. "It'll be rewritten in 3 months and run 2x as fast" types.
As a discipline, inculcating "respect that the years of person-work in the current version weren't done by idiots solving unimportant niche use cases" would be very healthy.
Labels like rockstar, guru and ninja are labels we don't need. We need competent generalists and competent specialists who can work in teams as well as work alone and can communicate with those who are part of the team or part of the management and user bases.
When a person takes on for themselves labels like rockstar, guru, ninja, etc. I don't doubt that they can write code, but I certainly doubt that they can write code that fulfils the needs of those who will be using it.
Labels likes these are a detriment to the profession. If we want businesses to take note and consider those in the IT profession to be anything more than ignored, we need to lift our game a long way.
What is IT known for (in the general sense), games, social media, search engines and lots of crappy software that users have to fight to get anything done.
Yet we have people and companies that produce great software that fulfils the needs of those who use it in a way that is not detrimental to those users.
It's coming up to forty years that I have been involved with the industry and I hear complaints every day from users who are frustrated by the inconsistencies in the software they are using, whether it be social media, business software, games, etc.
In general, as an industry, we are far too arrogant about our own self-importance and what we develop. Whether it be the likes of Apple, Oracle, IBM, Google, etc, the industry has forgotten that they only exist as long as people will tolerate the bull dust that is thrown at them by these companies. We are always looking for the "next big thing", yet many of the actual needs that we could be filling are not being done. We like flashy and not substance.
When a person takes on for themselves labels like rockstar, guru, ninja, etc. I don't doubt that they can write code, but I certainly doubt that they can write code that fulfils the needs of those who will be using it.
Labels likes these are a detriment to the profession. If we want businesses to take note and consider those in the IT profession to be anything more than ignored, we need to lift our game a long way.
What is IT known for (in the general sense), games, social media, search engines and lots of crappy software that users have to fight to get anything done.
Yet we have people and companies that produce great software that fulfils the needs of those who use it in a way that is not detrimental to those users.
It's coming up to forty years that I have been involved with the industry and I hear complaints every day from users who are frustrated by the inconsistencies in the software they are using, whether it be social media, business software, games, etc.
In general, as an industry, we are far too arrogant about our own self-importance and what we develop. Whether it be the likes of Apple, Oracle, IBM, Google, etc, the industry has forgotten that they only exist as long as people will tolerate the bull dust that is thrown at them by these companies. We are always looking for the "next big thing", yet many of the actual needs that we could be filling are not being done. We like flashy and not substance.
We don't need titles like that at all. Let's change rockstar to MVP Developer, Ninja to Builder, Guru to Experienced Builder, and the 3rd type of developer described in GP to Maintenance Developer. I think the industry could go a long way if it admits that it needs all 4 of these types of developers, so that expectations were transparent for employees and needs are transparent for developers.
I object to those terms. The rockstar is most definitely not the MVP. To the extent that I have worked with any, they are the insufferable primo donnos that fill the garbage bin and set it on fire then they proselytize their own trash fire to management until they think it is "hot", "energetic" and "enlightened". The rest of us then get stuck dealing with their legacy issues. If you're going to title-ify it, how about "prototype developer"?
The others can be "foundation developer", "transition developer", and "maintenance developer". It's still meaningless as long as different companies won't standardize on those titles.
We likely all know which category we belong to now, and which one we want to be. We also know that any company that asks directly for a "rockstar", "ninja", or "guru" is probably one to be avoided.
The others can be "foundation developer", "transition developer", and "maintenance developer". It's still meaningless as long as different companies won't standardize on those titles.
We likely all know which category we belong to now, and which one we want to be. We also know that any company that asks directly for a "rockstar", "ninja", or "guru" is probably one to be avoided.
[deleted]
There are those who get it done RIGHT, and those who get it done RIGHT NOW.
Yes to both of these, but there are other options as well.
The frustrating ones are those who talk a good talk about "doing things right" (and, generally, talk a lot...), but then work on something for an age and come back with a solution that's objectively worse than the "RIGHT NOW" solution we've been using in the interim.
The frustrating ones are those who talk a good talk about "doing things right" (and, generally, talk a lot...), but then work on something for an age and come back with a solution that's objectively worse than the "RIGHT NOW" solution we've been using in the interim.
This is one of the best summaries of software development practices I've seen. It's maybe even the way it should work.
A gem of a comment. This is why I come to HN.
Great explanation
vinceguidry(1)
"Most inventors are not professors"
This is not a great example. In academia, that's because they are fundamentally different jobs in most cases.
Most of the professor roles are not teaching their research, and where they are, i would bet your best professors are the inventors. But most are researching x and teaching y.
By contrast, in software development, the devs should be teaching, because what they are teaching is what they are doing on a daily basis, and the knowledge they've learned in how to do that well.
The notion that people who refuse to mentor or attend meetings (assuming these are symptoms of the same "not team player" phenomenon, and not something else) are rockstars is, imho, pretty misguided.
Even if you assume the 10x people silliness is true, each person mentoring 2-3 new people and building them will make the organization more productive than your 10x person fairly quickly.
(Again, situation may be reasonably different if you only will have a team of one or two, etc)
This is not a great example. In academia, that's because they are fundamentally different jobs in most cases.
Most of the professor roles are not teaching their research, and where they are, i would bet your best professors are the inventors. But most are researching x and teaching y.
By contrast, in software development, the devs should be teaching, because what they are teaching is what they are doing on a daily basis, and the knowledge they've learned in how to do that well.
The notion that people who refuse to mentor or attend meetings (assuming these are symptoms of the same "not team player" phenomenon, and not something else) are rockstars is, imho, pretty misguided.
Even if you assume the 10x people silliness is true, each person mentoring 2-3 new people and building them will make the organization more productive than your 10x person fairly quickly.
(Again, situation may be reasonably different if you only will have a team of one or two, etc)
> By contrast, in software development, the devs should be teaching, because what they are teaching is what they are doing on a daily basis, and the knowledge they've learned in how to do that well.
I don't agree, senior tasks are often much more high-level and related to figuring out requirements/stories, or their tasks are hard enough that explaining them to juniors is not the most productive.
I don't agree, senior tasks are often much more high-level and related to figuring out requirements/stories, or their tasks are hard enough that explaining them to juniors is not the most productive.
I'm kind of confused here, so i feel like i missing something.
The way this is written makes feel feel like you you don't think the junior devs need to become competent at those high level tasks over time?
Otherwise, how do they become senior devs if not by things like "gradually delegate higher level work, see what happens, help them learn by mentoring them based on results".
It's not like they read a book and suddenly know how to do that.
"hard enough that explaining them to juniors is not the most productive" I strongly doubt this. Most of the differences i've seen over the years are in approach to complexity, and not level of complexity themselves.
"hard enough that explaining them to juniors is not the most productive" I strongly doubt this. Most of the differences i've seen over the years are in approach to complexity, and not level of complexity themselves.
If you don't want to teach, you're not a rockstar. The best developers I know have always been ready to show and explain what and why and how. Inventors love to talk about their inventions.
Teaching isn't a simple matter you can flatten down to like/dislike.
One aspect of teaching is explaining your inventions to your peers.
But another aspect is telling a new graduate what a version control system is and why you need one. Then doing the same for your build system, continuous integration system, staging environment, code review, bug tracker, style guide, and so on.
Seems to me those are quite different skills - I can easily imagine a person who is good at / enjoys one might not be good at / enjoy the other.
One aspect of teaching is explaining your inventions to your peers.
But another aspect is telling a new graduate what a version control system is and why you need one. Then doing the same for your build system, continuous integration system, staging environment, code review, bug tracker, style guide, and so on.
Seems to me those are quite different skills - I can easily imagine a person who is good at / enjoys one might not be good at / enjoy the other.
To a first approximation there is no such thing as a "rockstar" developer. I mean a few of them exist, but the actual stars (not poseur wannabes) are already locked down doing other things so it isn't possible to hire them anyway. If you're hiring or building a team you have to target developers who are actually available, not the stars.
Thus the need to hire junior developers. Some very small percentage of them will turn out to be rockstars, and they'll already be working for you.
[deleted]
I love that you pointed out the need for political strength within organizations. I agree, and I think it directly conflicts with this line from the post:
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.
Having the admiration and respect of the next generation of developers at your company offers far more leverage than the nebulous prestige. If you mentor three engineers, that's three warm bodies at your company who will have good things to say when asked about you. If you do a good job, you now have a team of four capable engineers who can get things done.
What could provide more organizational political power than building a hierarchy of capable engineers that consistently come to you when they need help?
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.
Having the admiration and respect of the next generation of developers at your company offers far more leverage than the nebulous prestige. If you mentor three engineers, that's three warm bodies at your company who will have good things to say when asked about you. If you do a good job, you now have a team of four capable engineers who can get things done.
What could provide more organizational political power than building a hierarchy of capable engineers that consistently come to you when they need help?
> Having the admiration and respect of the next generation of developers at your company offers far more leverage than the nebulous prestige
“Prestige” and “respect” are essentially synonyms, and careerwise respect of developers in the org often is not as important as respect of management.
> What could provide more organizational political power than building a hierarchy of capable engineers that consistently come to you when they need help?
Being perceived by management as delivering results rather than being the one behind the scenes enabling others to be perceived that way.
“Prestige” and “respect” are essentially synonyms, and careerwise respect of developers in the org often is not as important as respect of management.
> What could provide more organizational political power than building a hierarchy of capable engineers that consistently come to you when they need help?
Being perceived by management as delivering results rather than being the one behind the scenes enabling others to be perceived that way.
> Being perceived by management as delivering results rather than being the one behind the scenes enabling others to be perceived that way.
This is essentially a synonym of the sentence you quoted
> careerwise respect of developers in the org often is not as important as respect of management
You're missing the point. By mentoring developers you become de facto management; it's willful, benevolent career advancement.
This is essentially a synonym of the sentence you quoted
> careerwise respect of developers in the org often is not as important as respect of management
You're missing the point. By mentoring developers you become de facto management; it's willful, benevolent career advancement.
Wait until you get old (past 35), I'm a woman (ex web deck "ninja/rockstar/etc") and I can safely say the ageist comments are far worse.
No one believes you can keep up the development sprints, or new technologies.
No one believes you can keep up the development sprints, or new technologies.
Molly, you are so right. And this is why internships are a bunch of hooey too. ("hooey" only in the supposedly merit-based on-ramp sense- of course they're valuable for teaching and learning and building a great team) The entire process toward getting tech job is ageist if all we have to offer "junior devs" is the internship role. (all the ads say that interns must be recent graduates or currently enrolled in an undergrad CS program) Nevermind if that's even legal. We know legality doesn't come into it until a whole movement and hashtag gets going. The ageism is sickening. It does seem that those who are the most ageist may suffer the consequences of their culture later. For example, it's interesting that Facebook is now officially the "old(er) person's social media" according to The Guardian and many other sources this week. Do note that "old" had to be changed in rewrite to "old(er)" in the paper, so as not to appear as fully insulting and ageist as the statement to address the data actually is.
I'm a little older but I'm only 6 years in the industry. I worked at a job where they were using technologies from 10 years ago, i.e. tons of custom PHP5 and MySQL on top of Wordpress, while I took the time to learn Angular, Node.js, MongoDB, Postgres, React, and modern tooling like Grunt and Webpack -- this list can go on and on. Now I have a situation where I had to go back in time and learn how to do things 4 years before I started hacking and everyone in any position of power is treating me like I'm a threat. I open my mouth at a meeting and someone will immediately shut me down. At every corner, I'm being mansplained to and I'm a man.
> Wait until you get old (past 35)
39 never noticed anything. Where do you work?
39 never noticed anything. Where do you work?
Don't see anything said that's incompatible with the 'Den mother' stigma. If its about pay and promotion, not about being friendly with Engineers, then you want to avoid the role that won't be respected.
You can't imagine all the ways management can dismiss women's actions - "she's a great connector in that department. Let's leave her there, that's working great." or "sure she's got all the guys eating out of her hand. But lets talk leadership - Bob has got everybody afraid of him! Lets promote Bob"
You can't imagine all the ways management can dismiss women's actions - "she's a great connector in that department. Let's leave her there, that's working great." or "sure she's got all the guys eating out of her hand. But lets talk leadership - Bob has got everybody afraid of him! Lets promote Bob"
If its about pay and promotion
Pay and promotion is about making yourself valuable. If you mentor engineers and gain a reputation for doing so, you're effectively shaping the culture of the organization, not to mention gives you a ton of leverage with the productive employees you taught to be productive.
It makes you far less disposable. When mixed with even amateur negotiating skills, that leads to promotion and better pay.
Pay and promotion is about making yourself valuable. If you mentor engineers and gain a reputation for doing so, you're effectively shaping the culture of the organization, not to mention gives you a ton of leverage with the productive employees you taught to be productive.
It makes you far less disposable. When mixed with even amateur negotiating skills, that leads to promotion and better pay.
If you ignore the part about stigmatizing, which happens to women by default, then sure. An objective management team would act as described.
But the 'den mother' comment comes out of a real issue, of womens roles being sidelined. One pragmatic response is to avoid roles that feed into the stereotype.
In a better world, this would not be a thing. But here we are.
But the 'den mother' comment comes out of a real issue, of womens roles being sidelined. One pragmatic response is to avoid roles that feed into the stereotype.
In a better world, this would not be a thing. But here we are.
One pragmatic response is to avoid roles that feed into the stereotype.
You make a good point, and I agree with the pragmatism of the choice, but I also believe mentorship can be a means of advancement.
The point of my original comment was to advocate for another choice - one that will both advance the mentor and their proteges. Hopefully, this will give us that better world we're looking for.
You make a good point, and I agree with the pragmatism of the choice, but I also believe mentorship can be a means of advancement.
The point of my original comment was to advocate for another choice - one that will both advance the mentor and their proteges. Hopefully, this will give us that better world we're looking for.
If you're mentoring jr devs ten it's going to be years before they rise up high enough to have any influence on you getting promotion.
Depends if the leaders even care what 3 junior devs think.
The leaders will care a great deal if the three devs are well trained and capable.
The leaders should care a great deal.
> always had to lie, cheat, and steal your way into the field
Back in the 90's, when I wanted to move up to working with C++ (the hip, new, "in" thing at the time), I bought a book about C++, read through it, worked the examples, and then started interviewing. The interviewers asked all sorts of arcane questions that I hadn't come across in my few months of study, so I was tanking the interviews. The trick I figured out back then, though, was that the interviewers all tended to ask the same sorts of questions - so after getting my rejection, I'd go look up what the answers to all their questions were so that the next time I was asked the same question, I'd know the answer. I did eventually get a job doing C++ (and did well at it), but... yeah, looking back it was maybe a little bit dishonest.
Back in the 90's, when I wanted to move up to working with C++ (the hip, new, "in" thing at the time), I bought a book about C++, read through it, worked the examples, and then started interviewing. The interviewers asked all sorts of arcane questions that I hadn't come across in my few months of study, so I was tanking the interviews. The trick I figured out back then, though, was that the interviewers all tended to ask the same sorts of questions - so after getting my rejection, I'd go look up what the answers to all their questions were so that the next time I was asked the same question, I'd know the answer. I did eventually get a job doing C++ (and did well at it), but... yeah, looking back it was maybe a little bit dishonest.
Your story reminds me of the joke/anecdote of the way to cheat on tests. You religiously look over your notes and the textbook in the weeks leading up to the test, so that when you take the test it's like you have a comprehensive cheat sheet with you, but in your head.
If the hiring process wasn't able to distinguish between you or who they thought they were looking for, then it wasn't your responsibility to inform them of it.
If the hiring process wasn't able to distinguish between you or who they thought they were looking for, then it wasn't your responsibility to inform them of it.
Reminds me of this skit: http://www.cc.com/video-clips/acaxis/key-and-peele-the-heist
I may be dense here, but what's the difference between a cheat sheet in your head and actually knowing the topic?
That's the point of joke/anecdote. By studying you know the material and don't have to cheat, but the "tip" is voiced by someone more accustomed to cheating than studying, and so it's framed as a dishonest strategy.
That's the joke he referenced. Although there is a difference between knowing something and memorizing answers.
Knowing canned answers vs being able to come up with it yourself.
Well, thank you for your (intentional?) kindness, but back then I did sort of misrepresent how well I understood the language.
this happens in an episode of the simpsons except he studies on accident by getting locked in a closet.
Eh, sounds like smart preparation to play the game on its terms. Did those questions end up being seriously relevant to the work? If so, then you prepared yourself better for the job by learning the answers. If not, well, then maybe it's the interviewers who weren't so honest.
> Did those questions end up being seriously relevant to the work?
Oh, God no. I've never been asked a question in a job interview that was in any way relevant to the work I actually ended up doing.
Oh, God no. I've never been asked a question in a job interview that was in any way relevant to the work I actually ended up doing.
Only one question has ever been relevant for me. It was about map reduce for locations and the job was using map reduce on location data...
At the job I have now, they spent the whole interview session asking about Python, Scala, machine learning, natural language processing, Spark and Hadoop clustering. I've been doing Angular 2 front-end work since I started.
I would argue that the kind of person with the skill to navigate into a position, is more likely than the person not, to be able to pick up things faster. So the fact that you may not hit the ground running does not matter so much as your attitude and ability to learn quick. Well done.
What you talk about indicates there is a gap between what industry wants/expects and what you learn either from books or in college.
It's only dishonest if you send in a fake interviewee before you in order to get the questions.
> accountants leave school fully capable of employment
Well, fully capable of entry-level employment. Anyone who graduates from a reputable school with a Comp. Sci. or InfoSys type of major is also fully capable of entry-level employment.
Accountants aren't really capable of anything but grunt work until they pass the CPA which normally is after several years of grunt work and additional learning and study.
Programmers aren't much good in a business until after several years of actually programming business systems.
It doesn't seem to hard to understand to me, in fact they seem quite similar.
Well, fully capable of entry-level employment. Anyone who graduates from a reputable school with a Comp. Sci. or InfoSys type of major is also fully capable of entry-level employment.
Accountants aren't really capable of anything but grunt work until they pass the CPA which normally is after several years of grunt work and additional learning and study.
Programmers aren't much good in a business until after several years of actually programming business systems.
It doesn't seem to hard to understand to me, in fact they seem quite similar.
> Anyone who graduates from a reputable school with a Comp. Sci. or InfoSys type of major is also fully capable of entry-level employment.
No, they're really not, for at least a year. It takes at least that long for most new graduates to get over the hump and learn enough of the practical skills and industry practices that their university left them woefully ignorant of, so that they can start being marginally useful. Once in a while you find somebody who has been doing real work on the side for years during or before college, and thus has a clue how things work, but that's a diamond in the rough, usually.
And unfortunately, many of them just can't hack being a professional programmer, and they never get to the point where they become a net positive, in which case you just hope they leave of their own volition or you can silo them off in some area of little importance that won't cause you problems down the road.
No, they're really not, for at least a year. It takes at least that long for most new graduates to get over the hump and learn enough of the practical skills and industry practices that their university left them woefully ignorant of, so that they can start being marginally useful. Once in a while you find somebody who has been doing real work on the side for years during or before college, and thus has a clue how things work, but that's a diamond in the rough, usually.
And unfortunately, many of them just can't hack being a professional programmer, and they never get to the point where they become a net positive, in which case you just hope they leave of their own volition or you can silo them off in some area of little importance that won't cause you problems down the road.
>or at least a year. It takes at least that long for most new graduates to get over the hump and learn enough of the practical skills and industry practices that their university left them woefully ignorant of, so that they can start being marginally usefu
A year?!
You're either scraping the bottom of the barrel for new hires, have a terrible on-boarding process, over-estimating the difference between the code someone fresh out of college writes or have absolutely terrible documentation or some combination thereof.
I'm leaning toward on-boarding and/or documentation. Junior devs are the ones who most need documentation because they're not gonna be able to infer the existence of policy and best practices from existing code and procedures as well as a senior dev will.
Either you and your HR is doing a terrible job giving new hires a lead on what to be asking and where to find information or that information just doesn't exist outside of the heads of existing employees.
I work at a CDN. We have plenty of issues with legacy code, cumbersome interactions between business units, outdated policies/docs, lack of documentation on stuff and all the other BigCo problems.
A huge chunk of new hires at any time are fresh out of school. It takes ~3-4mo before they're dealing with stuff on their own with perfectly fine results.
People aren't idiots but they don't know what they don't know. People with more experience are better at knowing when there's something that they don't know. Fix your process and you'll be able to get good value for junior devs.
If you don't fix your process don't whine when someone who has business practices that let them deliver the same results at lower cost by utilizing cheaper labor comes along and undercuts you.
A year?!
You're either scraping the bottom of the barrel for new hires, have a terrible on-boarding process, over-estimating the difference between the code someone fresh out of college writes or have absolutely terrible documentation or some combination thereof.
I'm leaning toward on-boarding and/or documentation. Junior devs are the ones who most need documentation because they're not gonna be able to infer the existence of policy and best practices from existing code and procedures as well as a senior dev will.
Either you and your HR is doing a terrible job giving new hires a lead on what to be asking and where to find information or that information just doesn't exist outside of the heads of existing employees.
I work at a CDN. We have plenty of issues with legacy code, cumbersome interactions between business units, outdated policies/docs, lack of documentation on stuff and all the other BigCo problems.
A huge chunk of new hires at any time are fresh out of school. It takes ~3-4mo before they're dealing with stuff on their own with perfectly fine results.
People aren't idiots but they don't know what they don't know. People with more experience are better at knowing when there's something that they don't know. Fix your process and you'll be able to get good value for junior devs.
If you don't fix your process don't whine when someone who has business practices that let them deliver the same results at lower cost by utilizing cheaper labor comes along and undercuts you.
No, they're really not, for at least a year.
Isn't that the definition of entry-level or junior?
FWIW, the four recent graduates I hired this summer are all capable of completing well-defined programming tasks with minimal assistance. Does that mean I spend more time with my PO ensuring those tasks are well-defined and consumable by the new developers? Yeah (but that's our job). Do the senior team members spend part of their day mentoring? Yeah (but that's their job).
As for some of them not hacking it. Yeah that's true. But, I've also interviewed plenty of "senior devs" who were terrible. I've even hired one or two who didn't work out. I just do my best to avoid hiring them.
Isn't that the definition of entry-level or junior?
FWIW, the four recent graduates I hired this summer are all capable of completing well-defined programming tasks with minimal assistance. Does that mean I spend more time with my PO ensuring those tasks are well-defined and consumable by the new developers? Yeah (but that's our job). Do the senior team members spend part of their day mentoring? Yeah (but that's their job).
As for some of them not hacking it. Yeah that's true. But, I've also interviewed plenty of "senior devs" who were terrible. I've even hired one or two who didn't work out. I just do my best to avoid hiring them.
All of those things comprise "entry level" to me. Maybe we have differnent concepts of what an "entry level" job is. To me, entry level == first job. The candidate has been a student but never a professional. They won't have practical skills or much knowledge of industry practices.
I'm not an accountant but I did do a business minor and I don't see this being much different for new accountant hires vs. new developer hires.
I'm not an accountant but I did do a business minor and I don't see this being much different for new accountant hires vs. new developer hires.
I worked with and later became a “student programmer” when I was in college. I had classes with some of these guys and I would ask them how long the homework took. “2 hours”? That’s crazy. It took me 10 and I knew people who were 15 hours in and not done yet.
Then I got on a new project as a dev. Within months I was down to 3-4 hours for similar assignments. My last class at school was the first time we had a shortage of hardware (good school). I would sit at home and remote into one of the machines, get my code to compile and show up to the lab the afternoon before it was due to debug. And everybody looked at me like I looked at my old coworkers.
It’s been a while since I’ve talked to undergrads but I always tell them to beg borrow or steal an internship or a job on campus. You have no idea how far a little concrete experience takes you.
Then I got on a new project as a dev. Within months I was down to 3-4 hours for similar assignments. My last class at school was the first time we had a shortage of hardware (good school). I would sit at home and remote into one of the machines, get my code to compile and show up to the lab the afternoon before it was due to debug. And everybody looked at me like I looked at my old coworkers.
It’s been a while since I’ve talked to undergrads but I always tell them to beg borrow or steal an internship or a job on campus. You have no idea how far a little concrete experience takes you.
Yeah, there was a great incentive to get done with the homework fast, because then you could get back to writing scripted mob behaviors and quest scripts for your MUD.
Finish with the boring programming, and you get to do fun programming.
Finish with the boring programming, and you get to do fun programming.
>Once in a while you find somebody who has been doing real work on the side for years during or before college, and thus has a clue how things work, but that's a diamond in the rough, usually.
Can you define "real work"?
Can you define "real work"?
I assume essentially anything that isn't a school assignment.
Something built for a need--whether profitable business, or personal need--tends to provide more meaningful experience than a "write this contrived program to learn how [specific programming functionality] works" project.
Something built for a need--whether profitable business, or personal need--tends to provide more meaningful experience than a "write this contrived program to learn how [specific programming functionality] works" project.
Code schools try to solve this problem. But they need to become an actual structural part of the industry before companies can really start to rely on them.
They seem to be on the other side of the extreme though.
Ok, the first part of your comment makes no sense to me. How do you lie your way into a certification? An interview I can understand, but don't you have to take a test to get a cert?
From the second paragraph down, you're absolutely right for non-software companies. They still don't have an understanding of how to build software development into their business model. They don't realize that the low barrier entry to building software does not mean it is a low-cost, low-risk endeavor, nor do they understand how to extract value from a completed software project. They go straight from "Bob the executive has a cool idea," to, "Let's hire 3 full-time devs."
From the second paragraph down, you're absolutely right for non-software companies. They still don't have an understanding of how to build software development into their business model. They don't realize that the low barrier entry to building software does not mean it is a low-cost, low-risk endeavor, nor do they understand how to extract value from a completed software project. They go straight from "Bob the executive has a cool idea," to, "Let's hire 3 full-time devs."
The Magento Certification tests are so divorced from the skills and reality of developing a Magento site and the study materials are so, so, so bad that most organizations just send a couple of canaries to take the cert expecting them to fail, then based on the questions they saw the org will put together their own memorization based study materials and train other devs using their own internal docs.
THIS IS INTENTIONAL on the part of Magento. They want a high fail rate. It ensures that only orgs with lots of money (who can afford a couple failures) will get a large number of certs and become official Magento partners, and since you pay for each test more failures means more money.
They have carefully structured the cert so that about 1/2 the questions are actual general skills and useful knowledge for working with the framework and about 1/2 are rote memorization such as, "What is the EXACT class name and Method Name that does X?" where options are
My_Basic_Class_Car::doThing() My_Basics_For_Class_Car::doThings() My_Class_For_Car::doThing() My_Class_for_Cars::doThings()
You need like 75% to pass... so if you're really lucky you can guess your way through the memorization portion but 90% won't pass on their first try.
If I were a hiring manager looking at a candidate with a Magento cert I could glean 1 of 2 things:
1) This person took the cert independently and cared enough to cheat or pay a lot of money to get it.
2) This person worked at an org with enough institutional knowledge of Magento and their payola process that they probably learned SOMETHING while they were there.
THIS IS INTENTIONAL on the part of Magento. They want a high fail rate. It ensures that only orgs with lots of money (who can afford a couple failures) will get a large number of certs and become official Magento partners, and since you pay for each test more failures means more money.
They have carefully structured the cert so that about 1/2 the questions are actual general skills and useful knowledge for working with the framework and about 1/2 are rote memorization such as, "What is the EXACT class name and Method Name that does X?" where options are
My_Basic_Class_Car::doThing() My_Basics_For_Class_Car::doThings() My_Class_For_Car::doThing() My_Class_for_Cars::doThings()
You need like 75% to pass... so if you're really lucky you can guess your way through the memorization portion but 90% won't pass on their first try.
If I were a hiring manager looking at a candidate with a Magento cert I could glean 1 of 2 things:
1) This person took the cert independently and cared enough to cheat or pay a lot of money to get it.
2) This person worked at an org with enough institutional knowledge of Magento and their payola process that they probably learned SOMETHING while they were there.
I should have said cheated, he got a copy of the first part of the test and memorized it. The second part of it which requires actual coding he barely passed.
1) The test itself is randomly generated from a huge set of master questions many of which are actually IN the study materials. Everyone studies "from a copy of the test". Its like saying you cheated at a spelling bee because you memorized the dictionary.
2) There are several parts to the exam but none of them involve an evaluation of how you write code, its all multiple choice.
3) The cert itself and studying for it doesn't prepare you for actually building a Magento site in any way. The Magento certification program is really just a way for businesses to get access to "leads" and get free advertising from Magento. Having more certs just helps a company look good.
4) If your buddy is experiencing a lot turnover my experience of the eCommerce industry and Magento shops specifically is that they are more inclined to put a heavy emphasis on "culture fit" and be high stress environments. They say, "If you see assholes everywhere, maybe you should look in mirror..." but it might just be your friend is experiencing the reality that eCommerce development is NOT the same environment as the Wordpress chop shops he may have started in.
2) There are several parts to the exam but none of them involve an evaluation of how you write code, its all multiple choice.
3) The cert itself and studying for it doesn't prepare you for actually building a Magento site in any way. The Magento certification program is really just a way for businesses to get access to "leads" and get free advertising from Magento. Having more certs just helps a company look good.
4) If your buddy is experiencing a lot turnover my experience of the eCommerce industry and Magento shops specifically is that they are more inclined to put a heavy emphasis on "culture fit" and be high stress environments. They say, "If you see assholes everywhere, maybe you should look in mirror..." but it might just be your friend is experiencing the reality that eCommerce development is NOT the same environment as the Wordpress chop shops he may have started in.
You can get through a Magento certification by memorizing the answers that are all over the internet, http://magecert.com ect.
Most certification programs can be gamed. Generally there is a simulator - if you play enough with it and memorize the questions you will nail 60% or more in the official test. Take the test a few times and luck will kick-in.
Last year I worked with a certified LPIC-3 system administrator and deploying a trivial wordpress website at AWS took him 1 week. He was fired 1 month later. His CV is very impressive with lots of certification badges (I checked the codes of several badges and he is really certified).
Last year I worked with a certified LPIC-3 system administrator and deploying a trivial wordpress website at AWS took him 1 week. He was fired 1 month later. His CV is very impressive with lots of certification badges (I checked the codes of several badges and he is really certified).
[deleted]
What do you suggest for those of us who believe we would be terrible at management? Add to that, I also think I would be miserable doing it.
Find an employer that values career programmers? We have a "Technical Fellow" career path for devs/engineers/architects who want to remain in a technical role beyond the typical "tech lead" or "principle whatever" roles.
I've come to terms that I want to be a developer for as long as possible.
This thread can also help: https://news.ycombinator.com/item?id=7372997
This thread can also help: https://news.ycombinator.com/item?id=7372997
Open your own consulting firm. The people you contract with, generally will not care if you're a 55 year old programmer so long as you can get the job done on time and on budget. Further, as you grow the business, you create your own security, as you can eventually turn yourself into more of a business owner/operator/manager, than only a programmer. This is one of the better ways to beat ageism in tech.
Subscribe to Rands' blog, read through his archives, and get on his Slack.
http://randsinrepose.com/
https://rands-leadership.slack.com/?redir=%2Fmessages%2Fgene...
http://randsinrepose.com/
https://rands-leadership.slack.com/?redir=%2Fmessages%2Fgene...
That the system is stacked against us.
[deleted]
Nah this is not true. I started out as a junior dev and remained a junior dev for many years. I've progressed through the ranks over time by continuing to learn new concepts and tools, to observe my mentors and managers, and to adapt.
There may be environments like Silicon Valley where companies lean towards experience, but I can tell you in the Chicago areas University of Illinois and other comp-sci graduates get hired consistently.
It's too complex of an issue to throw a blanket over it. The market matters, the person matters, and the hiring team matters.
I don't believe there's any inherent bias against hiring junior developers. It all depends on a company's needs.
There may be environments like Silicon Valley where companies lean towards experience, but I can tell you in the Chicago areas University of Illinois and other comp-sci graduates get hired consistently.
It's too complex of an issue to throw a blanket over it. The market matters, the person matters, and the hiring team matters.
I don't believe there's any inherent bias against hiring junior developers. It all depends on a company's needs.
Depends on the business of course. Try getting interviewed by competent developers, they'll quickly find the holes.
I used to believe this, now I'm skeptical. Even if they find holes in the developer's competence, interviewing is not a task, it's a business process orchestrated and controlled by middle management. Say the competent developer finds holes in the interviewee's knowledge and skills, his findings become a line item in the report passed up to said middle management.
The middle manager, hopefully not in HR, has to weigh all the items in the report, and as a result the actual skill level of the developer gets buried deep, under cultural factors and attitude. There's also the human aspect, does Jimmy Mid-Level know how to raise issues with an interviewee's competence convincingly? If he doesn't, his concerns are likely to get written off.
This all ties back to the lack of political cover that software development shops in non-technically oriented organizations usually exhibit. Developers need to be in those middle management positions if they want their concerns to be taken seriously.
The middle manager, hopefully not in HR, has to weigh all the items in the report, and as a result the actual skill level of the developer gets buried deep, under cultural factors and attitude. There's also the human aspect, does Jimmy Mid-Level know how to raise issues with an interviewee's competence convincingly? If he doesn't, his concerns are likely to get written off.
This all ties back to the lack of political cover that software development shops in non-technically oriented organizations usually exhibit. Developers need to be in those middle management positions if they want their concerns to be taken seriously.
This is a symptom of managers not understanding the jobs of the people they're managing. I don't know if that kind of management works under any circumstances, but it definitely can't work if people who don't understand programming (and I specifically mean programming, no matter how well they understand the rest of a developer's job) are managing junior developers.
Of course it is. But in most organizations, managers do not understand software development. That competence is extremely hard to hire.
I'm fortunate to work for a manager who is a half-time developer. He's really good at interviewing people, and finding out if they're what we want.
This is why it's imperative that software devs get on the management track.
So true! My first (student) job..10 years ago... I landed because of personal recommendation through a friend and yeah, for the rest I built on that. Confirming what you say about politics, all following jobs there was a lot of of it involved rendering the jobs eventually mechanic/boring.
Especially the non-technical people at the places had really unrealistic understandings of IT and DEV in particular to a degree that tech colleagues thought everybody in MGMT must be completely stupid or insane. After having left these places after some time it's just funny.
And yes, for many non-tech people hiring Junior devs is no option in my experience. No idea what these people think, but maybe this is then changing as tech becomes more relevant.. ;)
Especially the non-technical people at the places had really unrealistic understandings of IT and DEV in particular to a degree that tech colleagues thought everybody in MGMT must be completely stupid or insane. After having left these places after some time it's just funny.
And yes, for many non-tech people hiring Junior devs is no option in my experience. No idea what these people think, but maybe this is then changing as tech becomes more relevant.. ;)
> You have always had to lie, cheat, and steal your way into the field.
This terrifies me in terms of my rewriting my resume for my next job cycle. Is any minuscule semblance of honesty on a resume completely dead as a zombie shot through the brain?
I'm serious here. If I have never used XYZ tech, should I list that as a matter of course now should the position require it, and then fudge the results with a few searches and try-out "tests"?
In "current year": "I know what color it is" truly makes me an expert if I can snake-oil my way into it?
This terrifies me in terms of my rewriting my resume for my next job cycle. Is any minuscule semblance of honesty on a resume completely dead as a zombie shot through the brain?
I'm serious here. If I have never used XYZ tech, should I list that as a matter of course now should the position require it, and then fudge the results with a few searches and try-out "tests"?
In "current year": "I know what color it is" truly makes me an expert if I can snake-oil my way into it?
"Fake it 'till you make it," is a statement of pure wisdom, at least with regards to success in America. Especially in IT.
[deleted]
It seems to me that it's not uncommon for upper management to try to goad developers (and others) into becoming managers.. The catch is that it involves lots of free work by taking on increased responsibility with no increased pay. So I suspect most developers will think that it's not worth the hassle.
This might be a tech company vs. IT cost center in a traditional business thing. What major tech companies don’t have internship and new grad recruiting operations? Netflix is the only one I can think of.
I love mentoring. I always have. I used to help out other kids in my high school programming classes. Despite holding several high-level software development positions, what is the total number of times I've been asked by management to mentor more junior folks?
Zero.
I did it because I love sharing knowledge and I like seeing looks of understanding appear on my colleagues' faces when they "get something" for the first time.
The short-termism that's infested our culture--it seems like all Western culture--is truly sickening. It feels like "Well, I got mine, screw the next generation." This goes way beyond just junior developers.
Zero.
I did it because I love sharing knowledge and I like seeing looks of understanding appear on my colleagues' faces when they "get something" for the first time.
The short-termism that's infested our culture--it seems like all Western culture--is truly sickening. It feels like "Well, I got mine, screw the next generation." This goes way beyond just junior developers.
I feel like the current trend of agile development process common in startups now somewhat works against senior devs' interests to mentor junior devs. There simply isn't time allocated for this. Senior devs are held accountable for what they deliver, and doing so on time. This is among other things like code reviewing PRs and attending meetings. For most senior devs working under this circumstance, the best they could do is answer questions of junior devs when they ask them.
I was fortunate enough to be moved into a lead role at the current place after a few months, and expectation of my amount of individual-contribution is set lower than that of other IC members of the team. This has allowed me to spend a little more time on mentoring junior devs. I can see that for other senior devs, it simply isn't realistic to expect them to spend time on mentoring, with the agile schedule. This is how I had felt myself before moving to the team lead role.
I was fortunate enough to be moved into a lead role at the current place after a few months, and expectation of my amount of individual-contribution is set lower than that of other IC members of the team. This has allowed me to spend a little more time on mentoring junior devs. I can see that for other senior devs, it simply isn't realistic to expect them to spend time on mentoring, with the agile schedule. This is how I had felt myself before moving to the team lead role.
> I feel like the current trend of agile development process common in startups now somewhat works against senior devs' interests to mentor junior devs. There simply isn't time allocated for this.
If you're a senior dev, you should be gaming the system a bit to create the time needed to fulfill your role. Never let the keeners fill your time up to 100%, unless it's truly neccessary. There's always going to be some infrastructure that needs fixing, research that needs doing, refactoring that should happen, etc. And you should always have some slack for mentoring and whiteboard discussions.
I almost always start an agile sprint with a self-generated task or two already in my queue for just this reason.
If you're a senior dev, you should be gaming the system a bit to create the time needed to fulfill your role. Never let the keeners fill your time up to 100%, unless it's truly neccessary. There's always going to be some infrastructure that needs fixing, research that needs doing, refactoring that should happen, etc. And you should always have some slack for mentoring and whiteboard discussions.
I almost always start an agile sprint with a self-generated task or two already in my queue for just this reason.
If the system has to be gamed to achieve the best results for your team then the system is flawed.
The system is flawed.
My team counts new devs and juniors as 1/2 person from a point perspective when we are doing planning. Juniors usually get this sand bag until we start beating our sprint goals again.
Perpetually flawed. No matter how much resources you throw at fixing it.
There's a huge difference between "no system is perfect" and "the dominant process for development work in our industry completely ignores work that nurtures employees into being better employees."
The goal of agile, as implemented in most shops, is to get things done quickly and to establish a reporting cadence with management.
Nurturing employees, and indeed software quality, is the product of company and team culture.
The development process is concrete (and “SMART”), so that’s what many managers focus on. The cultural aspects are more nebulous, so they are ignored.
Nurturing employees, and indeed software quality, is the product of company and team culture.
The development process is concrete (and “SMART”), so that’s what many managers focus on. The cultural aspects are more nebulous, so they are ignored.
"...and a whole bunch of other important things."
Always.
The system sets the board rules. You play the game. No system will ever play for you.
Working in an agile team at the moment. I have zero time to be able to help the junior members of the team. Having a mentor is important but having a good mentor, somebody with the right skills and attitude is crucial. I'm watching helpless as the junior Devs take advice from the worst possible sources because they are the ones with the free time
I doubt that agile is the problem here. I've seen organizations which weren't even agile having the exact same problem, not just for devs. It's pretty much the same with manager/project manager positions.
I think a much better explanation is outsourcing. A company which does a lot of outsourcing only needs a few people managing the partners. Managing an outsourcing partner is next to impossible for a junior as they lack the crucial experience. So they try to focus an experienced personnel. I don't know if that is the way outsourcing is supposed to be done, but at least its the way I have experienced it.
There might be other reasons for this senior-only sickness, but I am pretty sure pointing at agile is the wrong direction. If you are unhappy with the 'agile schedule', maybe its time for
> Responding to change over following a plan
I think a much better explanation is outsourcing. A company which does a lot of outsourcing only needs a few people managing the partners. Managing an outsourcing partner is next to impossible for a junior as they lack the crucial experience. So they try to focus an experienced personnel. I don't know if that is the way outsourcing is supposed to be done, but at least its the way I have experienced it.
There might be other reasons for this senior-only sickness, but I am pretty sure pointing at agile is the wrong direction. If you are unhappy with the 'agile schedule', maybe its time for
> Responding to change over following a plan
Agile doesn't really foster collaboration in general. You can't have one ticket assigned to two developers and have them pair program, from the business perspective rather than the best way to develop inexpensive new talent pair coding is a massive waste of time and resources. However agile works really well for remote workers who have little social contact outside of the daily standups and slack. It helps to be an autodidact in the industry in general no matter where your skill level is. I've had kids with almost no experience smoke me on react because we were both having to learn it at the same time and the kid was a better autodidact than me.
Actually you can have a ticket applied to more than one person in an agile process. You must've been thinking of Scrum in particular which does not allow the practice.
(The original agile process called Extreme Programming actually mandated pairs.)
Indeed, a task not budgeted in time is not done. That pertains to tests, static quality analysis, performance optimizations and use case analysis. None of these are explicitly budgeted in agile processes, though they say "write tests" or "definition of done", these are taken as suggestions.
(The original agile process called Extreme Programming actually mandated pairs.)
Indeed, a task not budgeted in time is not done. That pertains to tests, static quality analysis, performance optimizations and use case analysis. None of these are explicitly budgeted in agile processes, though they say "write tests" or "definition of done", these are taken as suggestions.
Strongly agree. I would like to spend more time teaching junior developers what I know. But anything that slows down a small, agile startup can mean the death of the startup, so this tends to undercut my ability to do any kind of mentoring.
Excerpt from a real life situation I was in:
===========================
June of 2015:
Sital was a beginner. In general, there is nothing wrong with being a beginner. All of us are beginners at some point. And for the most part, I think corporations in the USA can do more facilitate apprenticeships to help people start their careers. However, we were a startup that needed to move fast. Could we succeed when we had a beginner in a critical role? I had doubts.
July of 2015:
I felt no sympathy for John. Hiring Sital had been his call, as was failing to hire Arthur. These last few weeks had offered plenty of evidence that Sital was a liability to the team. If John wanted to stick with Sital, he would have to live with the consequences.
I would feel very differently if Celolot had a formal commitment to an apprenticeship program, and if I had clearly been given the responsibility of running that program. And I do think corporations in the USA can do more to help people start their careers. But it was ridiculous to both want to run an aggressive schedule and also train a beginner. The one contradicts the other.
https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...
Excerpt from a real life situation I was in:
===========================
June of 2015:
Sital was a beginner. In general, there is nothing wrong with being a beginner. All of us are beginners at some point. And for the most part, I think corporations in the USA can do more facilitate apprenticeships to help people start their careers. However, we were a startup that needed to move fast. Could we succeed when we had a beginner in a critical role? I had doubts.
July of 2015:
I felt no sympathy for John. Hiring Sital had been his call, as was failing to hire Arthur. These last few weeks had offered plenty of evidence that Sital was a liability to the team. If John wanted to stick with Sital, he would have to live with the consequences.
I would feel very differently if Celolot had a formal commitment to an apprenticeship program, and if I had clearly been given the responsibility of running that program. And I do think corporations in the USA can do more to help people start their careers. But it was ridiculous to both want to run an aggressive schedule and also train a beginner. The one contradicts the other.
https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...
> Could we succeed when we had a beginner in a critical role?
This is core issue. This has nothing to do with startup team vs team in corporation. Neither can have beginner in a critical difficult role. Both can make use of junior, assuming they dont put him to critical role.
This is core issue. This has nothing to do with startup team vs team in corporation. Neither can have beginner in a critical difficult role. Both can make use of junior, assuming they dont put him to critical role.
Where is best to place a beginner? Too easy and they get bored. Too hard and they get demoralised when somebody else has to step in. Give them side projects and the work load for the team goes up with code review etc for unnecessary work.
I agree with what you are saying in that it needs to be called out that time needs to be specifically set aside in agile / sprint planning for mentoring. My manager understood this and I was allocated at least a day sprint to just 'mentor' my junior dev through a 8 months rotational stint in the team. Mentorship is very rewarding and I found out that I got just as much out of the relationship as they did. It also helped that for the first 4 weeks I was allowed to run her through a self lead learning program that I designed for them. Giving a new hire out of univiristy time to learn enough of what they needed to tackle some high value work just made the final outcome so much more successful.
You are supposed to modify and fit Agile into your specific process, not follow it dogmatically. It's literally the first thing on the manifesto: "Individuals and interactions over processes and tools". Change the process, or change the culture around this instead of blaming a broken process.
To add an example: At this company they have the concept of an IP (Innovation and Planning) sprint. This means that one sprint out of 5 we take to fix technical debt, add instrumentation, verify documentation. You should have some time carved out for mentoring.
At the very least, don't count the juniors in your capacity. This way you'll be able to handle their pace while keeping your velocity.
To add an example: At this company they have the concept of an IP (Innovation and Planning) sprint. This means that one sprint out of 5 we take to fix technical debt, add instrumentation, verify documentation. You should have some time carved out for mentoring.
At the very least, don't count the juniors in your capacity. This way you'll be able to handle their pace while keeping your velocity.
We account for that during spring planning. We plan on pairing on tasks/stories for general knowledge transfer and mentoring. If this affects velocity, that is actually a good thing (tm). Velocity should decrease when onboarding and mentoring, and then should increase as those team members become more efficient.
I have the same suspicions about the agile process as well. Great to be fast and producing but it's counter-productive if not everyone is at a similar level of output.
This... has made me realize how lucky I am. I do get asked to mentor our junior people, and I also enjoy the look on people's faces when they get that sudden realization of how something works. And I like explaining how things work anyway; I find it's the second-best way to realize what pieces of the system -I- don't know.
And - being perfectly honest about myself - I also enjoy the (brief and usually undeserved) "wow, he's a wizard!" that I get right before - just as a random example that has nothing to do with today - spending two hours trying to debug why some simple iptables rules don't work without testing that the network was working before adding them.
And - being perfectly honest about myself - I also enjoy the (brief and usually undeserved) "wow, he's a wizard!" that I get right before - just as a random example that has nothing to do with today - spending two hours trying to debug why some simple iptables rules don't work without testing that the network was working before adding them.
I've worked at 5 companies during my 13 years of programming and while I live in Eastern Europe and not North America, I can still confidently say luck has nothing to do with it.
Companies who work on long-term projects usually hire junior devs, companies that work on short therm projects don't, it's as easy as that.
Companies that hire more junior devs tend to pay less and usually struggle to keep the rising star devs that they helped train for the last 3 or so years.
It's just the way things are, I don't get the entitlemend of the article.
I totally agree, this is just the way things are. Yet, I think it's still possible that businesses in general have become more short-term oriented nowadays. An abundance of short-lived startups, companies being managed for short-term objectives, etc.
Therefore, it's possible, that there are relatively more short-term projects than long-term projects these days (comparing to, let's say a decade ago).
Therefore, it's possible, that there are relatively more short-term projects than long-term projects these days (comparing to, let's say a decade ago).
Full disclosure: I work at Dropbox.
Dropbox is a company that values mentorship. It is something that is explicitly called out and rewarded in performance evaluations, and it's one of the reasons I chose to accept the job offer from Dropbox.
I have been lucky enough to work at a place that pushed me to be a mentor, and another place where I got to influence culture to value mentorship, and I have seen junior developers who barely had any idea what they were doing and needed lots and lots of guidance, grow into some of the most amazing and capable engineers I've ever worked with.
> The short-termism that's infested our culture--it seems like all Western culture--is truly sickening. It feels like "Well, I got mine, screw the next generation." This goes way beyond just junior developers.
This is a byproduct of the erosion of loyalty that's pervasive in business these days. Businesses use to be loyal to their employees and in return their employees were loyal to them. That's no longer the case because over the last 30-40 years businesses have shown they aren't loyal to their employees.
Pensions are gone in favor of the 401k scam with many employers no longer even matching contributions. Medical Benefits get worse every year while the cost to the employee rises. Merit increases are virtually nonexistent and in many cases you're lucky to get a cost of living increase.
Why would an employee have any loyalty to a company that treats them like a commodity? It's gotten to the point that many functions are just outsourced to another company (e.g. HR, Maintenance & Facilities, Administration, IT). The staff are employed by the contracting firm and thus they are a fixed unit cost commodity and there's no long term obligation to them.
This is a byproduct of the erosion of loyalty that's pervasive in business these days. Businesses use to be loyal to their employees and in return their employees were loyal to them. That's no longer the case because over the last 30-40 years businesses have shown they aren't loyal to their employees.
Pensions are gone in favor of the 401k scam with many employers no longer even matching contributions. Medical Benefits get worse every year while the cost to the employee rises. Merit increases are virtually nonexistent and in many cases you're lucky to get a cost of living increase.
Why would an employee have any loyalty to a company that treats them like a commodity? It's gotten to the point that many functions are just outsourced to another company (e.g. HR, Maintenance & Facilities, Administration, IT). The staff are employed by the contracting firm and thus they are a fixed unit cost commodity and there's no long term obligation to them.
> The short-termism that's infested our culture--it seems like all Western culture--is truly sickening. It feels like "Well, I got mine, screw the next generation." This goes way beyond just junior developers.
It's a bit of a leap to conclude that on the basis that you weren't asked by management to mentor junior devs. In fact, it's possible management assumed you would do mentoring and didn't need to be told.
It's a bit of a leap to conclude that on the basis that you weren't asked by management to mentor junior devs. In fact, it's possible management assumed you would do mentoring and didn't need to be told.
The impression I got was not that he was inferring that short-termism has infested culture due to the fact that he is no longer able to mentor junior devs.
I believe he was saying that short-termism (which his belief is everywhere and I assume he has this opinion based on external beliefs not listed here...) is the root cause of this. Not many people hire junior devs anymore.
I tend to agree with him, and believe it has a lot to do with the death of "lifers" in business.
The quickest way to progress a career nowadays is to jump every few years, and that applies to both management and tech people. If people do this, what incentive is there to properly mentor a junior developer? Train them up for them to get nabbed in a few years?
There is not much loyalty in both directions nowadays and that has some genuine downsides.
I believe he was saying that short-termism (which his belief is everywhere and I assume he has this opinion based on external beliefs not listed here...) is the root cause of this. Not many people hire junior devs anymore.
I tend to agree with him, and believe it has a lot to do with the death of "lifers" in business.
The quickest way to progress a career nowadays is to jump every few years, and that applies to both management and tech people. If people do this, what incentive is there to properly mentor a junior developer? Train them up for them to get nabbed in a few years?
There is not much loyalty in both directions nowadays and that has some genuine downsides.
Implying management isn’t tech? You mean isn’t engineering? (Well, people engineering....)
It isn't tech nor engineering nor science. Managers do not properly and scientifically measure their performance or performance of their teams. Nor run proper experiments on management practices.
Do you read the newspaper? Watch TV? Have you genuinely not noticed an increase in short term thinking and f*ck you, got mine mentality in North America?
If not, over what time span are you considering?
If not, over what time span are you considering?
The "f*ck you, got mine" was probally always there.
It seems like it's just getting worse though.
Morality/ethics used to be more noticed, and rewarded. I don't know who to blame. I sometimes think it's the lack of listening to a sermon on Sundays?
I do know this, I can usually spot the selfish bastards around us, and try to steer clear from them. If I can financially harm them, I try. If they happen to be family, they are emotionally cut off.
I have a very financially successful sister.
She is now over fifty, and misserable. She lived the American dream, but did it ugly, and now just has a 25 year old husband that doesn't care about her. Yes--she got a pre-nup.
She still emails me with some new spiritual thing she discovered. It's always the same email. Why don't my brothers, and mother call me? My kids only call when they need money. What did I do?
She knows what she did early on. It's no mystery. At one time she had it all. Her good looks got her so much. The looks are fading, along with that power. I knew in my twenties she would have a wake up call later in life, but I didn't know she would burn down so many bridges clawing her way up. And no--if she was a man, she wouldn't have it easier.
It seems like it's just getting worse though.
Morality/ethics used to be more noticed, and rewarded. I don't know who to blame. I sometimes think it's the lack of listening to a sermon on Sundays?
I do know this, I can usually spot the selfish bastards around us, and try to steer clear from them. If I can financially harm them, I try. If they happen to be family, they are emotionally cut off.
I have a very financially successful sister.
She is now over fifty, and misserable. She lived the American dream, but did it ugly, and now just has a 25 year old husband that doesn't care about her. Yes--she got a pre-nup.
She still emails me with some new spiritual thing she discovered. It's always the same email. Why don't my brothers, and mother call me? My kids only call when they need money. What did I do?
She knows what she did early on. It's no mystery. At one time she had it all. Her good looks got her so much. The looks are fading, along with that power. I knew in my twenties she would have a wake up call later in life, but I didn't know she would burn down so many bridges clawing her way up. And no--if she was a man, she wouldn't have it easier.
I've never been explicitly mentored but I've been lucky to work places where there have been colleagues with things to learn from by example and inference. There does not need to be an explicit mentor relationship for knowledge to spread if work is done in teams and culture of open communication is cherished (at least on the team level).
I don't think dedicated mentorship is required for junior devs.
There's usually code reviews in which they can pick up on a lot, a mountain of resources online, and there's nothing stopping them from asking for help/opinions from fellow co-workers when tackling a problem.
There's usually code reviews in which they can pick up on a lot, a mountain of resources online, and there's nothing stopping them from asking for help/opinions from fellow co-workers when tackling a problem.
Junior programmers may not (even probably don't) have a good idea of what questions to even ask. Younger juniors (e.g. right out of college) may even feel intimated or anxious that their question is "stupid". This isn't helped by the software industry's reputation (well deserved, in my opinion) of being populated by arrogant people with little or no tact or empathy.
Reliance on online resources is, in my view not a substitute for experienced mentorship: there is the paradox of choice, and the plethora that creates this paradox is of generally poor quality. Except for textbook or trivial problems, moreover, much of the resource material online is too generic or only marginally applicable to the depth and breadth of technology issues that face a real business and its needs.
Reliance on online resources is, in my view not a substitute for experienced mentorship: there is the paradox of choice, and the plethora that creates this paradox is of generally poor quality. Except for textbook or trivial problems, moreover, much of the resource material online is too generic or only marginally applicable to the depth and breadth of technology issues that face a real business and its needs.
Totally agreed. This is, in essence, what I would define as the line between "junior" and someone escaping it.
Learning how to discern relevant info from random and how to ask useful questions in new areas are skills that take time (and a ton of context) to acquire, but are utterly essential to doing anything beyond what other people tell you to do.
Learning how to discern relevant info from random and how to ask useful questions in new areas are skills that take time (and a ton of context) to acquire, but are utterly essential to doing anything beyond what other people tell you to do.
> "This isn't helped by the software industry's reputation (well deserved, in my opinion) of being populated by arrogant people with little or no tact or empathy."
I don't get this attitude at all, but perhaps that is because I transitioned into software dev from the trades. In the trades you want your apprentices to ask questions, I don't see why Senior Devs would be assholes. In my experience, when I asked my Senior Devs questions, and this was after initial research efforts on my part, they were all receptive and helpful. It is much better to ask the question as a Junior than commit to prod and create even more work for the Seniors.
I don't get this attitude at all, but perhaps that is because I transitioned into software dev from the trades. In the trades you want your apprentices to ask questions, I don't see why Senior Devs would be assholes. In my experience, when I asked my Senior Devs questions, and this was after initial research efforts on my part, they were all receptive and helpful. It is much better to ask the question as a Junior than commit to prod and create even more work for the Seniors.
Ask the right question is a skill, and a good indicator for growth. If you have an ineffective team member on your team, you will know the pain. Junior dev isn't necessarily bad, some of them can ramp and contribute really fast, but some are just lacking.
When you hire a junior developer, they are themselves a project. How else could it be? The need for mentoring is what makes them a junior. If they didn't need mentoring, they would not be a junior.
Code reviews are a reactive exercise. They allow people of influence to criticise work. But it is important that people of influence have first stepped up, and laid out a clear direction.
As the mentor, you should have a mental plan for their one month, three months and eighteen month progressions. If you do not have this in mind, you should not have hired them.
From here, you should set a tempo that steers the junior to grow. The things you are growing are their skills, judgement and initiative. You need to balance the need to make sure they are heading down a good path against the momentum of their own initiative, which is valuable but also prone to misfiring.
This path will be different for each person. So: have a plan, but be prepared to adjust it regularly.
There comes a crossover point where their judgement and ability becomes strong. You realise that your steering efforts are holding them back vs their own initiative. There should be some conversation where you explain that you are stepping back, and that they should be careful with the extra rope they will be getting. With graduate hires this will be at least eighteen months out.
Code reviews are a reactive exercise. They allow people of influence to criticise work. But it is important that people of influence have first stepped up, and laid out a clear direction.
As the mentor, you should have a mental plan for their one month, three months and eighteen month progressions. If you do not have this in mind, you should not have hired them.
From here, you should set a tempo that steers the junior to grow. The things you are growing are their skills, judgement and initiative. You need to balance the need to make sure they are heading down a good path against the momentum of their own initiative, which is valuable but also prone to misfiring.
This path will be different for each person. So: have a plan, but be prepared to adjust it regularly.
There comes a crossover point where their judgement and ability becomes strong. You realise that your steering efforts are holding them back vs their own initiative. There should be some conversation where you explain that you are stepping back, and that they should be careful with the extra rope they will be getting. With graduate hires this will be at least eighteen months out.
Im hired as junior dev. at a relatively large non-tech company, to provide them with software tools, I built all these tools by myself with no mentoring and no help, My fear is this, my code looks clunky (probably not written according to good software design ?), and hard to read for others, I also have no skills in collaboration, how would I be able to grow these skills without a mentor ?.
You sound as if you are already able to teach yourself, just read more open-source code to find out what is good or bad style.
I would consider soliciting a formal mentor here on hackernews. Hacking on a open source project together would be a way to recieve that help in a remote fashion.
Sounds like there should be a thread to match mentors and mentees here on hackernews. Maybe a bunch of mentors post some open source projects that they want mentees for?
Sounds like there should be a thread to match mentors and mentees here on hackernews. Maybe a bunch of mentors post some open source projects that they want mentees for?
I would jump on something like that, I'm a senior university student currently with no work experience on my resume. I have been unable to do internships during summers because I usually need to spend that time helping out my sick father every year, and it terrifies me that I'm going to have to jump into the marketplace with no internships or anything really on my resume.
Every time I try to 'contribute to open source projects' online I get overwelmed by the size and complexity of most codebases, I have tried numerous times, and have never been able to fix a bug.
This type of thread is something I'm sure I and others would take serious advantage of.
Every time I try to 'contribute to open source projects' online I get overwelmed by the size and complexity of most codebases, I have tried numerous times, and have never been able to fix a bug.
This type of thread is something I'm sure I and others would take serious advantage of.
When I started my first job out of university I worked in a team where we were tasked with fixing various issues and requests (e.g. reports or minor features) from the business, so that teams working on features could focus on those. Even senior developers would be rotated around into this team, but as a junior develop it was where you first started, to learn the ropes.
It was a great experience, as other members of the team, who were more senior than you, may not have even understood how the application you were looking at worked (we had ~40 applications/services), so you would have to work together to figure it out - both completely clueless. Usually we would pair because of the unfamiliarity, but if we were familiar with the application we would occasionally work solo, even as a junior.
The best bit was the management: there was enough pressure that you knew you had to get this fixed soon, but not so much that you were stressing out.
It was a great experience, as other members of the team, who were more senior than you, may not have even understood how the application you were looking at worked (we had ~40 applications/services), so you would have to work together to figure it out - both completely clueless. Usually we would pair because of the unfamiliarity, but if we were familiar with the application we would occasionally work solo, even as a junior.
The best bit was the management: there was enough pressure that you knew you had to get this fixed soon, but not so much that you were stressing out.
Code review is horrible way to teach. Especially with reviewers common in tech who just can't tell difference between differences of opinion and crappy code. Or difference between "how I would did it" and bad code.
I don’t agree with this at all. It’s up to the participants to argue their points and see who has more valid designs. I became a much much better programmer by learning from senior devs who review my code.
Except when Juniors are humble and like "yes sir yes sir", don't defend their design assuming seniors know more and internalize everything. And except when seniors give conflicting feedback based on what they read yesterday. It was mostly impact on those juniors I found bad. They were told their code is crappier then it really was and lost a lot of confidence. They started humble and ended afraid to do anything except simplest tasks.
Also, they got only and exclusively negative feedback. Instead of being told in advance how to do things where we are opinionated or being encouraged to ask questions or just being led/given hints, they were expected to do it alone. Then they were told they done it badly and were effectively dictated how to rewrite it.
Tech is not different from anything else - teaching people should involve more then just telling them they suck. It should involve telling them what they are expected to do in advance.
Also, they got only and exclusively negative feedback. Instead of being told in advance how to do things where we are opinionated or being encouraged to ask questions or just being led/given hints, they were expected to do it alone. Then they were told they done it badly and were effectively dictated how to rewrite it.
Tech is not different from anything else - teaching people should involve more then just telling them they suck. It should involve telling them what they are expected to do in advance.
I feel like the problems you're describing are more workplace specific and not specific to the method of CR itself. For example,
> They started humble and ended afraid to do anything except simplest tasks.
It's the job of the team leads to create an environment where people (especially new people) shouldn't be afraid to try something out and learn from it. I've had plenty of CRs which went for some huge number of iterations when I first started, generally this was solved by spending some time thinking about designs on my own and then having a meeting with senior devs to discuss pros/cons and any suggestions before writing any code.
> Also, they got only and exclusively negative feedback.
This sounds really shitty, and this seems like a problem with the people on the team. I always try to put at least one positive thing in a CR after lots of criticism, and if there isn't that much criticism even better!
All in all it sounds like with or without CR, the team you're describing probably wouldn't be a pleasant place to work.
> They started humble and ended afraid to do anything except simplest tasks.
It's the job of the team leads to create an environment where people (especially new people) shouldn't be afraid to try something out and learn from it. I've had plenty of CRs which went for some huge number of iterations when I first started, generally this was solved by spending some time thinking about designs on my own and then having a meeting with senior devs to discuss pros/cons and any suggestions before writing any code.
> Also, they got only and exclusively negative feedback.
This sounds really shitty, and this seems like a problem with the people on the team. I always try to put at least one positive thing in a CR after lots of criticism, and if there isn't that much criticism even better!
All in all it sounds like with or without CR, the team you're describing probably wouldn't be a pleasant place to work.
I agree with you, through I am pretty confident the seniors were well meaning. Insecure in more then one way, but still well meaning people with no intention to cause anything bad.
It is not that CR is has no place in the process. It is that it should not be primary tool for teaching, mentoring and leading. Nor talked about that way. Every forum and blog posts talks about CR as teaching tool and every discussion about juniors puts a lot of emphasis on CR and none on other tools. A lot of people think and act that way.
It is not that CR is has no place in the process. It is that it should not be primary tool for teaching, mentoring and leading. Nor talked about that way. Every forum and blog posts talks about CR as teaching tool and every discussion about juniors puts a lot of emphasis on CR and none on other tools. A lot of people think and act that way.
Yeah, it was a long time ago (2000-2003) but I still clearly remember implementing everything twice as a Junior Developer - first my way, then their way.
On the other hand it's possible for this to lead to senior developers who can't or won't leave their comfort zones entrenching designs and patterns that degrade the efficiency of the organization.
What you said is basically a tautology. "This method of mentoring won't work if you have bad mentors".
The person you're describing shouldn't be mentoring. The problem isn't the methodology, but their personality being poorly suited to the task at hand.
This industry frequently conflates effective producers of lines of code, with an ability to function in a senior role. If you look at other lines of work, seniority often implies things beyond "does the basic job quickly".
The person you're describing shouldn't be mentoring. The problem isn't the methodology, but their personality being poorly suited to the task at hand.
This industry frequently conflates effective producers of lines of code, with an ability to function in a senior role. If you look at other lines of work, seniority often implies things beyond "does the basic job quickly".
1.) Depending on the team, code review is either done by everyone non-junior or by the people most responsible for code base and expected to know most about it. It is last approve/reject step before admitting code.
So yes, this person will do code review. And code review has more functions then mentoring.
2.) Mentoring starts on task selection. Latest when junior start working on it - with senior occasionally checking the junior out while the task is in progress. Code reviewer might be someone completely else who might have noticed that junior is working on code only after it is done.
Sane mentoring should not start when junior finished the work.
So yes, this person will do code review. And code review has more functions then mentoring.
2.) Mentoring starts on task selection. Latest when junior start working on it - with senior occasionally checking the junior out while the task is in progress. Code reviewer might be someone completely else who might have noticed that junior is working on code only after it is done.
Sane mentoring should not start when junior finished the work.
If the reviewers are giving crappy code reviews, what makes you think they would be better at mentorship?
I it is different task. And you could assign it to different person.
Also, there is level of knowledge to be acquired about teaching and working with people. A culture that does not conflate code review with teaching nor talk about it as a primary means of how to deal with less experienced developers have better chance to develop that knowledge.
As in, admitting that those are different tasks is first step.
Also, there is level of knowledge to be acquired about teaching and working with people. A culture that does not conflate code review with teaching nor talk about it as a primary means of how to deal with less experienced developers have better chance to develop that knowledge.
As in, admitting that those are different tasks is first step.
How would you feel about mentoring non-technical people? Uber seems to be piloting an apprenticeship program for people from non-technical backgrounds:
https://eng.uber.com/engineer-apprentices/
I don’t really know why Uber is doing it, but I wonder if in-house apprenticeship programs are going to become more of thing now.
https://eng.uber.com/engineer-apprentices/
I don’t really know why Uber is doing it, but I wonder if in-house apprenticeship programs are going to become more of thing now.
Vocational + apprentice systems of all types are going to be a massive thing in the next ten years. Most likely we'll all be sick of hearing about it a few years from now. It's starting to pop up everywhere in the US, an idea that has caught the culture's imagination again. It's the ideal counter to the stupid practice of everybody must get a four year degree as a base qualification. And it's the only way the bottom half in the US are going to finally start making progress again.
> How would you feel about mentoring non-technical people?
I'm not sure what you mean by "non-technical" people. Didn't we all start at zero technical skill? If Uber have gone about this the right way and have some motivated hires with some of the right basic competency then they should do well.
In terms of technical mentoring I'd be very happy to engage with individuals inside a program like this. It's a very different story when you've got someone who was originally hired for a different role and you are tasked with helping them make the jump from a non-technical role to technical one. This can fail for a number of reasons, but it often boils down to motivation, and the individuals might have been better quitting to do something like a bootcamp.
I will say that I have gotten a lot of benefit from coaching/mentoring non-technical people on specific things. An example would be teaching a customer success manager how to capture useful info from the browser dev tools. They have a superpower and that results in them getting better troubleshooting info to help customers.
I'm not sure what you mean by "non-technical" people. Didn't we all start at zero technical skill? If Uber have gone about this the right way and have some motivated hires with some of the right basic competency then they should do well.
In terms of technical mentoring I'd be very happy to engage with individuals inside a program like this. It's a very different story when you've got someone who was originally hired for a different role and you are tasked with helping them make the jump from a non-technical role to technical one. This can fail for a number of reasons, but it often boils down to motivation, and the individuals might have been better quitting to do something like a bootcamp.
I will say that I have gotten a lot of benefit from coaching/mentoring non-technical people on specific things. An example would be teaching a customer success manager how to capture useful info from the browser dev tools. They have a superpower and that results in them getting better troubleshooting info to help customers.
[deleted]
Well, you don't have to be asked directly to do that. I assume, you work in senior position, so read your role description and contract, for most senior positions I have seen "mentoring" and "team leading" is explicitly written there. Sure, don't expect to get assigned time and classroom with whiteboard for teaching in typical company, as it is expected to be done on fly ("don't know something? go ask our guru").
The way to learn professional coding as a junior dev is to consume massive quantities of programming books while working on side projects. Mentoring is great, but its value is usually very local to the current needs of a team.
It is a tragedy of the commons scenario. Everyone wants senior devs, who were at one point junior devs.
No one wants to train junior devs. The OP points out why:
* cheaper to have juniorish work done overseas
* juniorish work is automated away
* juniors on a team slow it down (compared to a team of all seniors)
So everyone competes for the senior talent.
A more sophisticated long term analysis might look at the benefits to senior developers and the hiring pipeline of bringing junior folks in. Again, the OP:
* senior folks get the chance to mentor, exercising a different skillset
* senior folks learn more about the problem domain by having to explain it
I'd add:
* junior folks bring in new ideas/concepts
* some level of loyalty is inspired. If nothing else, a beneficial brand among other new grads.
* the company matures and has to think about career path and retention
* good junior developers can be more "bang for the buck" as they grow. they still need raises, but will be able to do more work per $ than a mid level person might (because of their familiarity with the tooling and the domain)
No one wants to train junior devs. The OP points out why:
* cheaper to have juniorish work done overseas
* juniorish work is automated away
* juniors on a team slow it down (compared to a team of all seniors)
So everyone competes for the senior talent.
A more sophisticated long term analysis might look at the benefits to senior developers and the hiring pipeline of bringing junior folks in. Again, the OP:
* senior folks get the chance to mentor, exercising a different skillset
* senior folks learn more about the problem domain by having to explain it
I'd add:
* junior folks bring in new ideas/concepts
* some level of loyalty is inspired. If nothing else, a beneficial brand among other new grads.
* the company matures and has to think about career path and retention
* good junior developers can be more "bang for the buck" as they grow. they still need raises, but will be able to do more work per $ than a mid level person might (because of their familiarity with the tooling and the domain)
A key point that you're missing is that junior devs are likely to jump ship at least once in their career trajectory before they become senior devs. So yes, junior devs do need to be trained by someone, but if you're going to put in a lot of work and not receive much of the benefit, it's not in your best interest.
There's a variety of reasons for why devs jump ship so often (including compensation), but unless you can tackle that problem first and solve it, it doesn't make sense to jump head-first into expanded junior dev mentorship.
There's a variety of reasons for why devs jump ship so often (including compensation), but unless you can tackle that problem first and solve it, it doesn't make sense to jump head-first into expanded junior dev mentorship.
Once they're trained up to a point where another company is willing to pay them more for a more senior position, you could give them a raise? Congrats! You trained a junior dev and they turned into a senior dev.
This is the answer, but they just won't listen. Management at so many firms have convinced themselves that developers leave because of all these magical reasons that aren't either
1) they're dissatisfied with their pay and you're not listening
2) they're dissatisfied with their working conditions (bullpens or open offices anyone?)
so they'll never keep their best people and they'll never learn.
1) they're dissatisfied with their pay and you're not listening
2) they're dissatisfied with their working conditions (bullpens or open offices anyone?)
so they'll never keep their best people and they'll never learn.
That's because fixing 1 and 2 are really expensive. On top of that, the further removed someone is from the work being done, the more they want people to look "busy".
I got moved from a desk in in a dead end office with to a desk in a bullpen so that I could be "closer to the people who I work with." My performance fell off a cliff. People would stop by all the time to check up on things, there was always a conversation going on. It was incredibly stressful and I slowly burned out trying to maintain my level of productivity.
My boss (the director of the org.) started asking me why I was making mistakes and forgetting deadlines. I told him that it was entirely because of my new desk, and he said he would do what he could to help.
A couple of months go by, and we have another meeting. I say the same thing.
A few more months go by, we have another meeting. I say the same thing. He said he asked people to keep their conversations quieter.
A few more months go by, and we have a meeting, and I tell my boss I'm leaving because I'm burned out, and my desk is the #1 culprit. He and HR were like "you should have let us know before it got to this point."
I don't think there was a chance for them to understand the issue, regardless of how I articulated my concerns. To them, my new desk was an upgrade from the old desk. It was bigger, had lots of drawers, was closer to the "desirable" part of the building.
To me, it meant that everyone had to walk by my desk, and would use the time to chat, and ask questions that would be better handled via email. It was nice being closer to the team, but I had a way different workflow from everyone else. My boss probably thought it was great that everyone could turn around and ask me a question the second they thought of it, but it meant I was getting interrupted 3-4 times an hour, when I used to be able to work for 3 hours straight without seeing anyone.
I've honestly been thinking of calling up my old boss and asking him if he wants to grab a drink to see if he ever wrapped his head around why I left. To this day I'm baffled by the entire situation.
TL;DR: "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!"
I got moved from a desk in in a dead end office with to a desk in a bullpen so that I could be "closer to the people who I work with." My performance fell off a cliff. People would stop by all the time to check up on things, there was always a conversation going on. It was incredibly stressful and I slowly burned out trying to maintain my level of productivity.
My boss (the director of the org.) started asking me why I was making mistakes and forgetting deadlines. I told him that it was entirely because of my new desk, and he said he would do what he could to help.
A couple of months go by, and we have another meeting. I say the same thing.
A few more months go by, we have another meeting. I say the same thing. He said he asked people to keep their conversations quieter.
A few more months go by, and we have a meeting, and I tell my boss I'm leaving because I'm burned out, and my desk is the #1 culprit. He and HR were like "you should have let us know before it got to this point."
I don't think there was a chance for them to understand the issue, regardless of how I articulated my concerns. To them, my new desk was an upgrade from the old desk. It was bigger, had lots of drawers, was closer to the "desirable" part of the building.
To me, it meant that everyone had to walk by my desk, and would use the time to chat, and ask questions that would be better handled via email. It was nice being closer to the team, but I had a way different workflow from everyone else. My boss probably thought it was great that everyone could turn around and ask me a question the second they thought of it, but it meant I was getting interrupted 3-4 times an hour, when I used to be able to work for 3 hours straight without seeing anyone.
I've honestly been thinking of calling up my old boss and asking him if he wants to grab a drink to see if he ever wrapped his head around why I left. To this day I'm baffled by the entire situation.
TL;DR: "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!"
How is it expensive to solve the bullpen issue? Tell people to STFU or build a wall in the office, or at least put up some dividers. It’s not rocket science.
Most CEOs and VPs are idiots, handing money around to each other in a circle jerk of old white guys club, backslapping each other for hiring each other and keeping the hegemony going.
These idiots do not know what they are doing, they have just been conditioned to ooze confidence and ignore critics.
Most CEOs and VPs are idiots, handing money around to each other in a circle jerk of old white guys club, backslapping each other for hiring each other and keeping the hegemony going.
These idiots do not know what they are doing, they have just been conditioned to ooze confidence and ignore critics.
I tried, and nearly got fired for this. Well, not fired, but I'm currently a contractor, and was told because of this that I may not become an actual hire. (This has since settled down, but I'm still not hired because of unrelated issues —they're still waiting for a government grant.)
The story is simple: we have a prefab building with 3 stories, a beautiful interior, 52 desks on each floor. All open, but for 2 closed meeting rooms per floor. And the toilet. The desks are arranged close to the window. The centre of the floor holds a couple meeting spaces, and the coffee machine. It was, unsurprisingly, very noisy.
I talked about the issue during a sprint's retrospective, and was told to lay out my proposals to HR. I had plenty, most of which didn't involve actually chopping up the "lovely" open space into actual desks. It was mostly about putting dividing half walls and generally muffling the whole thing, while mostly preserving that "open" look that is so dear to whoever doesn't actually work there (funny how most people who condoned the open plan end up spending most of their time in meetings).
I had indirect feedback later (through my team's product owner). Turned out the head HR was surprised to see me raise the subject—I was the first to do so. So she asked around. The feedback she got was mostly "well, yeah, it's an open plan, but it's okay", which she translated by "there is no problem, it's just a single contractor being difficult". I guess she was oblivious to the biases introduced by her being in a position of power. That nobody will say to her face that the noise is not okay, lest she thinks they can't fit in. (I no longer have that fear, for better or worse.)
I have later learned that a "Life in the Open Plan" group formed because of the noise issue.
The story is simple: we have a prefab building with 3 stories, a beautiful interior, 52 desks on each floor. All open, but for 2 closed meeting rooms per floor. And the toilet. The desks are arranged close to the window. The centre of the floor holds a couple meeting spaces, and the coffee machine. It was, unsurprisingly, very noisy.
I talked about the issue during a sprint's retrospective, and was told to lay out my proposals to HR. I had plenty, most of which didn't involve actually chopping up the "lovely" open space into actual desks. It was mostly about putting dividing half walls and generally muffling the whole thing, while mostly preserving that "open" look that is so dear to whoever doesn't actually work there (funny how most people who condoned the open plan end up spending most of their time in meetings).
I had indirect feedback later (through my team's product owner). Turned out the head HR was surprised to see me raise the subject—I was the first to do so. So she asked around. The feedback she got was mostly "well, yeah, it's an open plan, but it's okay", which she translated by "there is no problem, it's just a single contractor being difficult". I guess she was oblivious to the biases introduced by her being in a position of power. That nobody will say to her face that the noise is not okay, lest she thinks they can't fit in. (I no longer have that fear, for better or worse.)
I have later learned that a "Life in the Open Plan" group formed because of the noise issue.
> I'm currently a contractor, and was told because of this that I may not become an actual hire
They are never going to hire you. The contract is, in a way, a more airtight way of paying you under the table. Depending on the size of the business, labeling everyone as 1099 can reduce taxes for the business quite a bit. Thing is, though, is that it's illegal. But it's usually up to the worker to report it, so it is extremely under-enforced.
Bottom line is that you're being abused. I encourage you to file Form SS-8 as soon as possible with the IRS and check into your state's labor office to see what they can do.
https://www.irs.gov/forms-pubs/about-form-ss8
Source: I left a contractor role in October after realizing that I was a victim of misclassification.
They are never going to hire you. The contract is, in a way, a more airtight way of paying you under the table. Depending on the size of the business, labeling everyone as 1099 can reduce taxes for the business quite a bit. Thing is, though, is that it's illegal. But it's usually up to the worker to report it, so it is extremely under-enforced.
Bottom line is that you're being abused. I encourage you to file Form SS-8 as soon as possible with the IRS and check into your state's labor office to see what they can do.
https://www.irs.gov/forms-pubs/about-form-ss8
Source: I left a contractor role in October after realizing that I was a victim of misclassification.
First, I live in France. The practices you speak of are familiar, but legislation may be different. Second, several contractors did got hired before me. Third, the terms of the grant they seek compels them to have very few contractors. They are expected to hire en masse if they get it.
Fourth, my contractor status is actually secondary to me. More important is being allowed to work part time (4 days a week), which I'm currently negotiating.
Fourth, my contractor status is actually secondary to me. More important is being allowed to work part time (4 days a week), which I'm currently negotiating.
I honestly don’t know why so many companies are clinging to open offices with a death grip. Who does this benefit???
Accounting. Open offices take less space, which is cheaper. The real costs are hidden, so they tend to be ignored.
It also looks good from the outside.
It also looks good from the outside.
Yeah, the funny thing is that the accountants and HR all had private offices with doors that locked because they dealt with confidential matters.
In our case, even the higher ups have their desk in the open plan. Closer to the corners of course, but still. And I think this actually contributes to the delusion of harmlessness of this environment.
Having their desk in the open plan, they're more be inclined to think they are as affected as everyone else. Except they're not, because they spend way more time in meetings, and live on the manager's schedule.
As far as I can tell, the higher ups actually do mean well. I'm not sure what drew them to the open plan, but I think cold blooded cynicism explains only a fraction of their error.
Having their desk in the open plan, they're more be inclined to think they are as affected as everyone else. Except they're not, because they spend way more time in meetings, and live on the manager's schedule.
As far as I can tell, the higher ups actually do mean well. I'm not sure what drew them to the open plan, but I think cold blooded cynicism explains only a fraction of their error.
I am surprised no companies offer noise cancelling headphones for staff. They are relatively cheap (compared to restructuring an office building) and could increase productivity a lot for some people.
Those headphones only block constant background noise, not conversations. In order to do that you have to put your hearing at risk with enough actual noise to overwhelm the rest.
I have tried some decent quality ones. They don't block out conversations completely, but it does sound a lot quieter. They are definitely an improvement over not wearing them.
I tried this, and my problem was that I would end up with "listening fatigue" or whatever you want to call it after 6 hours of listening every day.
I think he meant "conversations" as in someone walking up and interrupting you to have a conversation
Yep.. my Bose QC35's are amazing!
> He and HR were like "you should have let us know before it got to this point."
Why is this so common? What kind of brain dead morons are becoming managers?
Why do they even become managers if they don't want to manage. At my firm, it was the same. Some people were automatic fits and managed to do fine. The others were left to fend for themselves. No mentorship, no management, nothing.
Why is this so common? What kind of brain dead morons are becoming managers?
Why do they even become managers if they don't want to manage. At my firm, it was the same. Some people were automatic fits and managed to do fine. The others were left to fend for themselves. No mentorship, no management, nothing.
I'm fairly aware that the about half the management at this job thought I was inscrutable. Someone who kind of knew me was interviewing for a position and asked my boss about me. His reply was something to the effect of "He's the genius who we leave alone in the corner while he does mad science experiments."
I guess it's complimentary in a way, but I can articulate exactly what I did in a way that my mom, who is an artist and barely uses a computer, can understand.
I think a lot of the problem is that some managers are really inflexible. They only know one way of management, and if that doesn't work they don't know what to do. They are a lot like teachers in that regard. We've all had teachers who could only explain things one way, and they constantly confused students who didn't grasp that explanation.
I even got my boss and HR to admit that I was really self-aware, and was able to articulate what I needed to succeed. It was like that meme where you break a logical explanation down into atomic parts and get them to agree with every step along the way, but they just said "no" to the conclusion.
I guess it's maybe an example of the Peter Principle in action.
I guess it's complimentary in a way, but I can articulate exactly what I did in a way that my mom, who is an artist and barely uses a computer, can understand.
I think a lot of the problem is that some managers are really inflexible. They only know one way of management, and if that doesn't work they don't know what to do. They are a lot like teachers in that regard. We've all had teachers who could only explain things one way, and they constantly confused students who didn't grasp that explanation.
I even got my boss and HR to admit that I was really self-aware, and was able to articulate what I needed to succeed. It was like that meme where you break a logical explanation down into atomic parts and get them to agree with every step along the way, but they just said "no" to the conclusion.
I guess it's maybe an example of the Peter Principle in action.
> That's because fixing 1 and 2 are really expensive.
Re point #1, I simply don't understand how, long term, it is more cost efficient to hire and train someone entirely new than it is to build a culture of valuing current staff. Maybe I'm naive? Maybe it is difficult in ways I don't perceive?
Re point #1, I simply don't understand how, long term, it is more cost efficient to hire and train someone entirely new than it is to build a culture of valuing current staff. Maybe I'm naive? Maybe it is difficult in ways I don't perceive?
Different budgets. Raises are continual, ongoing costs but the cost for hiring a new person can be considered one off costs, even though you are performing the "one off" task repeatedly
Some managers also seem to only respond to crises. Being down an employee is a crisis. Making sure that your employee gets an appropriate raise isn't, especially since most people aren't going to leave their boss know that they are looking for another job
Some managers also seem to only respond to crises. Being down an employee is a crisis. Making sure that your employee gets an appropriate raise isn't, especially since most people aren't going to leave their boss know that they are looking for another job
This is why you take notes.
This I can nod agreed with, Im forced into open office, with a lot of marketing people, and I cant be productive, often times I end up spending my time at home fixing the hard problems, and just doing the easy ones at work.
btw. I'm a junior dev. without mentor working with non tech people.
> This is the answer, but they just won't listen
Is there a counterfactual? A company with a strong culture of promoting from within that outperforms as a likely result of this attribute?
Is there a counterfactual? A company with a strong culture of promoting from within that outperforms as a likely result of this attribute?
In my experience promoting from within is still insufficient. Getting a promotion means maybe a 10% raise. Quitting means a 50-100% raise. I've got a guy on my team in a junior-ish position making 80 who is about to leave to make 160. There's no promotion path in the company to get that kind of raise over night.
Where the heck are these kinds of companies? I've heard jumping for a $10-20k raise (so, roughly 20-30%), but double for a junior? Unless COL influences stuff, I'd be wondering what he did right and knock that off as an outlier.
His junior position probably doesn’t have a junior label, and the next one might have a senior.
This is the correct answer.
Well that sucks time to change the company...
I've personally never heard of any company doubling a developer's salary like that. Have you?
Double, no. But I had a company that gave me a 30-40$ increase one year because it was obvious I was performing at that level.
Then a couple years later they were giving me basically no raise. When I told them I thought I was worth more, they asked me if I could "wait a year".
I got a new job and a huge raise compared to the last one. (Again, 30-40%.)
So while it's possible, it's not always even reliable at the same company that has done it in the past.
Then a couple years later they were giving me basically no raise. When I told them I thought I was worth more, they asked me if I could "wait a year".
I got a new job and a huge raise compared to the last one. (Again, 30-40%.)
So while it's possible, it's not always even reliable at the same company that has done it in the past.
It's certainly rare, but my employer is aggressive about keeping compensation appropriate. Top performing new hires can see their comp double in 2-3 years.
GE used to do this (not developers, but generally) in the 1980s, I think. Here's an article about promoting CEOs from within and how that is beneficial: http://www.jimcollins.com/article_topics/articles/companies-...
3) They're dissatisfied with how they are managed.
Awhile back I left my first software job (they did have systematic hiring of new grads) at a very large corporation because I was moving to another city. As it happened, that company also had an office in the city I was moving to. I applied for a position at the new location and they gave me an offer. But their offer was something like 15-20k lower than just about all the other offers I had. Apparently there was some limit on how much you could increase someone's compensation that was preventing them from offering me more. I heard a rumor that my previous boss (one of only two level 6 software engineers in the company's whole eastern region) made some noise about how ridiculous it was given that hiring me was way less risky than hiring someone else since my track record at the company was well established. But it was all to no avail. He couldn't move the bureaucracy. So of course I took the highest paying offer with another company.
Absolutely happened at my first job, too. There was a huge fuss over how much a raise they could give me and how they were capped to a certain limit.
It's great you love my work but it's not enough of a reason that I shouldn't walk across the street to your competitor and get paid 20% more.
It's great you love my work but it's not enough of a reason that I shouldn't walk across the street to your competitor and get paid 20% more.
Even if you're a savvy manager who is totally on board with this idea, you have to work within the rules HR gives you. There are lots of companies that cap promotion raises at 10% and need VP level sign off above that. How many companies allow a manager to make a habit out of 50% raises - not just for the once a generation talent who made the company 10x their salary this year, but for "pretty good" employees who are progressing as expected?
For whatever reason, letting them walk and paying that same 1.5x salary to a new mid-level hire is easier for everyone to swallow.
And from the employee's perspective, saying "yes" to a recruiter who expects to pay market rate sounds like a lot less hassle and stress than preparing a presentation on why your current company should change or make an exception to its HR polices for you.
For whatever reason, letting them walk and paying that same 1.5x salary to a new mid-level hire is easier for everyone to swallow.
And from the employee's perspective, saying "yes" to a recruiter who expects to pay market rate sounds like a lot less hassle and stress than preparing a presentation on why your current company should change or make an exception to its HR polices for you.
If you're going to end up paying market rate anyway, why not just skip the training cost and hire them after someone else has put in the hard yards?
Because the problem domain, process and tooling is specific to your company and a senior person also needs time to learn them.
Plus, turning a junior into a senior developer isn't exactly a boolean switch, that is turned over night. It's a process and that junior developer will spend a lot of intermediate time between both states, in which he's still very useful, yet affordable since he's probably paid below senior level.
That's true. Presumably the junior developer is cheaper while they're junior, but if nobody's hiring them anymore then I guess they're not cheaper enough to compensate for needing to train them.
Maybe by creating a workplace where developers want to stay you could keep them around at slightly under market rate? Not everyone is looking to job hop every 6 months. But the amount below market rate that you seem to end up by staying in one job feels like it's unreasonably large.
Maybe by creating a workplace where developers want to stay you could keep them around at slightly under market rate? Not everyone is looking to job hop every 6 months. But the amount below market rate that you seem to end up by staying in one job feels like it's unreasonably large.
That's true but it also misses the point: A portion of the limited money-pool you could have used for their raise is already gone, spend in the extra costs (direct or opportunity) of the training period.
There isn't much of a "raw mercenary economics" argument for training (which the MBA types prefer), you've got to talk about intangibles like loyalty, goodwill, social connections, etc.
There isn't much of a "raw mercenary economics" argument for training (which the MBA types prefer), you've got to talk about intangibles like loyalty, goodwill, social connections, etc.
That doesn't make sense to me.
Let's say you train someone whose salary is [x]. After training, their market salary would be 30% higher; [1.3x].
Are you suggesting that if they end up with a hypothetical 10% raise, to [1.1x] because [.2x] was spent on training?
That's absurd. You can't just walk out on the street and hire a person who is already trained for [1.3x]. You have to devote resources to the hiring process, which are probably nearly as expensive as training up a junior dev, all things considered.
I honestly think the difference in the second example is that the expenses in the second example are paying the kinds of people who make stupid personnel decisions like this.
I'm obviously cynical about the whole thing, but it seems that MBA-style thinking is almost deliberately evil. I have friends who have gotten MBAs from top schools, and friends who work in management consulting for the Big 4, and I've talked at length with them about their feelings about business practices that they implement and support. I literally have never gotten an answer that justifies philosophical objections to their work, beyond perhaps "well, it's just the way it's done."
I think it's a myth that organizations have to behave in a deliberately sociopathic manner in order to be successful. I mean, to a certain extent being a sociopath is an advantage, but I really don't think that's really a necessity.
On the flip side, I acknowledge that I am not very good at divorcing who I am from what I do. It's why I've made a career helping non-profits and social enterprises. I'd probably be a healthier person if I were able to get less invested in what I do.
Let's say you train someone whose salary is [x]. After training, their market salary would be 30% higher; [1.3x].
Are you suggesting that if they end up with a hypothetical 10% raise, to [1.1x] because [.2x] was spent on training?
That's absurd. You can't just walk out on the street and hire a person who is already trained for [1.3x]. You have to devote resources to the hiring process, which are probably nearly as expensive as training up a junior dev, all things considered.
I honestly think the difference in the second example is that the expenses in the second example are paying the kinds of people who make stupid personnel decisions like this.
I'm obviously cynical about the whole thing, but it seems that MBA-style thinking is almost deliberately evil. I have friends who have gotten MBAs from top schools, and friends who work in management consulting for the Big 4, and I've talked at length with them about their feelings about business practices that they implement and support. I literally have never gotten an answer that justifies philosophical objections to their work, beyond perhaps "well, it's just the way it's done."
I think it's a myth that organizations have to behave in a deliberately sociopathic manner in order to be successful. I mean, to a certain extent being a sociopath is an advantage, but I really don't think that's really a necessity.
On the flip side, I acknowledge that I am not very good at divorcing who I am from what I do. It's why I've made a career helping non-profits and social enterprises. I'd probably be a healthier person if I were able to get less invested in what I do.
> Are you suggesting that if they end up with a hypothetical 10% raise, to [1.1x] because [.2x] was spent on training?
Either that, or the company makes cuts somewhere else which -- all else being equal -- puts it at a competitive disadvantage. Budgets are generally zero-sum at a particular moment in time.
> You have to devote resources to the hiring process, which are probably nearly as expensive as training up a junior dev, all things considered.
If you can prove that to the bean-counters, by all means spread the good word.
However even if true you must consider a third potential outcome: You train up the junior employee, and then they don't stay with your market-rate offer for whatever reason, and you have to incur the hiring-process costs anyway for the empty senior position.
That scenario is always be more expensive than the other two, and it can only strike junior-trainer companies. Senior-poacher companies don't have to even worry about the odds of it occurring.
Either that, or the company makes cuts somewhere else which -- all else being equal -- puts it at a competitive disadvantage. Budgets are generally zero-sum at a particular moment in time.
> You have to devote resources to the hiring process, which are probably nearly as expensive as training up a junior dev, all things considered.
If you can prove that to the bean-counters, by all means spread the good word.
However even if true you must consider a third potential outcome: You train up the junior employee, and then they don't stay with your market-rate offer for whatever reason, and you have to incur the hiring-process costs anyway for the empty senior position.
That scenario is always be more expensive than the other two, and it can only strike junior-trainer companies. Senior-poacher companies don't have to even worry about the odds of it occurring.
But if they leave, now you have to pay to train a new junior dev, and you still have to pay full price for a different senior dev.
The "raw mercenary economics" argument is saved money on recruitment/and allowing better calibration of performance to salary.
Consider the costs associated with recruiting for a single role. You have to either advertise a role/filter out candidates or engage a recruiter (which costs time or money). You have to interview a number of people, taking time (money).
You then have to onboard that person, and choose a salary based on your limited knowledge about them. And even then you could still hire a lemon (although admittedly it could go the other way and you hire someone better than expeceted). You then have to wait for them to become productive in the new organisation.
You also have much better information about someone who has worked at your organisation for a longer period of time and can therefore tailor their salary better to their skills than for someone who you know nothing about.
Spending money on training is a predictable cost vs. an unknown future cost of hiring. And yes, people will also appreciate it as an intangible, which if you are 'mercenary' you can enumerate as a supplement to a certain amount of salary.
Consider the costs associated with recruiting for a single role. You have to either advertise a role/filter out candidates or engage a recruiter (which costs time or money). You have to interview a number of people, taking time (money).
You then have to onboard that person, and choose a salary based on your limited knowledge about them. And even then you could still hire a lemon (although admittedly it could go the other way and you hire someone better than expeceted). You then have to wait for them to become productive in the new organisation.
You also have much better information about someone who has worked at your organisation for a longer period of time and can therefore tailor their salary better to their skills than for someone who you know nothing about.
Spending money on training is a predictable cost vs. an unknown future cost of hiring. And yes, people will also appreciate it as an intangible, which if you are 'mercenary' you can enumerate as a supplement to a certain amount of salary.
Market rate compensation, non-toxic culture, and realistic expectations for work output solves 90% of the reasons reasonable people leave jobs.
People claim all sorts of reasons for leaving jobs but its always one of those three or uncertainty about company longevity. (i.e. acquisition/financial difficulties for the company)
The other 10% is people who are naive or have a family/relocation related issue that you can never control for.
And yes, before you say it is impossible, I've worked at a company where "voluntary quits" was _that_ low and no one voluntarily left because they knew how good they had it. Literally, in a team of 20+ I knew all 3 people who voluntarily quit over the span of 10 years there.
People claim all sorts of reasons for leaving jobs but its always one of those three or uncertainty about company longevity. (i.e. acquisition/financial difficulties for the company)
The other 10% is people who are naive or have a family/relocation related issue that you can never control for.
And yes, before you say it is impossible, I've worked at a company where "voluntary quits" was _that_ low and no one voluntarily left because they knew how good they had it. Literally, in a team of 20+ I knew all 3 people who voluntarily quit over the span of 10 years there.
You may have a point in here. Provided I have productive working conditions and 5-10% YoY salary bump I'd probably never have the inertia to look for a new job myself.
Most company doesn't work this way. They are not really toxic, it is just their internal policy structure.
Junior devs should look for jobs once they reach the 2 years mark any more, for their own good as well. They now know better what they want to do, more focused, more experienced, and most importantly, more valuable on the market.
Junior devs should look for jobs once they reach the 2 years mark any more, for their own good as well. They now know better what they want to do, more focused, more experienced, and most importantly, more valuable on the market.
When I first got into programming, as a high school intern in the early eighties, I was told a programmer stays at a job, on average for the years. I haven't heard this number change at all.
While I'm sure there are many jobs where people stay along time, the average length of stay is still fairly short.
Boredom and wanting to work on something new is probably the biggest driver
Boredom and wanting to work on something new is probably the biggest driver
- Promise of a higher income
- Low perceived stability at the current job (employees want to secure a new job before they're layoffs)
- Toxic work environment
I HAD to switch jobs 3 times within 2 years when first starting. (Redundancy, restructure, outsourcing.)
It's no longer scary or stressful. I now choose to switch jobs regularly because I get better incentives to join somewhere else and I get more bargaining power with each transition.
C-levels and shareholders made it this way - if they kept with market rates and the organisation put more value in employees and their IT I'd stay around. But I've been seeing more and more of a shift to outcome-based budgeting, maintenance and refactoring isn't even part of BAU budgeting - it's strapped on to project work. This is likely exclusive to non-tech companies (even though most companies are shifting towards tech as their basis ala "Software is Eating The World").
Managers can only do so much within an org, I haven't worked for a manager I didn't like (I've turned down jobs based on my interview process though). Not US based.
It's no longer scary or stressful. I now choose to switch jobs regularly because I get better incentives to join somewhere else and I get more bargaining power with each transition.
C-levels and shareholders made it this way - if they kept with market rates and the organisation put more value in employees and their IT I'd stay around. But I've been seeing more and more of a shift to outcome-based budgeting, maintenance and refactoring isn't even part of BAU budgeting - it's strapped on to project work. This is likely exclusive to non-tech companies (even though most companies are shifting towards tech as their basis ala "Software is Eating The World").
Managers can only do so much within an org, I haven't worked for a manager I didn't like (I've turned down jobs based on my interview process though). Not US based.
> When I first got into programming, as a high school intern in the early eighties, I was told a programmer stays at a job, on average for the years. I haven't heard this number change at all. While I'm sure there are many jobs where people stay along time, the average length of stay is still fairly short.
I've literally worked at _one_ place that scored well on those three items. Most places are racing to the bottom in one or two of those. Usually it is pay unless you are somewhere competitive like the Bay Area.
> Boredom and wanting to work on something new is probably the biggest driver
That is much like the "exciting new opportunity" story people tell about why they changed jobs. It is not _real_ in the literal sense.
If it was real, they would shop around internally to change projects and succeed. There would be no real need to change jobs.
Idk where you have worked but I've literally never worked on the same project for longer than 1-2 years. Even if I was at the same employer for 6+. If you have people with realistic expectations who aren't piling on technical debt, maintenance work _should_ be negligible even if you are lightly attached to old projects.
I've literally worked at _one_ place that scored well on those three items. Most places are racing to the bottom in one or two of those. Usually it is pay unless you are somewhere competitive like the Bay Area.
> Boredom and wanting to work on something new is probably the biggest driver
That is much like the "exciting new opportunity" story people tell about why they changed jobs. It is not _real_ in the literal sense.
If it was real, they would shop around internally to change projects and succeed. There would be no real need to change jobs.
Idk where you have worked but I've literally never worked on the same project for longer than 1-2 years. Even if I was at the same employer for 6+. If you have people with realistic expectations who aren't piling on technical debt, maintenance work _should_ be negligible even if you are lightly attached to old projects.
Comeon now, there are more reasons than that for people to leave, like a new exciting opportunity appearing.
People _say_ that to acquaintances, to coworkers. Just like they stay positive in the workplace and a bunch of other fronts people keep up as part of work life. Your job at work is to sell yourself and your skillset.
With people you talk with honestly outside of work YMMV but I've never seen that as a legitimate thing except with naive people who ended up regretting it. I've only seen people being happy with it when they were already underpaid, unhappy with the culture, or forced to work absurd hours to keep their jobs.
With people you talk with honestly outside of work YMMV but I've never seen that as a legitimate thing except with naive people who ended up regretting it. I've only seen people being happy with it when they were already underpaid, unhappy with the culture, or forced to work absurd hours to keep their jobs.
> a new exciting opportunity
You mean a salary or title increase? Yeah, that's in the GP's comment.
You mean a salary or title increase? Yeah, that's in the GP's comment.
No, like a project or team you really want to work on for any number of reasons other than salary or title.
Not just the risk of them jumping ship, the problem is that because mid to senior dev salaries are highly desirable it attracts juniors into the field who are not suited to the job but like the idea of working in the industry or the potential money in it. So, you spend time training a group of people where some aren't suited for the job but you spend a lot of time on them and the better ones leave quickly. If you don't pick the juniors carefully in the first place and if you don't have the environment and renumeration to keep the better ones from leaving then it's probably better to just not spend too much time on recruiting them. It actually might work well for a company that doesn't want or need a large dev team. Also, not everyone is good at mentoring, some of the best people are often self taught and some of them find it difficult to teach others.
They jump ship more often when they stop or significantly slow growing than when for compensation, but eventually compensation becomes a problem just the same as at any job.
You're underestimating how quickly a junior dev can be putting out useful work - within a few months they'll be tackling a ton of bugs and freeing up senior people to work on bigger features. Yes, eventually they leave, but it seems like everyone seems to think they're just dead weight.
You're underestimating how quickly a junior dev can be putting out useful work - within a few months they'll be tackling a ton of bugs and freeing up senior people to work on bigger features. Yes, eventually they leave, but it seems like everyone seems to think they're just dead weight.
You could poach them too. It could be a tragedy of the commons scenario, but it would be nice.
I did say "they still need raises" :) But I get what you are saying.
As a junior dev, I have received at least one double digit percentage raise. This was a while ago, and perhaps I worked for an enlightened boss, or maybe I was just really really undermarket. But it can and should happen.
The long term approach would be to give the juniors raises and challenge them and keep them within the org. Unfortunately the short term perspective doesn't value that and so jumping ship is the best way to get more money, causing the org to lose all the training and the institutional memory.
As a junior dev, I have received at least one double digit percentage raise. This was a while ago, and perhaps I worked for an enlightened boss, or maybe I was just really really undermarket. But it can and should happen.
The long term approach would be to give the juniors raises and challenge them and keep them within the org. Unfortunately the short term perspective doesn't value that and so jumping ship is the best way to get more money, causing the org to lose all the training and the institutional memory.
> No one wants to train junior devs.
Many dev shops want junior devs, and that's a great place to get experience if you get placed on-site with a good client. Also cash cow businesses where tech isn't their core competency (media, fashion, pharma, etc.) will hire junior devs.
Basically if you're spending all your time trying to get hired by a startup or by FAAMG then you're going to have a bad time, but if you focus on the types of companies that actually hire junior devs then you shouldn't have too much trouble at least getting interviews. It's obviously still very difficult because you're pretty much useless, but if you're at least willing to put in the time to do the hiring homework assignments then you'll get taken seriously as a candidate.
Many dev shops want junior devs, and that's a great place to get experience if you get placed on-site with a good client. Also cash cow businesses where tech isn't their core competency (media, fashion, pharma, etc.) will hire junior devs.
Basically if you're spending all your time trying to get hired by a startup or by FAAMG then you're going to have a bad time, but if you focus on the types of companies that actually hire junior devs then you shouldn't have too much trouble at least getting interviews. It's obviously still very difficult because you're pretty much useless, but if you're at least willing to put in the time to do the hiring homework assignments then you'll get taken seriously as a candidate.
That's weird, in my experience FAAMG (maybe less so Apple) hire junior devs by the truckload. However, I don't think they are typically in the business of hiring bootcamp graduates; it's mostly new grads or people transitioning from a similarly technical job/advanced degree in e.g. physics or math.
It's pretty interesting -- as a startup founder leading a dev team of ~10 people now, I've hired almost all junior level candidates. We never had a posting for "Junior Software Engineer" though. We just had one posting and considered everyone who applied separately and within the context of their experience.
One reason I see especially in larger companies that there is specific hiring headcount allocated. Always it doesn’t specify if the allocation is for junior/mid/senior level. So to optimize your team’s output, you tend to look for the mid/senior and not even consider junior people.
This. If more managers were given a budget rather than a headcount, they'd hire more juniors. At my last managing gig, I was the only manager at my level to hire junior devs.
I prefer a little mentoring/supervision to the "too many chiefs" problem. And juniors have fewer bad habits I need to break, so I can more easily mold them into the kind of developer I want. Also, junior devs are much more willing to take the crap tasks that seniors find less challenging/interesting. I can stick a fresh college grad on bug duty and they'll often churn through them faster than the senior devs. The raw horsepower of some young devs is damn impressive just as long as you keep them pointed in the right direction.
But I've also found that mentoring is a rewarding part of the job and now that I manage, I really enjoy mentoring mentors. Helping turn great experienced devs into great teachers helps take them to the next level and I've had guys that didn't want to do anything but write code thank me for pushing them to mentor.
So yeah...lots of companies give their managers perverse incentives and allow them to be lazy. But if you're conscientious and put a plan in place, mixing in around 30-40% juniors can be cheaper, more productive and better for everyone involved. It's just harder and most managers are more interested in playing politics to increase the size of their fiefdom than they are in actually shipping software and thinking about their reports' careers.
I prefer a little mentoring/supervision to the "too many chiefs" problem. And juniors have fewer bad habits I need to break, so I can more easily mold them into the kind of developer I want. Also, junior devs are much more willing to take the crap tasks that seniors find less challenging/interesting. I can stick a fresh college grad on bug duty and they'll often churn through them faster than the senior devs. The raw horsepower of some young devs is damn impressive just as long as you keep them pointed in the right direction.
But I've also found that mentoring is a rewarding part of the job and now that I manage, I really enjoy mentoring mentors. Helping turn great experienced devs into great teachers helps take them to the next level and I've had guys that didn't want to do anything but write code thank me for pushing them to mentor.
So yeah...lots of companies give their managers perverse incentives and allow them to be lazy. But if you're conscientious and put a plan in place, mixing in around 30-40% juniors can be cheaper, more productive and better for everyone involved. It's just harder and most managers are more interested in playing politics to increase the size of their fiefdom than they are in actually shipping software and thinking about their reports' careers.
You're missing a rather obvious point. A junior dev after months of training could jump ship for much better comp now that they're less junior or that suddenly some other company's product interests them more. Another point missing is that sometimes there are very hard problems (eg. self-driving cars, fusion power, DNA pattern matching) that need solving quickly and that's what some companies try to do, there are other type of companies that solve move mundane problems (hr software, customer relation management software, email tool) that have been solved over and over again. To bundle all companies into one category when it comes to training junior devs is a mistake, junior devs could be trained at companies working on easier problems much more cost effectively and efficiently.
> A junior dev after months of training could jump ship for much better comp now that they're less junior or that suddenly some other company's product interests them more.
Sure, but that's why you need to give people raises in line with market rates if you don't want to experience high turnover. That goes for junior and more senior people.
Companies often don't want to give big raises as junior people transition into mid-level, then senior. So many companies have a standardized 2-8% pay raise scale, which results in developers being drastically underpaid as they gain experience. The silly part of that is that those same companies are gonna have to pay market rate to replace those skills when their employees leave, and they have to eat the additional recruiting costs, lost institutional knowledge, and ramp up time for a new employee. Penny-wise and pound-foolish as it were.
Sure, but that's why you need to give people raises in line with market rates if you don't want to experience high turnover. That goes for junior and more senior people.
Companies often don't want to give big raises as junior people transition into mid-level, then senior. So many companies have a standardized 2-8% pay raise scale, which results in developers being drastically underpaid as they gain experience. The silly part of that is that those same companies are gonna have to pay market rate to replace those skills when their employees leave, and they have to eat the additional recruiting costs, lost institutional knowledge, and ramp up time for a new employee. Penny-wise and pound-foolish as it were.
I think there is a lot of assumptions being made in regards to what training actually is. In software development field change is constant a senior dev can not afford to stop learning new techniques, frameworks, etc. that’s not something you just get mentored at and you’re set for the rest of your career. The issue that seems to be ignored here is the fact that good devs are active learners on their own and do not typically require the kind of hand holding that is implicitly implied to be required in these type of arguments. A company can not train an employee who otherwise does not have the required skills for the job and hope that once they are trained will stay at the same company.
Here is the equation in my mind:
cost of junior dev added slowness + senior dev lost training time > recruiting cost for senior devs + lost institutional knowledge + ramp up time for new senior devs
Here is the equation in my mind:
cost of junior dev added slowness + senior dev lost training time > recruiting cost for senior devs + lost institutional knowledge + ramp up time for new senior devs
Devs are constantly learning but there's a still a lot at tech jobs that you are paying people to learn once. Some of it is how to get around in legacy code bases that haven't been worth replacing yet, but even things like "this is how you file an expense report" add up in time and need to be repeated for every new hire
I disagree with that statement. I find that a junior dev is far less jaded by the work world and will often develop a loyalty and dedicate to the team (if it is a good environment) that a sr. Dev wouldn't. Once your are 5 to 10 years into your career how you view your work/life balance and professional relationships changes dramatically.
A junior dev will often stay with an organization much much longer than what is probably good for them, especially if they are actively mentored and engaged.
A junior dev will often stay with an organization much much longer than what is probably good for them, especially if they are actively mentored and engaged.
I agree with this. My first job I was under a fairly good partner who took the time to mentor me, get me involved in decision making processes, and take me out to see clients. It was some of the best times of my life and I did learn a ton. I had to move for a family issue and immediately received a 35% raise in a similar COL location. If I didn't have that issue come up, I probably would have stayed much longer and continued to be underpaid.
Junior devs can also be great for sticking on smaller\simpler\more rote things that might be boring for a senior developer, but for a junior is new territory. Depending on the size\complexity of your codebase, a senior will take lot of time to actually be useful anyhow.
The problem is squashed salaries. I’ll have junior devs or people straight out of code school asking for 75-80% the salary of a solid senior dev. If I have to make a bet on who will be easier to manage and get productive 4 seniors vs 5 juniors for the same total expenditure I’ll choose the seniors every time. Even at 2 to 1 I’m taking seniors. Maybe around 3 or 4 to 1 juniors might look better. But that means junior starting salaries around 50k which no one is taking. Salary range is too squashed in the industy.
I've noticed this too. There are only a few rational explanations
1. Senior devs aren't paid enough for the value they bring to the company (or conversely, junior devs are paid too much for that value)
2. Investing in junior devs gives a good enough ROI that it's worth overpaying them for a few years. That is, after e.g. three years, enough junior devs have stuck around that they've accumulated enough org-specific knowledge and general tech competency to justify their initially high salaries
3. Senior devs aren't actually that much more productive than junior devs, they just think they are. They also may be averse to doing productive-but-boring work that feels "beneath" them.
4. New devs are valued for more than just their direct contributions to the software project's code base. For example, they may be valued for their ability to bring fresh perspectives, or for their proximity to formal education and thus their tendency to be knowledgable of relatively cutting-edge tech. I think universities lag behind the vanguard trendsetters by at least 5 years, but there are certainly software companies that are stuck 20 or more years in the past
5. The job market for developers is irrational with respect to experience and reasoning about it is as worthwhile as reasoning about the true value of Bitcoin.
I think it's a mixture between 1 and 2, with a little bit of each other explanation too. Worth noting is that senior developers at the big tech companies (AmaGooFaceAppleSoft) get paid a lot more than senior devs at most other tech companies, but most of that compensation is in stock. Full monetary comp (not counting benefits and perks) for a fresh grad might be about $150k/year, but senior developers with >5 years experience are making closer to $250k/year or more
1. Senior devs aren't paid enough for the value they bring to the company (or conversely, junior devs are paid too much for that value)
2. Investing in junior devs gives a good enough ROI that it's worth overpaying them for a few years. That is, after e.g. three years, enough junior devs have stuck around that they've accumulated enough org-specific knowledge and general tech competency to justify their initially high salaries
3. Senior devs aren't actually that much more productive than junior devs, they just think they are. They also may be averse to doing productive-but-boring work that feels "beneath" them.
4. New devs are valued for more than just their direct contributions to the software project's code base. For example, they may be valued for their ability to bring fresh perspectives, or for their proximity to formal education and thus their tendency to be knowledgable of relatively cutting-edge tech. I think universities lag behind the vanguard trendsetters by at least 5 years, but there are certainly software companies that are stuck 20 or more years in the past
5. The job market for developers is irrational with respect to experience and reasoning about it is as worthwhile as reasoning about the true value of Bitcoin.
I think it's a mixture between 1 and 2, with a little bit of each other explanation too. Worth noting is that senior developers at the big tech companies (AmaGooFaceAppleSoft) get paid a lot more than senior devs at most other tech companies, but most of that compensation is in stock. Full monetary comp (not counting benefits and perks) for a fresh grad might be about $150k/year, but senior developers with >5 years experience are making closer to $250k/year or more
I think the gig economy has helped #1 considerably.
In the UK, at least, a lot of developers reach a point where their pay is limited to what a company is willing to pay them for a full-time role. When you get to this point, you have a choice: stick to the full-time market, or go into contracting. From a money and freedom perspective, it's almost a no-brainer. A competent senior developer might make £45-50k, whereas a contractor will earn considerably more if they find consistent work. If they're not lucky enough to find back-to-back contracts they get a lot of extra free time to build their skills even further, or to diversify their offering.
In the UK, at least, a lot of developers reach a point where their pay is limited to what a company is willing to pay them for a full-time role. When you get to this point, you have a choice: stick to the full-time market, or go into contracting. From a money and freedom perspective, it's almost a no-brainer. A competent senior developer might make £45-50k, whereas a contractor will earn considerably more if they find consistent work. If they're not lucky enough to find back-to-back contracts they get a lot of extra free time to build their skills even further, or to diversify their offering.
0. Junior devs are hired on current median salary trends, while senior coast from the ones they started with years before.
I would bet heavily on 5. Not exactly on the hiring being irrational, but on companies doing crazy things that destroy the productivity of their senior people.
Just look at how many people are complaining here about open plan offices, agile time slots, heavyweight meetings, and inability to do what they do best.
Just look at how many people are complaining here about open plan offices, agile time slots, heavyweight meetings, and inability to do what they do best.
I think #2 is just dead wrong. The easiest way to change your status - whether that's income or losing your junior title - is to move jobs. I think the real reason we see so few junior devs now is they just aren't good for the companies paying them. Why invest in a junior developer when almost certainly they will (and should!) leave your company to get more money and different experiences.
reevaluate what they're being paid and promote them from junior to senior and pay them.
I think it's 2. I don't see why senior dev salaries should go any higher. At that point it would be easier to open office overseas even for smaller shops.
>I don't see why senior dev salaries should go any higher
Because they're vastly underpaid compared to the value they produce.
>At that point it would be easier to open office overseas even for smaller shops.
Which means you're getting junior devs, at best. The entire concept of outsourcing hangs on the idea that the people being outsourced to will behave exactly the opposite of those doing the outsourcing, i.e. not really caring about money. Well they do care: when they get senior they leave and go somewhere they can earn western money.
Because they're vastly underpaid compared to the value they produce.
>At that point it would be easier to open office overseas even for smaller shops.
Which means you're getting junior devs, at best. The entire concept of outsourcing hangs on the idea that the people being outsourced to will behave exactly the opposite of those doing the outsourcing, i.e. not really caring about money. Well they do care: when they get senior they leave and go somewhere they can earn western money.
> Well they do care: when they get senior they leave and go somewhere they can earn western money.
It seems like the offshore contracting companies have a better grasp on how to maintain tech workers than the companies that hired them do. I've noticed my contracting counterparts get regular performance reviews, decent raises, and title changes actually open up doors for them.
I get my regular 2% a annual bump and any title change has no impact on my actual work.
It seems like the offshore contracting companies have a better grasp on how to maintain tech workers than the companies that hired them do. I've noticed my contracting counterparts get regular performance reviews, decent raises, and title changes actually open up doors for them.
I get my regular 2% a annual bump and any title change has no impact on my actual work.
World doesn't work like that. You are not paid by the value you create, but by supply/demand for the position. The economics of the product only dictate whether something will be done or not.
And your second statement is not true. You simply get cheaper workforce in other countries. Even on senior levels.
And your second statement is not true. You simply get cheaper workforce in other countries. Even on senior levels.
>You are not paid by the value you create, but by supply/demand for the position.
The labor market isn't the greatest place to talk about market forces. Companies do everything they legally (and illegally to an extent) can to ensure that it's not an efficient market. Further, companies have all the power in the relationship: most of us must have work but a company doesn't absolutely have to hire someone. I saw a 4-person startup on this site say they'd been looking for a "rockstar" for 2 years to expand their company. They were willing and able to wait 2 years for a highly skilled person willing to take a low enough salary. Not many people can wait 2 years to get a job.
To see what a real labor market would look like, you need to address the power balance. So I think sports teams are a better representation because they have unions to address this issue. And they do capture more of the value they produce (not all of it, obviously).
>And your second statement is not true. You simply get cheaper workforce in other countries. Even on senior levels.
Oh, I had assumed you meant the typical outsourcing locations. If you mean places like Europe, yes you can get good senior people for lower rates there. But it's a percentage lower, not X times lower, you can't get a truly senior level person on e.g. 7k/yr. I'm sure there's someone somewhere that has, but they'd have done better to buy a lottery ticket with that luck.
The labor market isn't the greatest place to talk about market forces. Companies do everything they legally (and illegally to an extent) can to ensure that it's not an efficient market. Further, companies have all the power in the relationship: most of us must have work but a company doesn't absolutely have to hire someone. I saw a 4-person startup on this site say they'd been looking for a "rockstar" for 2 years to expand their company. They were willing and able to wait 2 years for a highly skilled person willing to take a low enough salary. Not many people can wait 2 years to get a job.
To see what a real labor market would look like, you need to address the power balance. So I think sports teams are a better representation because they have unions to address this issue. And they do capture more of the value they produce (not all of it, obviously).
>And your second statement is not true. You simply get cheaper workforce in other countries. Even on senior levels.
Oh, I had assumed you meant the typical outsourcing locations. If you mean places like Europe, yes you can get good senior people for lower rates there. But it's a percentage lower, not X times lower, you can't get a truly senior level person on e.g. 7k/yr. I'm sure there's someone somewhere that has, but they'd have done better to buy a lottery ticket with that luck.
This is good comment, and I wish I had seen it when it was made. The labor market is strange; it actually must be messed up, for profitable ventures to pan out in the software development space (if developers were paid directly according to their contributions, capital would not invest in developer-oriented businesses).
The counterpoint is that you get what you pay for. If you wait 2 years for a rockstar to take a shit salary (and let's be real, someone numerate enough to be a rockstar won't take a bad deal) you also are pricing into your organization that it's not worth it to acquire a rockstar for anything less.
The counterpoint is that you get what you pay for. If you wait 2 years for a rockstar to take a shit salary (and let's be real, someone numerate enough to be a rockstar won't take a bad deal) you also are pricing into your organization that it's not worth it to acquire a rockstar for anything less.
We've recently started hiring for a junior front-end position and we've stumbled upon code bootcamps graduates asking for 120k with one or two demo projects on their github. NYC Area, which I find absurd.
Unsure if it's the mentors at those schools that are telling their students to ask for that much or the students themselves think that companies that want to hire juniors usually have that deep of a pocket.
Unsure if it's the mentors at those schools that are telling their students to ask for that much or the students themselves think that companies that want to hire juniors usually have that deep of a pocket.
I'd argue that it's absurd that we still think 120k is a lot of money when we look around at how expensive things like property are.
My father, with a modest education and a modest first job, was able to get married, raise a child and buy a house near London well before he was 30.
Property in that area is now worth hundreds of thousands and would require a six-figure salary (supposedly a lot of money!!) to be able to qualify for a mortgage to buy.
My father, with a modest education and a modest first job, was able to get married, raise a child and buy a house near London well before he was 30.
Property in that area is now worth hundreds of thousands and would require a six-figure salary (supposedly a lot of money!!) to be able to qualify for a mortgage to buy.
This. Its not that junior devs are overpaid, its that almost every single salaried job is underpaid for the amount of revenue they produce.
If you work for a company and produce a million in value every year and they pay you 100k for it, you are basically accepting that the company was 90% of the reason you made any value at all. For almost every single developer that is not true. On average you could probably make the exact same amount on contract / as a consultant. The fact the business is making fortunes off your work is just exploitative.
This also applies to way more industries than just software, its just most apparent in software because of how many ludicrous buckets of money big tech players are taking home each year while still paying their dev teams only 6 figures.
Your worth to a corporation is the amount of revenue you produce for their bottom line (or how much loss you offset). If you are making them way more money than they are paying you you are being taken advantage of, whether that be at 30k a year or 300k a year.
If you work for a company and produce a million in value every year and they pay you 100k for it, you are basically accepting that the company was 90% of the reason you made any value at all. For almost every single developer that is not true. On average you could probably make the exact same amount on contract / as a consultant. The fact the business is making fortunes off your work is just exploitative.
This also applies to way more industries than just software, its just most apparent in software because of how many ludicrous buckets of money big tech players are taking home each year while still paying their dev teams only 6 figures.
Your worth to a corporation is the amount of revenue you produce for their bottom line (or how much loss you offset). If you are making them way more money than they are paying you you are being taken advantage of, whether that be at 30k a year or 300k a year.
Absolutely. 100. Do you have any revolutionizing ideas about how to change this for the better? I think you could start a movement right here.
Well for starters, losing the mentalities "well if I got paid x when I was a junior, then this junior should also be paid x" and "if I'm a senior earning a, this junior should not be earning more than b" when you reach leadership positions will help.
Having profit-sharing schemes when you run your own business are also helpful. Another alternative would be reserving a sizeable proportion (like 20%) of your company's shares strictly for employee ownership.
Having profit-sharing schemes when you run your own business are also helpful. Another alternative would be reserving a sizeable proportion (like 20%) of your company's shares strictly for employee ownership.
Absolutely this. Income is not zero sum. Someone else fighting to earn more should be incentive for you to do the same, not villainize them as "greedy".
You cannot be greedy in salary negotiations. A company will not keep you on staff if you demand to be paid more than you are worth. If someone can get paid more by fighting for that raise you should be there supporting them 110% and fighting your own battles to be paid justly for your productiveness.
And you cannot feel guilty about the millions who struggle on substantially lower incomes. It is a problem way larger than an individual that only a small fraction of the working class produces trillions in revenue while the rest make close to parity with their productive yields at fractions of what the top end make. That being said, its not something to ignore, but at that scale its social and political. You have to fight the fights in the arenas they are suited for. Avoiding your own right to the fruit of your labor because your labor produces substantially more revenue than someone elses contributes to holding everyone back when competing for just wages.
You cannot be greedy in salary negotiations. A company will not keep you on staff if you demand to be paid more than you are worth. If someone can get paid more by fighting for that raise you should be there supporting them 110% and fighting your own battles to be paid justly for your productiveness.
And you cannot feel guilty about the millions who struggle on substantially lower incomes. It is a problem way larger than an individual that only a small fraction of the working class produces trillions in revenue while the rest make close to parity with their productive yields at fractions of what the top end make. That being said, its not something to ignore, but at that scale its social and political. You have to fight the fights in the arenas they are suited for. Avoiding your own right to the fruit of your labor because your labor produces substantially more revenue than someone elses contributes to holding everyone back when competing for just wages.
We've been getting something similar - data analysts with solely Excel and SQL experience who've been in the industry for < 6 months, looking for $120k starting salaries as data scientists in non-SF/NYC/Seattle locales. I'm sure they're not that interested in the position and just fishing to see if some company will pick them up (and maybe some will, but there's not even close to a shortage of analysts/data scientists to command that type of salary for that experience).
I've seen this attitude also, and it completely turned me off from interviewing bootcamp graduates. I'm sure there are great bootcamp people out there, but a 12 week course + a demo is basically an intern in my book.
hello, recent bootcamp grad in nyc here. pple are asking that much because other companies are offering that much. I'm sympathetic to the cost perspective for employers, but that is actually the price that many companies are willing to pay (source: got multiple >120k offers myself)
Are these just basic junior devs, or are they specialists in another field with multiple advanced degrees from top tier schools ($$$) and professional experience in that other field? (law, medicine, the arts) and (Yale, Princeton, Juilliard) If so, I'd say they are well worth $120,000, probably have a giant body of work in another field, and are motivated to make back their investment in a mountain of education that has led them over and over again to unemployment or low wage work. If not, my guess is that the math of buying so much schooling over so many years (even mid-tier) and then having to buy tuition at a coding school because the competition is so tight they have no time to waste teaching themselves just doesn't work out, especially when they have to pay $2000 a month in rent plus a 5 month security deposit in NYC, just to attend the "free", "scholarship-supported",or "tuition deferred" bootcamp, that is, if they are new to the city. If they are already New Yorkers, they are probably about to be evicted due to non-payment of same. No one is really talking openly about this with respect to this group of people; the affected must hide their ivy league scholarship homelessness at all costs if they want to ever get a job. It leads to a whole new breed of homeless: living as a homeless person/person-on-the-brink-of-homelessness, well educated, loans to pay, healthcare to pay because they aren't young anymore and really have to get root canals and cancer screenings, middle class props, lunches, and clothes to pay for so they can "pass" as middle class at interviews. It is not sustainable. This wave of unemployed people is exceptionally educated and professionally seasoned (in other fields) in a way that most in previous waves of new job seekers didn't have to be. And on top of all of this, they aren't good at the business of being poor-- they don't know how to get support because they were raised to behave like the middle class. Their families don't understand why they can't get jobs. I remember how little a junior dev had to know just 8 years ago in order to get work. The bootcamps aren't being honest about the lack of interest in bootcamp grads. The online programs aren't getting completed by students. Just a year ago on HN, very few would even recognize the lack of interest in junior devs. Now, we can't ignore it anymore. The tech ecosystem is unhealthy and dishonest with itself about its addictions to certain cultures and practices. It needs to take responsibility for educating newcomers (of all ages and backgrounds) because it is responsible for the fact that these highly skilled people are now useless in this increasingly tech-based society. Mentoring should be a natural part of prepping the soil. It should not matter if devs stay at the company that mentored them. The only reason this is a problem right now is because tech behaves like warring nations not like collaborating artists.
You might be having a bit of grass is greener syndrome. I graduated in 2012, so a bit after that 8 year ago mark, but after over a year of the traditional "apply and interview with big tech companies all over the country" and nobody wanting to take on verbatim junior devs (at least not at my skill level at the time) I just pivoted into free software for two years and consulting for small businesses the last three.
There has never been a point in time where corporations were willing to hire on the inexperienced cart blanche to train them. It has always been a problem that nobody wants to foot the proverbial bill of Jimmys first real dev team. It is only getting worse now as more and more people enter the industry but major giants are slowing down their rampant horizontal department growth that gave a large chunk of juniors a path to classical employment in the nulls.
There has never been a point in time where corporations were willing to hire on the inexperienced cart blanche to train them. It has always been a problem that nobody wants to foot the proverbial bill of Jimmys first real dev team. It is only getting worse now as more and more people enter the industry but major giants are slowing down their rampant horizontal department growth that gave a large chunk of juniors a path to classical employment in the nulls.
Yes,perhaps it depends a lot who and where and the year it started to turn. Around 8 years ago, NYC was more open. The free and easy "hey, apply in whatever language you know, we will pay you while you learn ours", etc...this whole notion of "language agnostic" that applies to truly accomplished coders but not juniors. Not really open, just a lot more than it is now. 10 years ago, it was easy to get a junior dev job with basic coding skills. I graduated "several" years before you, friend, so I'll keep that actual number vague ;) I just think it is important that we notice what's happening and notice that they/we can't afford to work for free/very little for may years-- eventually, one can't afford to front anymore, and the bills are coming due, at least here in NYC. We are seeing it in salary demands, lowered enrollment in dev programs, new additions to the severely impoverished (PHD grads who live in their car and take interviews from there). It is important to be truthful about the economy and the state of tech within it and supportive of those who are going through this, and to understand what they are now up against. Because of course mainstream media and similar would have us believe that there really is a giant "skills gap"in tech. I don't think anyone can claim that so vaguely any longer. When "they" suffer, it just means "we" will suffer soon enough.
This is the exact same argument I made the last time we hired. If for another 20% I can get a more proven senior dev, that's the decision I will make every time.
>But that means junior starting salaries around 50k which no one is taking.
Where are these $50k/yr junior positions?
I finished undergrad at a time when $60k/yr was a safe starting point for negotiation but recent searches only show me $15.50/hr at best for a junior. I acknowledge the tenuous distinction, if any, between "junior" and "entry-level" may be a factor for the disparity here.
Where are these $50k/yr junior positions?
I finished undergrad at a time when $60k/yr was a safe starting point for negotiation but recent searches only show me $15.50/hr at best for a junior. I acknowledge the tenuous distinction, if any, between "junior" and "entry-level" may be a factor for the disparity here.
is 50k really such a bad starting salary or is there such a big difference between US and EU?
If you are living somewhere with 2k a month rent, then yes, $50k a year is awful and nigh unlivable.
You should not be in a position where you are working professionally and full time where you have to worry about having enough money each month to survive.
The cost of living is out of control and nobody wants to acknowledge that should reflect rising salaries. It is why there was so much momentum around a $15 minimum wage two years ago.
The economy has not stagnated or contracted. Markets are larger than ever. Corporations are profitable as always and are somehow finding billions to buy each other out rather than pay their employees a respectable wage.
If the momentum and progress of the 50s and 60s held to today the mean salary should be in the $150k a year range, not $50k. The average person is way too complacent to the march of inflation and growth of the economy to think that since $50k was a lot in 1978 that it should still be sufficient in 2018.
You should not be in a position where you are working professionally and full time where you have to worry about having enough money each month to survive.
The cost of living is out of control and nobody wants to acknowledge that should reflect rising salaries. It is why there was so much momentum around a $15 minimum wage two years ago.
The economy has not stagnated or contracted. Markets are larger than ever. Corporations are profitable as always and are somehow finding billions to buy each other out rather than pay their employees a respectable wage.
If the momentum and progress of the 50s and 60s held to today the mean salary should be in the $150k a year range, not $50k. The average person is way too complacent to the march of inflation and growth of the economy to think that since $50k was a lot in 1978 that it should still be sufficient in 2018.
> The cost of living is out of control and nobody wants to acknowledge that should reflect rising salaries.
Alternatively, we could look into reducing cost of living. US is dealing with a legacy system in the form of suburban sprawl that makes housing far more expensive than it has to be because the demand by the biggest generation far outstrips supply (simply due to area constraints and ridiculous zoning policies).
A small dilapidated house built in the 1950s with lead paint and asbestos should not cost $400,000.
Unfortunately, that is politically untenable right out of the gate.
Alternatively, we could look into reducing cost of living. US is dealing with a legacy system in the form of suburban sprawl that makes housing far more expensive than it has to be because the demand by the biggest generation far outstrips supply (simply due to area constraints and ridiculous zoning policies).
A small dilapidated house built in the 1950s with lead paint and asbestos should not cost $400,000.
Unfortunately, that is politically untenable right out of the gate.
To be fair, in the 50s and 60s a lot of the jobs were more engineering than technical, and the US had the advantage of being one of the few nations whose industrial capacity wasn't damaged by World War II. Now, software developers of similar skills in the US and India are paid massively different rates, simply because of cost of living. All the "missed gains" the US has is because money is being funneled to other countries who are starting to produce wares (both soft and hard) that compete with what the US basically had a monopoly on.
There are 2 differences: first, US devs are paid substantially more. Second, their stated salaries is closer to what their employer spends than our salaries. Our employers pay various taxes before giving us our stated salary, they have private insurances. This is a gross oversimplification, but that's the idea. Third, the cost of living is often higher in the US.
To really compare salaries, you need to count what the employer actually pays, and factor in the various costs of living (taxes, insurance, home, food, transportation…).
To really compare salaries, you need to count what the employer actually pays, and factor in the various costs of living (taxes, insurance, home, food, transportation…).
In white collar jobs like software people don't usually have private health insurance (in the US). Employers cover that cost on top of your salary - 90%-100% of cost is typical in the industry, though it depends a biton whether it's just for you / your family.
Correct me if I'm wrong, but when talking US salaries you have to compare it to EU salary before any taxes, deductions, or insurance.
Depends what caliber person you want. Highly educated, motivated, top 10%, maybe even 20% should be able to earn almost $100k upon earning a Masters, maybe even engineering/science degree. In the bigger cities in the US, I would expect most technical/finance/medical professionals to be making six figures easily by the time they are mid to upper 20s.
I clearly live on the wrong continent.
12 years ago I started out of college at $75k. Starting salaries are much higher now if you live in a major tech area (100k+ for SF Bay or new york city).
Well, 50k might be a lot or really low depending on the area and CoL there.
And don't forget that a lot of interns make twice that...
And don't forget that a lot of interns make twice that...
The growth of undergrand CS program enrollment is pretty insane, same with bootcamps.
Lots of these people have no real interest in the positions outside of pay, which is fine for most careers. But in tech we put a lot of value on self learning and interest.
I've definitely seen the number of new grad applicants and bootcamp grad applicants at least quadruple in the past few years.
Most of these can make an Angular app or write an algorithm on a whiteboard but know nothing outside of what was taught in the school/bootcamp.
I find these types really hard to work with, because software is evolving ever so fast and requires such rapid uptake of knowledge that those who aren't self motivated require a lot of reinforcement and have drastically reduced productivity on the job.
I've definitely seen the number of new grad applicants and bootcamp grad applicants at least quadruple in the past few years.
Most of these can make an Angular app or write an algorithm on a whiteboard but know nothing outside of what was taught in the school/bootcamp.
I find these types really hard to work with, because software is evolving ever so fast and requires such rapid uptake of knowledge that those who aren't self motivated require a lot of reinforcement and have drastically reduced productivity on the job.
That's something I have noticed too. In the 90s most people I worked with were genuinely interested in the work and often came from very eclectic backgrounds. Almost nobody had a CS degree. Now it seems a lot of people go into programming because it pays well and looks like a good career but they don't really care for tech. I definitely found the industry more fun in the 90s but that may just be the fact it's becoming a mature industry.
I don't think someone necessarily has to live and breathe code to be good at their job. That kind of focus is hard to maintain forever. When I was new I was constantly reading programming books and now, like, I'm still interested, but other things are going on in my life that also need my attention, you know?
You can lead a horse to the water but you can't make him drink.
It's completely okay to "just" do your job professionally. However, skill development, transfer of skills to junior developers and mentoring is a different issue - if you want to learn from me, you have to want to learn; if you're just here for the paycheck, then I'm not going to go out of my way to educate you even if (which is the case for many junior developers) you're unable to actually do your tasks properly on your own without this help.
People with the desire and capacity to learn go over the "junior" phase very quickly (over a short internship or already during college) and become able to do decent work on their own; but those who don't and really need an actual prolonged "junior developer" role on the team... there's no incentive for the employer to do that, and there's no incentive for the colleagues to spend their effort if it seems wasted on someone who's not into it.
It's completely okay to "just" do your job professionally. However, skill development, transfer of skills to junior developers and mentoring is a different issue - if you want to learn from me, you have to want to learn; if you're just here for the paycheck, then I'm not going to go out of my way to educate you even if (which is the case for many junior developers) you're unable to actually do your tasks properly on your own without this help.
People with the desire and capacity to learn go over the "junior" phase very quickly (over a short internship or already during college) and become able to do decent work on their own; but those who don't and really need an actual prolonged "junior developer" role on the team... there's no incentive for the employer to do that, and there's no incentive for the colleagues to spend their effort if it seems wasted on someone who's not into it.
I can see your perspective. I think we're kind of talking at cross purposes here. I think it's reasonable to expect someone who needs mentoring to pay attention and want to learn. What I don't like is this idea that you need to spend every waking hour on programming or you're just a clocker who has nothing to contribute to a serious team.
This. Mentoring should just be pointing people in a direction and occasional code review. Go do this (for a few days). Let's see what you did. This is good, this should be that, name your variables better, etc.
If you let juniors figure it out the hard way, they will learn better, or they will fail. If they fail to learn by themselves, they will never become senior.*
*Shitty code bases should be given a lot of leeway on the learning curve.
If you let juniors figure it out the hard way, they will learn better, or they will fail. If they fail to learn by themselves, they will never become senior.*
*Shitty code bases should be given a lot of leeway on the learning curve.
> Mentoring should just be pointing people in a direction and occasional code review. Go do this (for a few days). Let's see what you did.
That's one (totally fine) way of mentoring, but it's by no means the only one.
A lot depends on the work environment and the relationship. I work with a couple junior engineers that are also friends, and in addition to "pointing people in a direction", code reviews, etc.:
* We frequently tackle harder issues together, pair-programming style (using a shared tmux session)
* In addition to code-reviewing their work, I have them code-review mine, and I walk them through my code and thought process
* Talks/meetings once a week or more about architecture/up-front design for projects, in which the junior devs are often included or free to attend
* We have a non-work-related Hackerspace that we attend every 2 weeks where we work on side projects / fun creative projects
Certainly this situation is not possible on many development teams, but I just wanted to point out that mentoring is a wide-open thing that has many approaches and options.
That's one (totally fine) way of mentoring, but it's by no means the only one.
A lot depends on the work environment and the relationship. I work with a couple junior engineers that are also friends, and in addition to "pointing people in a direction", code reviews, etc.:
* We frequently tackle harder issues together, pair-programming style (using a shared tmux session)
* In addition to code-reviewing their work, I have them code-review mine, and I walk them through my code and thought process
* Talks/meetings once a week or more about architecture/up-front design for projects, in which the junior devs are often included or free to attend
* We have a non-work-related Hackerspace that we attend every 2 weeks where we work on side projects / fun creative projects
Certainly this situation is not possible on many development teams, but I just wanted to point out that mentoring is a wide-open thing that has many approaches and options.
You can be willing to learn and still have work/life boundaries.
Absolutely - trying to teach people who are not interested in learning requires a very special set of skills, motivation, and personality that few have IMO. It certainly demoralized me as my university teaching responsibilities gradually shifted from small graduate research seminars to overcrowded introductory undergrad surveys, and now in tech roles I make sure to push back whenever my job devolves too far into babysitting. Smart, motivated junior devs are a true pleasure to work with, but unfortunately are still the exception rather than the rule.
I don't think you need to spend all your spare time making side projects or learning new technologies, but I do think a certain amount of professional curiosity is required as a software engineer, just like any other programming job.
I'll probably spend 15-30 minutes every day outside of work reading about new things, or tinkering around with something, even if it's just reading Hacker News, often these things I learn end up being used at work, so I gain new skills at work. It sounds like you're in the same boat.
My father is a network engineer, and he'll spend time in the evening doing things related to his field, he has a very impressive home networking setup. My friends that are electrical engineers play around with electronics in their spare time.
I think that for any professional, to be successful and have a good career you need to have at least some outside interest in your field. Obviously we all have hobbies, I don't sacrifice those because of work, but if you're working in a job where you have no interest you'll never get far.
I'll probably spend 15-30 minutes every day outside of work reading about new things, or tinkering around with something, even if it's just reading Hacker News, often these things I learn end up being used at work, so I gain new skills at work. It sounds like you're in the same boat.
My father is a network engineer, and he'll spend time in the evening doing things related to his field, he has a very impressive home networking setup. My friends that are electrical engineers play around with electronics in their spare time.
I think that for any professional, to be successful and have a good career you need to have at least some outside interest in your field. Obviously we all have hobbies, I don't sacrifice those because of work, but if you're working in a job where you have no interest you'll never get far.
I don't live and breathe programming either. But when I am at work I care about the technology and like to learn new stuff whereas a lot of people I see just do what they are told to do and take their paycheck home. Nothing wrong with that but I find it more fun to work with people who care.
OK, fair enough. I agree with you; I also like to challenge myself with new things. But I like to go home at the end of the day too, you know? Sometimes I think programmer culture gets too self-flagellating.
I hate the whole side-project-after-work thing. Unless you have a real business idea to pursue I think 40 hours per week of focused work is plenty. There are a lot of other cool things in life.
My time spent on side projects went down close to zero just about the time I graduated and became employed full time working 40-45 hour weeks.
I don't see any problem with that though; I'm still learning a lot, and work towards switching projects/companies when that's no longer the case.
I don't see any problem with that though; I'm still learning a lot, and work towards switching projects/companies when that's no longer the case.
I agree completely. But in a vacuum, the developer who codes outside of work probably has more knowledge and experience than the developer who works 40h/week and goes off to other things. Even considering diminishing returns.
Yes and no. I think somebody a little more well-rounded may have other soft skills that are also important.
Yeah that's true, hence in a vacuum. If you want someone to do nothing but code - the person who codes the most often will take the cake.
You almost never want that though. Every job I've ever done involved communicating with stakeholders and team mates, working out requirements, resolving disagreements, etc.
I think there are a handful of other reasons to persue a side-project-after-work, but mostly they'll be highly self-motivated and individualistic. That's not a bad thing; it may just mean that it's not going to be something you spin into a business, but it's something that solves a need in your life, and as such you don't take very seriously.
If it means you're still learning something a little extra, that's great! If not, that's okay too.
If it means you're still learning something a little extra, that's great! If not, that's okay too.
Yeah, that's exactly what I'm getting at.
> When I was new I was constantly reading programming books and now, like, I'm still interested, but other things are going on in my life that also need my attention, you know?
It's not a binary thing. The fact that you were/are interested enough in technology in the past is different than someone who only did the bare minimum. I consider it more of a mindset thing.
It's not a binary thing. The fact that you were/are interested enough in technology in the past is different than someone who only did the bare minimum. I consider it more of a mindset thing.
I didn't work in the 90s, but I'm with you here. I joined the industry out of interest. I didn't know a thing about pay when I started programming. As demand for developers increases and the industry becomes "mainstream", it's inevitable that we'll attract more folks who are purely in it for the high-paying job and "secure lifestyle".
The job of a school teacher is to teach, but your job at a startup is to empower the company to succeed. Part of this is helping the team succeed, but a big part of this is prioritization. There's nothing wrong with prioritizing your resources on someone who is more motivated and has more growth potential by their own choice. After all, if you don't put your all into something, you can't expect others to put their all into you.
The job of a school teacher is to teach, but your job at a startup is to empower the company to succeed. Part of this is helping the team succeed, but a big part of this is prioritization. There's nothing wrong with prioritizing your resources on someone who is more motivated and has more growth potential by their own choice. After all, if you don't put your all into something, you can't expect others to put their all into you.
The attitude that I need to devote myself to the company and forego any outside interests until the company is profitable is really unhealthy. The company I am leaving now wanted me to do that for 5 years. Imagine doing nothing but being at work for 5 years. Or imagine not dating anyone for 5 years because you're spending all your time at the office.
The product is finished now, so I'm leaving, and frankly the only reason I stuck around was because finishing products looks good on a resume.
The product is finished now, so I'm leaving, and frankly the only reason I stuck around was because finishing products looks good on a resume.
In today's environment devotion to a company is most likely a losers game unless you have lots of equity. When they offered pensions and more job security this may have made sense.
During the dotcom boom there were a lot of people attracted to the industry that were ill suited to it. I feel it's a bit like that now again. Then the dotcom crash came and many of those people lost their jobs in the industry but it had a limited impact on those who had true skill and passion for the technology. The rest had go back to the kind of careers that suited them better, like real estate agents...
> Now it seems a lot of people go into programming because it pays well and looks like a good career but they don't really care for tech.
This was already happening in the late 90s. Initially my undergrad was filled with people because CS paid well, but back then at least the first two classes were setup to weed those people out.
This was already happening in the late 90s. Initially my undergrad was filled with people because CS paid well, but back then at least the first two classes were setup to weed those people out.
People in my life have expressed interest in becoming developers and going to bootcamps, and such.
I tell them, it's not really a job, it's more of a lifestyle. You need to love learning, tinkering, and hacking. Want to go to conferences and play around with pet projects. It's a forever evolving field.
I tell them, it's not really a job, it's more of a lifestyle. You need to love learning, tinkering, and hacking. Want to go to conferences and play around with pet projects. It's a forever evolving field.
I hear you on almost everything...I love tinkering, hacking, reading, pondering, side "experiments" (I think "project" is a bit grandiose for what I hack on from time to time)...but holy hell do I hate conferences and things like that. I just don't get it...most every conference I've seen could have been summed up in a quick article or powerpoint...and I don't get any personal thrills from the "live experience". That, and this is mine own super biased experience, every developer I met who was a conference nut was that guy who was obsessed with the "new shiny", who never seems to do any work that isn't greenfield and leaves others to deal with the fallout of various short-lived infatuations...yah, I'm not bitter, heh...but I'll be damned if these guys don't love their conferences;)
I'm from another field, but I love love love conferences. It's like an annual reunion of my peers, days of detailed talks and better questions, and vast amounts of network chat that I find interesting and valuable.
I see a lot of anti-conference comments here on HN, and I don't get it. Every week I've spent at a conference has been highly illuminating and motivating, and recharged my fascination. This is all followed by presentations to the larger team of what I learned so that the benefits of the experience were broadly dispersed.
3-5 days in a new city seems like a huge win with the professional benefits. What am I missing?
I see a lot of anti-conference comments here on HN, and I don't get it. Every week I've spent at a conference has been highly illuminating and motivating, and recharged my fascination. This is all followed by presentations to the larger team of what I learned so that the benefits of the experience were broadly dispersed.
3-5 days in a new city seems like a huge win with the professional benefits. What am I missing?
>It's like an annual reunion of my peers, days of detailed talks and better questions, and vast amounts of network chat that I find interesting and valuable.
I think that's the key. Conferences are only fun if you can actually have a meaningful connection with the people, if they are genuine peers with similar interests instead of just a bunch of people there for their own self-aggrandizement, sneaking around the corners trying to catch someone saying "dongle". Or the ones mainly frequented by socially inept nerds, like Fosdem.
So conferences can often be pretty hit-and-miss.
I think that's the key. Conferences are only fun if you can actually have a meaningful connection with the people, if they are genuine peers with similar interests instead of just a bunch of people there for their own self-aggrandizement, sneaking around the corners trying to catch someone saying "dongle". Or the ones mainly frequented by socially inept nerds, like Fosdem.
So conferences can often be pretty hit-and-miss.
> 3-5 days in a new city seems like a huge win with the professional benefits. What am I missing?
I'm the tech presence at many of my companies industry conferences. The city the conference is in makes no difference because I'm there to meet people and schedule accordingly. Current customers, potential customers, tech people from partners and even competitors are all very valuable interactions.
For me, conferences have turned into a cost effective place to meet in person all of the people I deal with remotely.
I'm the tech presence at many of my companies industry conferences. The city the conference is in makes no difference because I'm there to meet people and schedule accordingly. Current customers, potential customers, tech people from partners and even competitors are all very valuable interactions.
For me, conferences have turned into a cost effective place to meet in person all of the people I deal with remotely.
I liken the bootcamp business to the mortgage lending business before the subprime crisis.
In the beginning, there were plenty of candidates that were suited for careers in software engineering. Now we are at the point where each school has fewer great candidates so they market to a bigger audience.
In the beginning, there were plenty of candidates that were suited for careers in software engineering. Now we are at the point where each school has fewer great candidates so they market to a bigger audience.
They have fewer great candidates (if that is even true) because the hip candidates are looking for the ladder somewhere else-- they can now see they will never get hired based on skill alone, however well developed for a beginner.(and if they had golden personal connections to add to it, they were in the first wave and/or would not be desperate for work) They all have ambitious, skilled, motivated friends who recently spent money on these bootcamps and who didn't get work that was any better than the work they took the course to get out of in the first place. Many can't find work at all. This is getting out there now, from student to student. There is now enough of a din to finally hear above the denials. But I agree, the bootcamps need to demand more of themselves so they don't end up all being hucksters to the few people who are so far away from tech in their lives, they have not yet heard that the ladder has been pulled up long ago. I hope they can learn how to innovate on a grand scale.
How would you filter for a "technically curious" candidate at the junior level (I'm assuming someone who, for example, pursues a Master's or beyond demonstrates this to a degree)?
It certainly doesn't help that an overwhelming amount of junior postings are more interested in the candidate being experienced with the particular stack, so, unless your interests happen to align with what's industrially pragmatic, I imagine the kid who stays overnight in the lab doing something in Haskell or some other "obscure but requires a non-trivial amount of autodidacticism" activity wouldn't be very happy about those valuable nights in their youth bearing them no fruit.
It certainly doesn't help that an overwhelming amount of junior postings are more interested in the candidate being experienced with the particular stack, so, unless your interests happen to align with what's industrially pragmatic, I imagine the kid who stays overnight in the lab doing something in Haskell or some other "obscure but requires a non-trivial amount of autodidacticism" activity wouldn't be very happy about those valuable nights in their youth bearing them no fruit.
How to you filter out those who are genuinely interested in self learning and motivated to keep up with evolving software trends vs. salary chasers? And more importantly, how can someone from a self-taught background convey that they are not just chasing salaries, but have a real interest in this stuff?
I fear that there is a bias in the industry that bootcampers = salary chasers and CS undergrads = real deal, when I've seen (anecdotally) a huge uptick in people entering CS undergrad programs just for the high salaries fresh out of school.
I fear that there is a bias in the industry that bootcampers = salary chasers and CS undergrads = real deal, when I've seen (anecdotally) a huge uptick in people entering CS undergrad programs just for the high salaries fresh out of school.
Most junior level positions are being filled with the massive influx of new grads from really strong intern programs at most companies now. If you're in college now, make sure you get an internship at a company in your field. If it's too late for that, then you'll have to do a little extra work and probably work on a couple side projects and post them on GitHub. That first job will always be the hardest to get, so don't feel bad if you keep getting turned down.
Definitely agree with this. It's not that the junior developer position doesn't exist anymore, it's that there's an overwhelming supply of strong candidates with the CS pedigree, multiple internships, side projects, and well balanced technical/soft skills.
For juniors to be cost effective/neutral, you can only really have 1-2 per mid/senior engineer. Most companies don't have that many mid/senior engineers to begin with, much less ones that are willing to take on a junior to mentor for a year or two.
It takes a better part of a decade to transition a junior into an independent, mentoring capable senior. The current software boom only started in 2009ish. That means there's only a few cohorts of seniors created in this cycle, and I would guess not very many of them given the job market in 09. Give it time, years of experience don't just happen overnight.
For juniors to be cost effective/neutral, you can only really have 1-2 per mid/senior engineer. Most companies don't have that many mid/senior engineers to begin with, much less ones that are willing to take on a junior to mentor for a year or two.
It takes a better part of a decade to transition a junior into an independent, mentoring capable senior. The current software boom only started in 2009ish. That means there's only a few cohorts of seniors created in this cycle, and I would guess not very many of them given the job market in 09. Give it time, years of experience don't just happen overnight.
> For juniors to be cost effective/neutral, you can only really have 1-2 per mid/senior engineer. Most companies don't have that many mid/senior engineers to begin with, much less ones that are willing to take on a junior to mentor for a year or two.
I think you're off by the reciprocal of the ratio. It should be something like two experienced devs per junior dev. Any more junior devs than that and your senior devs are spending too much of their time mentoring and not enough time getting their tasks done, which is going to frustrate them. Fortunately, with a good junior dev, it doesn't take long at all to reach mid-level dev. I've seen it happen in under a year for smart new grads.
I think you're off by the reciprocal of the ratio. It should be something like two experienced devs per junior dev. Any more junior devs than that and your senior devs are spending too much of their time mentoring and not enough time getting their tasks done, which is going to frustrate them. Fortunately, with a good junior dev, it doesn't take long at all to reach mid-level dev. I've seen it happen in under a year for smart new grads.
When I say cost neutral, I mean from a productivity standpoint. The 2x junior+senior accomplish the same amount of work as the senior would by themself.
It takes about a year for a junior+senior combo to be more productive than a senior alone. And another year before they're not a noticeable cost on the senior. 2x senior to a junior definitely brings the junior up to speed faster, but I think it's less efficient use of the seniors cause it also introduces a synchronization cost between the seniors.
I like to stagger the juniors so they're not at the same level; the +1 junior can take some part of the workload of mentoring the fresh junior. Plus it starts them on practicing mentoring early in their career. The fresh junior still has two mentors, and there's a clear pecking order.
It takes about a year for a junior+senior combo to be more productive than a senior alone. And another year before they're not a noticeable cost on the senior. 2x senior to a junior definitely brings the junior up to speed faster, but I think it's less efficient use of the seniors cause it also introduces a synchronization cost between the seniors.
I like to stagger the juniors so they're not at the same level; the +1 junior can take some part of the workload of mentoring the fresh junior. Plus it starts them on practicing mentoring early in their career. The fresh junior still has two mentors, and there's a clear pecking order.
I remember being a Sophomore in college 5 years ago, and it was hard even finding an internship. My first internship was unpaid because it was the only one that actually called me back.
It's funny how many business cards I picked up from recruiters during career fairs, only to have none of them return my calls or emails.
It's funny how many business cards I picked up from recruiters during career fairs, only to have none of them return my calls or emails.
This seems like a pretty common misunderstanding of the point of recruiting events.
The recruiters aren’t there to let you know they’ve got jobs. They’re there to talk in person to young people, and figure out which ones have passion for the company/project/etc., and put the passionate people’s resumes at the top of the queue.
If you just pick up a business card, it’s indistinguishable from being a cold call/spray and pray resume sender; companies and recruiters get so many of these there’s a good chance no human ever even looked at your resume.
The recruiters aren’t there to let you know they’ve got jobs. They’re there to talk in person to young people, and figure out which ones have passion for the company/project/etc., and put the passionate people’s resumes at the top of the queue.
If you just pick up a business card, it’s indistinguishable from being a cold call/spray and pray resume sender; companies and recruiters get so many of these there’s a good chance no human ever even looked at your resume.
I did not mean to imply that I LITERALLY just collected business cards and spoke to no one. Of course, doing so at recruiting events would be absurd.
So, I don't think it's a common misunderstanding. I think it's common sense that you're supposed to speak to the recruiters and build your network.
So, I don't think it's a common misunderstanding. I think it's common sense that you're supposed to speak to the recruiters and build your network.
Ah! In that case, sorry to hear you had such a hard time! If you talked to recruiters with enthusiasm and gave them your name/resume, I think you did the right thing.
This. If you're graduating without an internship or two, you're in trouble.
As someone who graduated in the summer of 2016 without having done any internships, I wholeheartedly agree with this sentiment.
Finding a job was much more difficult than I thought it would be. Part of that is because I was looking in a very specific geographic area so I could live with my girlfriend (now wife) , part of it was a low GPA, but most of it was because I didn't have any experience outside of college classes.
Eventually I lucked out and found a job with a company that was looking to train someone because they develop software for IBM mainframes and weren't having any luck finding people in that field in the area.
Finding a job was much more difficult than I thought it would be. Part of that is because I was looking in a very specific geographic area so I could live with my girlfriend (now wife) , part of it was a low GPA, but most of it was because I didn't have any experience outside of college classes.
Eventually I lucked out and found a job with a company that was looking to train someone because they develop software for IBM mainframes and weren't having any luck finding people in that field in the area.
Define "trouble". I'm ten years into my career now, but I graduated with no internships and feel like I've done OK.
I think he is referring to people entering the field now. If they don't have internships then it will be hard for them to compete with others vying for Junior Dev positions that have done internships.
Also applied when I started work in 2001. Having 3 months experience as an intern I think helped - making me appealing to smaller companies who needed someone to get stuck in rather than the big companies that spend the first 10 weeks in a training course. (Those companies were not doing well in 2001)
Anecdotally, I didn't factor in internships at all when I was last hiring for a jr. I didn't interview a single person who didn't have a public code repo.
You don't consider real world work experience relevant when hiring? Just side projects or contributions to open source projects?
That seems like you're looking for someone who lives and breathes programming. Do you have something against developers who work 40 hours a week and instead of programming as a hobby as well, they do other, non-tech, things for their hobby?
That seems like you're looking for someone who lives and breathes programming. Do you have something against developers who work 40 hours a week and instead of programming as a hobby as well, they do other, non-tech, things for their hobby?
I don't consider work experience relevant at all unless I can verify the work done or hold a particular recommendation in high esteem. Not getting fired for a length of time, while a skill, is not often what I care most about. Without knowing a company's policies, culture, and tech leads I cannot accurately judge whether someone spent 3 years playing ping pong with the CEO or was responsible for programming a successfully delivered system. In a perfect world, I might try to suss out each candidate's strength and then decide based on the totality of data, but I don't often have that kind of time. I look for public or provided code first, and if it's reasonable, will use that to begin a pointed conversation on our trade.
I was asked about that kind of "programmer universe" stuff during my interview process with my current employer. I said I didn't have a GitHub, never been to a programming conference, didn't participate in the local dev scene, and didn't really program on my free time. I said in my free-time I like being outside, hiking, camping, and fishing...It didn't hurt me because I got the job, of course, I'm working for a utility company and not some flashy SV/NY tech startup...
You aren't graduating then are you? You graduated ten years ago. So they weren't addressing you.
I didn't do a single internship either when I was doing my undergraduate either. I wouldn't recommend doing that to young people in a million years now.
I didn't do a single internship either when I was doing my undergraduate either. I wouldn't recommend doing that to young people in a million years now.
As in it will be a lot harder to get your first job. Once you have that first position or two, it's not really trouble from there obviously. I'd also point out that the dynamics of the junior dev position and the competition have changed a lot since 10 years ago. I suspect this level of experience wasn't as needed in 2006 or 2010 (maybe in 08 after the market crash).
The job market for newly graduated programmers is a little different than it was 10 years ago. I'm 20 years into a development career, but I'm not going to pretend that what was true about the market when I entered it was true about it when you did.
You're already 10 years in. Completely different.
This is 100% true in my experience as well. I hadn't thought of it before, but this seems like a major ethical problem for the industry -- from MegaCorp's perspective, internships are by far the best way to find junior talent, but access to internships is gated on being in a program at a top school with all the accumulated bias that implies.
I've seen some efforts at work along these lines, but nothing within even probably two orders of magnitude of the established internship program.
Curious if anyone is aware of companies offering entry level contract positions that aren't conditional on active enrollment in an academic program?
I've seen some efforts at work along these lines, but nothing within even probably two orders of magnitude of the established internship program.
Curious if anyone is aware of companies offering entry level contract positions that aren't conditional on active enrollment in an academic program?
/agree
I love hiring and mentoring junior developers, but the barrier to entry is quite high. Employers love junior developers with aptitude and enthusiasm.
I love hiring and mentoring junior developers, but the barrier to entry is quite high. Employers love junior developers with aptitude and enthusiasm.
A hypothesis for part of the problem that I've scrolled through most of this conversation and still not seen: Junior developers are having a hard time finding a job because the tasks have gotten harder. As easy as people may claim "cloud" is, if a junior developer has to learn the three Javascript libraries, two backend languages, a devops cloud deployment system, and three monitoring technologies just to be able to break even on productivity, it's going to be hard to justify hiring a "junior dev".
When I got into web dev in 1997, we didn't even have source control to speak of. We barely used Javascript. All I needed was a template language and same basic HTML, and we put out a project that, at the time, was considered amazingly cutting edge by most people who used it.
If I were to try to hire me of 1997 now, I'd have a lot harder time finding something for him to do, because I'd have half-a-dozen technologies to train him on before he could even produce the equivalent of "hello world" that integrates correctly into a modern environment. All of these techs have reasons to exist. We found out about the server going down when people got frustrated about it being down and called us after hours of outage. We found out that something was eating 100% of the CPU the same way. Our "analytics" were mostly "Hmmm, nobody seems to be complaining, everything must be OK!" Automated testing? Literally never heard of it. And so on and so on. But people are not magically infused with this knowledge in college; in fact the curricula have barely changed since then (which I consider mostly a good thing), so it means that the bar to being a productive junior dev has definitely risen.
Fortunately, my team lately has been able to diversify and we've got some more projects that are independent from the legacy code base I maintain, so as we've been looking at headcount this year I've been able to say that we've got some positions for juniors now, who can work in a space that is more lake-like than sea-like, and be productive, and learn things, and develop. But last year I had to say that I've got nothing that wouldn't take at least a medium-skill dev to get anywhere in any reasonable period of time.
(And let me both open and close on the word part. I don't think this is the entire problem, and I agree with a lot of what other people said about other parts. But I believe it may be a quite non-trivial part of it.)
When I got into web dev in 1997, we didn't even have source control to speak of. We barely used Javascript. All I needed was a template language and same basic HTML, and we put out a project that, at the time, was considered amazingly cutting edge by most people who used it.
If I were to try to hire me of 1997 now, I'd have a lot harder time finding something for him to do, because I'd have half-a-dozen technologies to train him on before he could even produce the equivalent of "hello world" that integrates correctly into a modern environment. All of these techs have reasons to exist. We found out about the server going down when people got frustrated about it being down and called us after hours of outage. We found out that something was eating 100% of the CPU the same way. Our "analytics" were mostly "Hmmm, nobody seems to be complaining, everything must be OK!" Automated testing? Literally never heard of it. And so on and so on. But people are not magically infused with this knowledge in college; in fact the curricula have barely changed since then (which I consider mostly a good thing), so it means that the bar to being a productive junior dev has definitely risen.
Fortunately, my team lately has been able to diversify and we've got some more projects that are independent from the legacy code base I maintain, so as we've been looking at headcount this year I've been able to say that we've got some positions for juniors now, who can work in a space that is more lake-like than sea-like, and be productive, and learn things, and develop. But last year I had to say that I've got nothing that wouldn't take at least a medium-skill dev to get anywhere in any reasonable period of time.
(And let me both open and close on the word part. I don't think this is the entire problem, and I agree with a lot of what other people said about other parts. But I believe it may be a quite non-trivial part of it.)
I've been saying this for a while, and I think it will lead to the demise of the bootcamps, and is already causing a cascade of unemployment in low-skill indian IT from what I read. The bar is simply getting higher. I think this is a good thing overall. It's also why I care almost exclusively about CS fundamentals in technical interviews, unless we have a very specific need.
How does exclusively interviewing on CS fundamentals get you people who are good at the job?
I didn't say I interviewed only on fundamentals, just that it was what I almost exclusively cared about - for junior devs. It's a good sign that the person understands core concepts behind many different types of software, and would be teachable on the job.
I find this observation really interesting! I've found that 10 years ago I was a more 'mature' full stack developer - I did front end, backend and ops type stuff. As complexity has grown I've absolutely shied away from keeping up with anything on the frontend and I avoid ops things as much as possible. It's probably not very wise on my part. These days I would absolutely not be able to call myself a full stack dev.
I've noticed this as well. The personal project that netted me my first job was really just a LAMP CRUD site for torrents. Not a single person would be impressed by that today.
> LAMP CRUD site for torrents
Impressed? Today that would result in an early morning police raid on your apartment.
Impressed? Today that would result in an early morning police raid on your apartment.
This reminds my of my job search 5 year ago after I graduated college. It took me 8 months to land my first job and I was living with my mother. I did work on some side projects to build my knowledge on some technologies. When my mom asked me what I was doing and I said I worked on project 'x' she would say "I think you should be sending out more job applications instead." Working on side projects is not an option for everyone.
What did get me hired was neither working on side projects nor blanket submissions of applications. A friend introduced me to another friend who's company he worked for was hiring and he gave me a list of open reqs for jobs he knew managers were looking to fill. I got two calls for interviews the next week and got an offer for one job by the end of the month.
IMHO your network, not even what you know or what you've done, is your most important asset when looking for work.
What did get me hired was neither working on side projects nor blanket submissions of applications. A friend introduced me to another friend who's company he worked for was hiring and he gave me a list of open reqs for jobs he knew managers were looking to fill. I got two calls for interviews the next week and got an offer for one job by the end of the month.
IMHO your network, not even what you know or what you've done, is your most important asset when looking for work.
Couldn't agree more, I feel that this is extremely under emphasized. Meetups and networking events are the best places to get your foot in the door imo. It's the easiest way to separate yourself from the troves of resumes a recruiter may be sifting through on a daily basis, bypass all the politics and nuances of looking perfect on paper, and in the very least be set up for an interview (where you can prove your skills through explanation and whiteboards).
I'm biased though because I got my first two jobs this way.
I'm biased though because I got my first two jobs this way.
I can relate to that. Fresh out of college and having to move back home during the recession, my parents insisted I be delivering resumes full-time, preferably by mail and in person, rather than "dicking around" on the computer. (No comprehension of what I had studied, of course.)
Eventually I worked things out, with a dose of luck, but I can't help thinking I'd be far better off today if I'd managed to publish some personal projects during that time and networked those around to like-minded associates.
Eventually I worked things out, with a dose of luck, but I can't help thinking I'd be far better off today if I'd managed to publish some personal projects during that time and networked those around to like-minded associates.
My personal experience with this is that the ratio matters A LOT. I.e. having juniors out number the seniors is bad.
When you have a team that mostly consist of junior and mid-level developers, then they will clique together and they will mostly likely "behave" like juniors. Typical junior behaviour is e.g. to rather than digging into the backlog for the next thing to work on when you're done with one thing, to just sit around and wait for a senior to give you the next task.
However, if you have a team of seniors, who behave like seniors, adding one junior to this team, the junior will in no-time start to behave like a senior. Act by example. Before you know it you will have a really valuable team member.
When you have a team that mostly consist of junior and mid-level developers, then they will clique together and they will mostly likely "behave" like juniors. Typical junior behaviour is e.g. to rather than digging into the backlog for the next thing to work on when you're done with one thing, to just sit around and wait for a senior to give you the next task.
However, if you have a team of seniors, who behave like seniors, adding one junior to this team, the junior will in no-time start to behave like a senior. Act by example. Before you know it you will have a really valuable team member.
I've had the opposite problem with juniors in the past -- rush to solve tickets and get them committed, but the work done is awful. I honestly preferred the lazy juniors on the team. At least they were doing poor work but there was less of it to code review and fix.
I used to be on the pro junior side of things... but when you're on the earlier side of a startup (series a/b), juniors are a huge liability.
Best "junior" hire I made was recruiting someone in support who I thought was smart and conscientious. Turned him on to programming, mentored him, and now he's great.
I have no idea what the lesson from this has been. hiring is hard.
I used to be on the pro junior side of things... but when you're on the earlier side of a startup (series a/b), juniors are a huge liability.
Best "junior" hire I made was recruiting someone in support who I thought was smart and conscientious. Turned him on to programming, mentored him, and now he's great.
I have no idea what the lesson from this has been. hiring is hard.
This is insightful. A senior dev shouldn’t be a “manager” for a group of juniors. It should be the norm.
The mistake I think is seeing junior/senior devs as a management hierarchy (in which you normally have a more senior person manage more than one junior staff member).
The mistake I think is seeing junior/senior devs as a management hierarchy (in which you normally have a more senior person manage more than one junior staff member).
I remember being a junior. I'd either go looking for more to do, or take a bit of extra time to experiment with different ways to do whatever I was given.
Maybe this is more a personality thing, and it's just that people who don't think a certain way don't really make it to senior?
Maybe this is more a personality thing, and it's just that people who don't think a certain way don't really make it to senior?
My two cents: simple supply and demand. The slow deflation of the startup bubble of the past five years or so has killed the junior developer. Once upon a time, there so much competition for engineering talent in the startup world that even developers with little to no experience and/or formal training were being handed lucrative jobs.
Looking back we see clear signs of a seller's market in talent: companies went out of their way to hire anyone remotely competent. Once hired, devs could hopefully rely on their company's mentorship, training, and experience opportunities to raise themselves up, and companies could rely on the same for retention. Coding boot camps sprung up to give people just enough skills and credibility to get their foot in the door. Salaries were high.
That gold rush has since dried up. Early stage funding has plummeted. Fewer and fewer companies want to go public. Large companies like Google, Facebook, etc. now dominate their respective product categories. Why is it now difficult to find senior people? Because for someone with years of experience and/or formal training, these companies offer the holy trinity of excellent pay, top-tier perks, and opportunities for career growth.
My personal opinion is that many of these junior devs simply aren't very good. As someone who conducts interviews at one of those aforementioned big companies, I'm consistently disappointed by how poorly most candidates perform on basic interview questions. And I don't mean the kind that test book knowledge of some obscure algorithm, I'm talking basic coding tasks.
From where I stand it's a matter of an oversupply of inexperienced, under-qualified developers that are no longer being absorbed into startups desperate for warm bodies to do rudimentary coding tasks, coupled with a strong demand for senior folks from big companies with the coffers to pay them.
Looking back we see clear signs of a seller's market in talent: companies went out of their way to hire anyone remotely competent. Once hired, devs could hopefully rely on their company's mentorship, training, and experience opportunities to raise themselves up, and companies could rely on the same for retention. Coding boot camps sprung up to give people just enough skills and credibility to get their foot in the door. Salaries were high.
That gold rush has since dried up. Early stage funding has plummeted. Fewer and fewer companies want to go public. Large companies like Google, Facebook, etc. now dominate their respective product categories. Why is it now difficult to find senior people? Because for someone with years of experience and/or formal training, these companies offer the holy trinity of excellent pay, top-tier perks, and opportunities for career growth.
My personal opinion is that many of these junior devs simply aren't very good. As someone who conducts interviews at one of those aforementioned big companies, I'm consistently disappointed by how poorly most candidates perform on basic interview questions. And I don't mean the kind that test book knowledge of some obscure algorithm, I'm talking basic coding tasks.
From where I stand it's a matter of an oversupply of inexperienced, under-qualified developers that are no longer being absorbed into startups desperate for warm bodies to do rudimentary coding tasks, coupled with a strong demand for senior folks from big companies with the coffers to pay them.
I'm curious about what the common deficiencies that your encountering are. Do you mean lack of knowledge and testing and more applicable skills?
Unfortunately I can't share the exact questions we ask, but here's a smattering of the sorts of pitfalls I encounter, in no particular order:
* Number one is probably no Big-O performance considerations, or Big-O is an afterthought. For the love of God, please please please don't do a linear search on an unsorted array anywhere inside a nested loop. If you're going to do any appreciable number of lookups, preprocess your data into a hashmap, hashset, whatever.
* No or insufficient considerations for edge cases. What if the input array is empty? What if I pass in invalid arguments? What if the strings aren't ASCII? What if the numbers you're multiplying are very large? What if the input is coming from an untrusted source?
* No questions about the size of the input. Some of my favorite questions are those whose solutions bifurcate on whether the input can fit on in memory, or whether it's coming in on a network stream. Some questions involve multiple arrays, and I always like to ask "you assume A is much bigger than B, but what if A is much smaller than B?"
* We place a great deal of weight not just on the solution, but on justifying why that solution is the most appropriate one. More often than not, this hinges on the Big-O performance and the system on which we're running. It's a mistake to dive right in to your solution, because it robs you of the opportunity to demonstrate that you have multiple fully-formed ideas knocking around in your head and you need to choose which one to code up. Otherwise I might get the impression that you only have one way to solve a problem.
* Sorting the entire array when I ask you for the top N elements! Getting the top handful of elements is a linear-time operation, people!
Bonus points:
* No consideration for parallel processing. I've run maybe like two serial production workflows in my entire career. Try to parallelize your solution to handle bigger inputs.
* Don't forget cache performance! I usually let candidates working in Python or other high-level languages slide on this one, but those odd C/C++ candidates have a major opportunity to impress me by optimizing their memory access patterns for cache performance.
* I let this one go for intern and entry-level candidates, but testing should never be an afterthought. The moment you finish your implementation you should throw input/expected output pairs on the whiteboard. You don't even need to walk through them super carefully, just show me that you know how to design test cases.
* Number one is probably no Big-O performance considerations, or Big-O is an afterthought. For the love of God, please please please don't do a linear search on an unsorted array anywhere inside a nested loop. If you're going to do any appreciable number of lookups, preprocess your data into a hashmap, hashset, whatever.
* No or insufficient considerations for edge cases. What if the input array is empty? What if I pass in invalid arguments? What if the strings aren't ASCII? What if the numbers you're multiplying are very large? What if the input is coming from an untrusted source?
* No questions about the size of the input. Some of my favorite questions are those whose solutions bifurcate on whether the input can fit on in memory, or whether it's coming in on a network stream. Some questions involve multiple arrays, and I always like to ask "you assume A is much bigger than B, but what if A is much smaller than B?"
* We place a great deal of weight not just on the solution, but on justifying why that solution is the most appropriate one. More often than not, this hinges on the Big-O performance and the system on which we're running. It's a mistake to dive right in to your solution, because it robs you of the opportunity to demonstrate that you have multiple fully-formed ideas knocking around in your head and you need to choose which one to code up. Otherwise I might get the impression that you only have one way to solve a problem.
* Sorting the entire array when I ask you for the top N elements! Getting the top handful of elements is a linear-time operation, people!
Bonus points:
* No consideration for parallel processing. I've run maybe like two serial production workflows in my entire career. Try to parallelize your solution to handle bigger inputs.
* Don't forget cache performance! I usually let candidates working in Python or other high-level languages slide on this one, but those odd C/C++ candidates have a major opportunity to impress me by optimizing their memory access patterns for cache performance.
* I let this one go for intern and entry-level candidates, but testing should never be an afterthought. The moment you finish your implementation you should throw input/expected output pairs on the whiteboard. You don't even need to walk through them super carefully, just show me that you know how to design test cases.
And I hate to say it, but this right here is the problem with the industry.
You're expecting a junior dev to know and apply details of edge cases, complex character sets, runtime and space complexity, parallel processing and behavior of caching.
This is not junior level knowledge. You're looking for a mid-level to senior developer with zero experience. Yes it's possible to find, but that's not junior level knowledge. But most of them all things that are easily learn-able on the job. You're expecting a junior dev to be familiar with and easily able to apply all aspects of software development but just not have done it. This is absurd.
A junior dev should be able to handle bug fixes, well scoped and defined features, and have a small area of ownership. Guess what, they're working for you, they need to find the 5 largest elements in an array. The sort the entire thing and then take the top 5. They send their code for code review. You have a 5 min conversation with them on how you don't need to sort the full thing. They say "ah that's cool, hadn't seen that trick before". They now implement it and know it for life.
This absurd idea that you wouldn't hire this person instead of investing in a 5 min conversation with them is a large part of the problem with the industry.
You're expecting a junior dev to know and apply details of edge cases, complex character sets, runtime and space complexity, parallel processing and behavior of caching.
This is not junior level knowledge. You're looking for a mid-level to senior developer with zero experience. Yes it's possible to find, but that's not junior level knowledge. But most of them all things that are easily learn-able on the job. You're expecting a junior dev to be familiar with and easily able to apply all aspects of software development but just not have done it. This is absurd.
A junior dev should be able to handle bug fixes, well scoped and defined features, and have a small area of ownership. Guess what, they're working for you, they need to find the 5 largest elements in an array. The sort the entire thing and then take the top 5. They send their code for code review. You have a 5 min conversation with them on how you don't need to sort the full thing. They say "ah that's cool, hadn't seen that trick before". They now implement it and know it for life.
This absurd idea that you wouldn't hire this person instead of investing in a 5 min conversation with them is a large part of the problem with the industry.
My thoughts kinda echo this, but I don't think it's outlandish for a junior dev to know a lot of this - what's less reasonable is knowing it with enough depth that they can bring it all to bear without prep in an interview. They've had fewer opportunities to put these things into practice, so I'd only expect them to demonstrate proficiency if they knew ahead of time to study those fairly specifically.
Exactly. In junior interview I accept passing mentions and hand-wavey verbal solutions. What I'm referring to here is a complete absence of awareness of these things.
I should be clear, I'm not expecting someone to write up a bulletproof solution to every possible edge case on a whiteboard in 35 minutes. I expect them simply to be familiar with the things that can go wrong. Add a check at the beginning to return false if the array is empty. Tell me your solution will get hairy if I expect you to handle Unicode, have a three-sentence exchange with me as to why, and implement an ASCII-only solution as a first pass.
My time, and the time of everyone on my team, is far too valuable to be spent on teaching new hires things they should have learned on their own in junior year of college. Onboarding people means bringing them up to speed on the complexities and specifics of our own systems. We're not in the business of hiring people and holding their hand for a year until they know enough CS to be useful.
Also:
> This is not junior level knowledge. You're looking for a mid-level to senior developer with zero experience.
Zero professional experience, maybe. Zero experience period, no. This stuff is offered in almost all undergrad CS programs. If you didn't go to college or have a degree in a different field you can find tons of lists of topics for self-study. If you've ever done any project on the side, you're bound to have encountered or at least imagined a couple of these issues. Something as basic as finding the largest N elements in a array isn't a trick, it's something that should be painfully obvious to anyone who's coded for more than a month.
My time, and the time of everyone on my team, is far too valuable to be spent on teaching new hires things they should have learned on their own in junior year of college. Onboarding people means bringing them up to speed on the complexities and specifics of our own systems. We're not in the business of hiring people and holding their hand for a year until they know enough CS to be useful.
Also:
> This is not junior level knowledge. You're looking for a mid-level to senior developer with zero experience.
Zero professional experience, maybe. Zero experience period, no. This stuff is offered in almost all undergrad CS programs. If you didn't go to college or have a degree in a different field you can find tons of lists of topics for self-study. If you've ever done any project on the side, you're bound to have encountered or at least imagined a couple of these issues. Something as basic as finding the largest N elements in a array isn't a trick, it's something that should be painfully obvious to anyone who's coded for more than a month.
> Something as basic as finding the largest N elements in a array isn't a trick, it's something that should be painfully obvious to anyone who's coded for more than a month.
Not a trick? Of course it's a trick.
The efficient way to do it is to heapsort the array, but just stop after you've popped N elements from the heap.
You can do much worse and still stay in pure linear time (though as I noted in another response to you, the difference in polynomial order between O(n) and the O(n log n) that would be required to finish your heapsort is ε, where ε is larger than zero but smaller than any real number): just scan the array N times, looking for the largest element that's smaller than your shrinking upper bound. I'd rather see a solution that sorted than one that took N passes to pull N elements -- sorting will be faster -- but the N passes approach is pure linear time.
Then again, naive N passes will fail when the array contains duplicates. To avoid that, you'll need to allocate a data structure to hold your N answers, and implement a way of adding values in and having it appropriately discard the lowest value when you add to it while it's full. That's starting to look like a trick. It also cuts you down to one pass.
Is the "not a trick" answer you're looking for implementing an N-running-maxes data structure, or remembering how to heapsort? Do you really care about getting your results in slow linear time instead of fast "so close to linear you can't even tell the difference" time?
Not a trick? Of course it's a trick.
The efficient way to do it is to heapsort the array, but just stop after you've popped N elements from the heap.
You can do much worse and still stay in pure linear time (though as I noted in another response to you, the difference in polynomial order between O(n) and the O(n log n) that would be required to finish your heapsort is ε, where ε is larger than zero but smaller than any real number): just scan the array N times, looking for the largest element that's smaller than your shrinking upper bound. I'd rather see a solution that sorted than one that took N passes to pull N elements -- sorting will be faster -- but the N passes approach is pure linear time.
Then again, naive N passes will fail when the array contains duplicates. To avoid that, you'll need to allocate a data structure to hold your N answers, and implement a way of adding values in and having it appropriately discard the lowest value when you add to it while it's full. That's starting to look like a trick. It also cuts you down to one pass.
Is the "not a trick" answer you're looking for implementing an N-running-maxes data structure, or remembering how to heapsort? Do you really care about getting your results in slow linear time instead of fast "so close to linear you can't even tell the difference" time?
I see where you're coming from on some points, such as complex character sets and caching. But runtime and spacetime complexity are basic concepts which should be taught in any respectable CS degree program. Looking for edge cases and writing good tests ought to be taught as well. Also I'd hope parallel algorithms would get some time in a CS degree, but that one could be somewhat negotiable.
Can you define what a 'respectable' CS program is? I'm currently taking a core CS class online for fun at a major public university and its nothing earth shattering. In fact, I'd go as far as saying that I get more out of blogs and study aides like 'cracking the coding interview' than this class.
Dunno how i should feel about this.
Somehow i got into Tech Industry without a fitting degree and found myself in a smallish (30 people) company as the only SysAdmin. Exploring, setting, and controlling all technical parts this office needs: Multiple Linux VMs with different services like smb, confluence, ...; AD- and Terminal Windows Server; Device-Managment of all used MacBooks; and so on.
I always also liked to code stuff, and always found a way to archive what i tried to solve. But of course i never build something big or even though about things like super efficient ways to archive what i did. I always though that when i keep going and try to build my small personal projects, one day i can maybe start as a junior dev. Even without the degree. But your post somehow states that a junior dev has to think about edge cases even before they occur. As a Sysadmin i also have to do this. But i always imagined that the job as developer is no one man show, and that these edge cases will be found together. Code will be reworked when a more experienced team member found a pithole.
Somehow i got into Tech Industry without a fitting degree and found myself in a smallish (30 people) company as the only SysAdmin. Exploring, setting, and controlling all technical parts this office needs: Multiple Linux VMs with different services like smb, confluence, ...; AD- and Terminal Windows Server; Device-Managment of all used MacBooks; and so on.
I always also liked to code stuff, and always found a way to archive what i tried to solve. But of course i never build something big or even though about things like super efficient ways to archive what i did. I always though that when i keep going and try to build my small personal projects, one day i can maybe start as a junior dev. Even without the degree. But your post somehow states that a junior dev has to think about edge cases even before they occur. As a Sysadmin i also have to do this. But i always imagined that the job as developer is no one man show, and that these edge cases will be found together. Code will be reworked when a more experienced team member found a pithole.
First off, congrats on landing in your role! Sysadmin and development are completely different skillsets in my mind, and I have as much admiration for sysadmins as they seem to have for me.
My company doesn't really do small projects anymore, so we take a lot of care to make sure we hire people with the discipline and ability to handle large systems. There's certainly a lot of organizations that don't have that requirement, though, so some of this assessment may be a little harsh.
As for code review catching errors, that sounds great in theory, but in practice it's just rarer than you'd think. Think about it, your reviewer is always going to spend less time on your code than you did, and they're always going to have less context. I find that unless the error is egregious, it's almost never the code reviewer that catches it. You're not really a one man show, but you're pretty close.
Unit testing is by far a better approach. I catch easily ten times as many bugs in my code by unit testing it as by manual inspection and code review combined.
My company doesn't really do small projects anymore, so we take a lot of care to make sure we hire people with the discipline and ability to handle large systems. There's certainly a lot of organizations that don't have that requirement, though, so some of this assessment may be a little harsh.
As for code review catching errors, that sounds great in theory, but in practice it's just rarer than you'd think. Think about it, your reviewer is always going to spend less time on your code than you did, and they're always going to have less context. I find that unless the error is egregious, it's almost never the code reviewer that catches it. You're not really a one man show, but you're pretty close.
Unit testing is by far a better approach. I catch easily ten times as many bugs in my code by unit testing it as by manual inspection and code review combined.
Most of these things are not “junior” level at all. There are exceptional people though and I suppose it makes sense for you to try and hire those. But large amounts of disappointment are very much part of the process then.
>Number one is probably no Big-O performance considerations, or Big-O is an afterthought. For the love of God, please please please don't do a linear search on an unsorted array anywhere inside a nested loop. If you're going to do any appreciable number of lookups, preprocess your data into a hashmap, hashset, whatever.
Big O should be an afterthought - the MO of any developer ought to be to get it right and then refactor - and worry about speed after profiling. Premature optimization is an antipattern you should be selecting against, not for.
Big O should be an afterthought - the MO of any developer ought to be to get it right and then refactor - and worry about speed after profiling. Premature optimization is an antipattern you should be selecting against, not for.
No. Leaving landmines like an easily avoidable linear search in a loop is an
antipattern.
> Sorting the entire array when I ask you for the top N elements! Getting the top handful of elements is a linear-time operation, people!
Unlike your other points, this one seems unlikely to cause any trouble in practice. From a polynomial-order perspective, a factor of log N is literally infinitesimal, essentially free.
Unlike your other points, this one seems unlikely to cause any trouble in practice. From a polynomial-order perspective, a factor of log N is literally infinitesimal, essentially free.
From what you asked, I can deduce you work in an environment where performance is important.
For my startup (and I'd say at least a non-negligible number of companies), half of what you ask is just not important.
Background to read what follows: small 5-year old startup with 2 developers, which don't do anything "complicated" like ML, computation or things like (mostly apps, with a CRUD back-end).
I'll try to rephrase as what I'd expect instead:
* Big-O is not important there. What you need to know is to have some knowledge to how to leverage your DB to do things instead of looping yourself over data just queried from your DB. And that's not number one.
* Edge cases is actually a valid concern for every programmer, no matter the field
* it might be useful to have a rough idea of what you expect to offer a proper solution, but it's generally pretty obvious
* justifying a solution is also a valid concern for every programmer, no matter the field
* manually doing operations already handled by your framework/library is a red herring, barring very specific situations that require an explanation. Be it sorting, filtering or whatever.
Bonus point
* bringing manual parallel processing reeks of premature optimization (as an environment where performance isn't generally a problem, remember). It has to have a real explanation, and other obvious optimizations have to be done already. So far, I've never reached that point in my professional career (but tools I use DO use parallel processing, I just don't roll it out myself, that would be NIH syndrome)
* don't forget caching! If the cache performs badly, it's time to start investigating why, but you don't need to worry about cache performance if you don't do crazy things, for the most part.
* Testing is also important wherever you go, but I also let this one slide because entry-level candidate aren't teached that in school, unfortunately.
For my startup (and I'd say at least a non-negligible number of companies), half of what you ask is just not important.
Background to read what follows: small 5-year old startup with 2 developers, which don't do anything "complicated" like ML, computation or things like (mostly apps, with a CRUD back-end).
I'll try to rephrase as what I'd expect instead:
* Big-O is not important there. What you need to know is to have some knowledge to how to leverage your DB to do things instead of looping yourself over data just queried from your DB. And that's not number one.
* Edge cases is actually a valid concern for every programmer, no matter the field
* it might be useful to have a rough idea of what you expect to offer a proper solution, but it's generally pretty obvious
* justifying a solution is also a valid concern for every programmer, no matter the field
* manually doing operations already handled by your framework/library is a red herring, barring very specific situations that require an explanation. Be it sorting, filtering or whatever.
Bonus point
* bringing manual parallel processing reeks of premature optimization (as an environment where performance isn't generally a problem, remember). It has to have a real explanation, and other obvious optimizations have to be done already. So far, I've never reached that point in my professional career (but tools I use DO use parallel processing, I just don't roll it out myself, that would be NIH syndrome)
* don't forget caching! If the cache performs badly, it's time to start investigating why, but you don't need to worry about cache performance if you don't do crazy things, for the most part.
* Testing is also important wherever you go, but I also let this one slide because entry-level candidate aren't teached that in school, unfortunately.
The thing about performance is that it doesn't matter until it does. A young organization can easily get away with hiring people who don't know about or don't care about performance for years. I get it, features need to get pushed, the business needs to move on. That's fine in the short term. For some organization even longer.
Sooner or later, though, that approach will come back to bite you. Milliseconds matter to the user because the longer they wait for an action to complete, the more likely they are to stop caring. They matter in settings where you're performing multiple RPCs because a millisecond of delay here and there adds up over multiple calls. Not to mention the fact that memory, CPU, and disk all cost money. And when those factors come up, you'll suddenly find yourself surrounded by people who are (at worst) incapable of addressing the situation or (at best) will need to be ramped up on the issue.
And that's just constant factor improvements. Can you imagine choosing an O(NlogN) solution over an O(N) one? Everyone thinks that's trivial, but in real terms it means a 10x speedup per thousand inputs and 20x per million inputs. That's huge.
More importantly: in interviews, a lack of care for performance suggest to me that a candidate is willing to cut corners. Once they have any old solution they pat themselves on the back and move on. We're a very self-driven organization, and in my experience if a new hire is struggling to meet expectations 6-12 months after joining, it's usually because they don't constantly ask themselves how they can improve their work and our codebase and instead expect to be told what to do.
Minor pet peeve: parallel processing is not premature optimization! If you think it is then I suggest you exercise it more. It's not as hard as people make it out to be, and at a certain point it becomes second nature. Then all of a sudden terabyte datasets start looking trivial...
Sooner or later, though, that approach will come back to bite you. Milliseconds matter to the user because the longer they wait for an action to complete, the more likely they are to stop caring. They matter in settings where you're performing multiple RPCs because a millisecond of delay here and there adds up over multiple calls. Not to mention the fact that memory, CPU, and disk all cost money. And when those factors come up, you'll suddenly find yourself surrounded by people who are (at worst) incapable of addressing the situation or (at best) will need to be ramped up on the issue.
And that's just constant factor improvements. Can you imagine choosing an O(NlogN) solution over an O(N) one? Everyone thinks that's trivial, but in real terms it means a 10x speedup per thousand inputs and 20x per million inputs. That's huge.
More importantly: in interviews, a lack of care for performance suggest to me that a candidate is willing to cut corners. Once they have any old solution they pat themselves on the back and move on. We're a very self-driven organization, and in my experience if a new hire is struggling to meet expectations 6-12 months after joining, it's usually because they don't constantly ask themselves how they can improve their work and our codebase and instead expect to be told what to do.
Minor pet peeve: parallel processing is not premature optimization! If you think it is then I suggest you exercise it more. It's not as hard as people make it out to be, and at a certain point it becomes second nature. Then all of a sudden terabyte datasets start looking trivial...
These are pretty hard questions for an average junior role. But depends on a company.
As someone starting to teach myself how to code, I'd be interested to hear more about the basic coding tasks people are failing at.
As someone else who have hired developers I agree with the parent post here.
Examples include:
- totally oblivious to standard library for the language/frameworks, reimplementing the most basic things (poorly)
- even after a 3 year CS education, lacks basic understanding of object-oriented programming/class hierarchies
- has trouble implementing even simple if/else-conditions without help
I’m talking really basic stuff here. You’d be surprised. I assume that if you are self-taught, you have the interest and because of that already much more knowledge than many graduates.
Examples include:
- totally oblivious to standard library for the language/frameworks, reimplementing the most basic things (poorly)
- even after a 3 year CS education, lacks basic understanding of object-oriented programming/class hierarchies
- has trouble implementing even simple if/else-conditions without help
I’m talking really basic stuff here. You’d be surprised. I assume that if you are self-taught, you have the interest and because of that already much more knowledge than many graduates.
The if/else part is really astonishing. The other ones I can understand in SOME way but the if/else is logic that's used in every day life. If I do this then that will happen, otherwise this other thing may happen. Very surprising.
"The other ones I can understand in SOME way"
Not me, "OOP class hierarchys" still incomprehensible gibberish here.
Not me, "OOP class hierarchys" still incomprehensible gibberish here.
We have a pre-interview test that is basically "use flickr's api to show some pictures", with a few details about how the pictures are sized and arranged. Applicants that have gone to bootcamps and even college frequently fail this miserably. Many of the rest fail to understand the details. We even had one use a completely different end point than the one specified by URL to the documentation. Some have just given up and turned nothing in, or something that they admitted didn't work.
These are candidates that we liked their resume enough to give them a shot, not just anyone who applied.
These are candidates that we liked their resume enough to give them a shot, not just anyone who applied.
I think teaching is a bit behind on the rest api thing, probably isn’t specifically taught. Doesn’t mean they couldn’t learn it.
Why do you refuse to mentor a few of them? /s
Why do you refuse to mentor a few of them? /s
That's, errr, a very high bar you got there.
People got it working, showing they can code just fine, and you fail them because they got some details wrong?
People got it working, showing they can code just fine, and you fail them because they got some details wrong?
If you have only one or two positions open, have no trouble finding applicants, why not give a test that has a 5% pass rate if that means you end up with 6 people to choose from and still have to turn people away? What would the advantage be of making it easier just so you would have to review and turn even more people away?
We aren't looking for someone that has to be told repeatedly to read the entire ticket and actually do everything in it. We're looking for detail-oriented people.
And we find them. It's so much easier to work with them.
And we find them. It's so much easier to work with them.
that's a super regular bar that anyone who's moderately able to program or learn new things should be able to jump over easily. details are important in a technical field.
For me it would be lack of intuition / imagination for building software.
Some people just cannot come up with a high level idea of a solution. Many of them immediately jumps into code, even worse so it's usually some UI code.
Some people just cannot come up with a high level idea of a solution. Many of them immediately jumps into code, even worse so it's usually some UI code.
I gave a little writeup to a sibling comment, PTAL.
Graduating and going through the hiring process last year, I realized how true this is and how important your tech pedigree is. I recieved no full time offers before interning at Apple last summer, and after the internship I had no trouble getting offers (ended up with 5 full time offers). There wasn't any difference in how I described my interests before and after the summer internship, the only difference was companies wanted to see that I was vetted by a big name company. The real experience I had, working at a startup for three years before that yielded very little value in recruiting, even though the experience there made me a much better engineer and it was a successful startup that got acquired.
Are companies hiring differently, or are we just defining the terms differently?
"Junior developer" used to refer to someone who can program but who doesn't have a lot of practical experience.
Today "junior developer" refers to someone who can't program but who has a CS degree or went to a bootcamp, and there are more of those today as a proportion of the talent pool than there have ever been.
I think this failure of academic institutions to teach practical skills is diluting the talent pool, causing companies to favor more experienced engineers because they've been getting burned and don't trust their own (or academic institutions') ability to determine in advance whether a candidate will be a productive programmer or not.
"Junior developer" used to refer to someone who can program but who doesn't have a lot of practical experience.
Today "junior developer" refers to someone who can't program but who has a CS degree or went to a bootcamp, and there are more of those today as a proportion of the talent pool than there have ever been.
I think this failure of academic institutions to teach practical skills is diluting the talent pool, causing companies to favor more experienced engineers because they've been getting burned and don't trust their own (or academic institutions') ability to determine in advance whether a candidate will be a productive programmer or not.
As far as I know, academic education is not meant to deliver practical skills, but rather theory and deeper understanding. CS degree is not a programming degree but the equivalent of theoretical physics.
It's become an unfortunate trend that the academy has somehow become stuck with the role of doing vocational education, rather than research and theory.
It's become an unfortunate trend that the academy has somehow become stuck with the role of doing vocational education, rather than research and theory.
I am a junior developer on my first job as a developer at a startup with around 50 developers.
The company, luckily, has a very opposite approach to hiring jr devs than what is described in the article. There are usually one or two jr developers per squad of 4 or 5 people (which is actually a maximum, the company is aiming only at more mid-level or senior devs right now).
There is a very collaborative environment, a lot of help from all senior developers - not only the ones in my squad.
What I think is missing in the economics there is that I (and all other jr developers) do provide measurable value to the company after 2 or 3 months. I am able to create simple, but necessary and demanded by the business, features by myself, just with senior developers reviewing my PRs.
This idea that junior developers are a drag to senior developers is fake in my (limited) experience. I make the senior developer in my team more productive most of the time, and after around 8 months in the job, we are actually hiring another junior developer because I think I am ready to take some of the responsibility of mentoring him/her on a basic level.
I am pretty sure that I am a net positive to the company on a $ invested per value delivered ratio.
The company, luckily, has a very opposite approach to hiring jr devs than what is described in the article. There are usually one or two jr developers per squad of 4 or 5 people (which is actually a maximum, the company is aiming only at more mid-level or senior devs right now).
There is a very collaborative environment, a lot of help from all senior developers - not only the ones in my squad.
What I think is missing in the economics there is that I (and all other jr developers) do provide measurable value to the company after 2 or 3 months. I am able to create simple, but necessary and demanded by the business, features by myself, just with senior developers reviewing my PRs.
This idea that junior developers are a drag to senior developers is fake in my (limited) experience. I make the senior developer in my team more productive most of the time, and after around 8 months in the job, we are actually hiring another junior developer because I think I am ready to take some of the responsibility of mentoring him/her on a basic level.
I am pretty sure that I am a net positive to the company on a $ invested per value delivered ratio.
When I hire, It's ONLY junior devs.
I prefer just out of University before they can get bad habits. Training a dev takes me 6-12 months for them to break even productivity wise.
When we have had intermediate or seniors hired they would not listen to anyone else or care if their software was easy to maintain in the future. I run a small team of 6, I have had 0 turnover for 3-4 years.
I don't want devs who "get it done" I want devs that enjoy the work and want to share it.
I prefer just out of University before they can get bad habits. Training a dev takes me 6-12 months for them to break even productivity wise.
When we have had intermediate or seniors hired they would not listen to anyone else or care if their software was easy to maintain in the future. I run a small team of 6, I have had 0 turnover for 3-4 years.
I don't want devs who "get it done" I want devs that enjoy the work and want to share it.
Not listening to feedback and ignoring future maintainability sounds like the exact opposite of senior behavior.
I think the "Junior" title is used entirely by companies to get a discount at salary negotiations these days. I work with a large mix of mid level, senior, and "Junior" developers by title. The practical difference in our technical skill levels is almost nonexistent. The proper progression should be: Intern -> Developer -> Senior/Lead, with Senior/Lead denoting that certain expectations are made of your organizational and management skills moreso than seeking genius rockstar programmers.
There is absolutely a skill difference between senior and junior. The problem is that junior developers today somehow think they deserve mid or senior level salaries despite not having the skills.
Developers are being told not only that higher level skills like algorithms and big-oh don't matter, but that they are such special people that they can even do jobs completely outside of their specialty like design, management, and other things.
Developers want to be paid like lawyers, but without the equivalent domain knowledge in CS that lawyers have in law.
Developers are being told not only that higher level skills like algorithms and big-oh don't matter, but that they are such special people that they can even do jobs completely outside of their specialty like design, management, and other things.
Developers want to be paid like lawyers, but without the equivalent domain knowledge in CS that lawyers have in law.
Hey, man, if people want to pay me well and give me lofty titles I am not going to dissuade them. As developers I don't think that's our problem to worry about. Seeking out the most benefit for yourself is just common sense in the job market we live in and I'm not losing a lot of sleep over the prospect that I'm not as "expert" in my job as a lawyer is.
>I'm not losing a lot of sleep over the prospect that I'm not as "expert" in my job as a lawyer is
I actually apply this logic in reverse. After seeing how lacking many "senior" developers are - given that we now call you "senior" after just 5 measly years - I've come to realize I shouldn't put much weight in the skills of lawyers (and other professionals) who only have 5 years of experience. Since we're not lawyers (for example), it's easy for us to give them more credit than they deserve, because we don't know enough about the domain to criticize them.
After just a couple of years experience, developers can still write pathetic spaghetti code. If you're gonna high a lawyer with a couple of years under their belt, imagine them bungling your case like it's the codebase!
I actually apply this logic in reverse. After seeing how lacking many "senior" developers are - given that we now call you "senior" after just 5 measly years - I've come to realize I shouldn't put much weight in the skills of lawyers (and other professionals) who only have 5 years of experience. Since we're not lawyers (for example), it's easy for us to give them more credit than they deserve, because we don't know enough about the domain to criticize them.
After just a couple of years experience, developers can still write pathetic spaghetti code. If you're gonna high a lawyer with a couple of years under their belt, imagine them bungling your case like it's the codebase!
While I don't think you're a bad person for doing those things, can you see how this (repeated by enough people) produces the new-entrant-hostile hiring environment we currently have?
Sure, but I think it would be foolish to do otherwise. I was new once too, and even after I'd done my first job people were hesitant to call me back with no relevant degree and my only experience being in a small shop mostly working alone (for significantly less than the market rate, I should add). Now I managed to make my way past that gauntlet and I'm enjoying the fruits of my labors as
a "senior" developer. I don't think I'm doing anything other than responding to the incentives created by the system.
Absolutely! Though would you still consider yourself a "senior" developer, if a "mid-level" or "junior" starts working with you and happens to exceed your skillset in very noticeable ways? I know I've hired some exceedingly excellent programmers that made me feel rather amateurish!
I guess what I'm trying to say titles are fairly arbitrary - and yes, the system is in need of a little shake up! Enjoy the perks the title brings, and stay humble :)
I guess what I'm trying to say titles are fairly arbitrary - and yes, the system is in need of a little shake up! Enjoy the perks the title brings, and stay humble :)
The titles are more or less arbitrary anyway. I'm not that hung up on it.
So is working for a living wage. Imagine how much room there would be for new entrants if you were paid $8 an hour! Everyone who wanted to could have a programming job.
I don't think you know many lawyers. Lawyers tend to have a lot of depth and little breadth of knowledge. They specialize. Most good computer people have one or two things the specialize in.
But algorithms and big-oh don't matter. All the CS stuff, by and large, doesn't matter. It's like learning biology when you're a Doctor. Might be slightly useful if you have certain jobs, but if you're a GP it's almost entirely useless. The difficulty in programming a web app is almost entirely complexity management.
I just recreated a multi-million pound company's functionality without a single algo or any thought of big-o.
Can you explain what deep algos or big-o knowledge I need to recreate booking.com. uber, airbnb, etsy, flickr, imgur, etc., but without their scale? Or maybe making an internal data input app with a basic rules engine, which virtually every business needs these days? No big o, as if you're only handling 10 million or so hits a year, you can make some pretty big mistakes and still have a nicely performing site. For algos maybe you might need one algo depending on the business, a ranking algo, or perhaps a pathfinding algo, something that will be extensively discussed on SO and laid out entirely for you, or you might just plug a library in. No CS knowledge required.
I just recreated a multi-million pound company's functionality without a single algo or any thought of big-o.
Can you explain what deep algos or big-o knowledge I need to recreate booking.com. uber, airbnb, etsy, flickr, imgur, etc., but without their scale? Or maybe making an internal data input app with a basic rules engine, which virtually every business needs these days? No big o, as if you're only handling 10 million or so hits a year, you can make some pretty big mistakes and still have a nicely performing site. For algos maybe you might need one algo depending on the business, a ranking algo, or perhaps a pathfinding algo, something that will be extensively discussed on SO and laid out entirely for you, or you might just plug a library in. No CS knowledge required.
I mostly agree with you, but I feel like there is benefit in the knowledge of how inputs/processes do affect performance (aka Big O) as that demonstrates just a deeper level of thinking.
It's pretty easy to get someone to understand doing stuff more than you have to is bad aka (no data calls in loops, sort at the DB not on the server, etc), but it's another type of developer to say "hey, this works good for now, but if this client has over X# of widgets we're going to run into performance problems, why don't we see if we can build a caching layer to share data across widgets".
Just that type of person in a room bringing up those issues saves close to 100 man hours by the time that bug gets found by a client, escalated through client support, pointed, moved into a sprint, retested, etc. That's saving the company a lot of money in a very concrete way and delivering a better product.
It's pretty easy to get someone to understand doing stuff more than you have to is bad aka (no data calls in loops, sort at the DB not on the server, etc), but it's another type of developer to say "hey, this works good for now, but if this client has over X# of widgets we're going to run into performance problems, why don't we see if we can build a caching layer to share data across widgets".
Just that type of person in a room bringing up those issues saves close to 100 man hours by the time that bug gets found by a client, escalated through client support, pointed, moved into a sprint, retested, etc. That's saving the company a lot of money in a very concrete way and delivering a better product.
So if I work at company A as a junior and get paid the same salary as a senior at company B, why is it bad that my expectation is to keep getting paid at the level of A even if I want to switch jobs?
Or does your comment apply to fresh grads? Because then your comment would make more sense to me.
Or does your comment apply to fresh grads? Because then your comment would make more sense to me.
"The problem is that junior developers today somehow think they deserve mid or senior level salaries despite not having the skills."
If other companies are willing to pay those salaries, why would you say they don't deserve them?
If other companies are willing to pay those salaries, why would you say they don't deserve them?
Business is rife with people getting things they don’t deserve.
Why would you equate availability with appropriateness?
Why would you equate availability with appropriateness?
> I think the "Junior" title is used entirely by companies to get a discount at salary negotiations these days.
I think there's some truth here. What I consider some proof of this, is an unsolicited recruiter email I received today. The role was called junior web developer, a $25.00/hr contract only position, but listed a mathematics or CS degree as a requirement. Like, am I nuts to think this is preposterous?
I think there's some truth here. What I consider some proof of this, is an unsolicited recruiter email I received today. The role was called junior web developer, a $25.00/hr contract only position, but listed a mathematics or CS degree as a requirement. Like, am I nuts to think this is preposterous?
When recruiters reach out to me, I just list them what I expect including salary expectation. If they still respond after that, then it is mostly worth my time.
But I noticed hiring practices here in Europe are much better anyways than in the US.
But I noticed hiring practices here in Europe are much better anyways than in the US.
I would say in addition to Intern -> Developer -> Senior/Lead where Lead is Org and management skills you need a Senior/Expert path too.
Some devs will never want any management duties and you shouldn't give it to them. However, they then probably are going to be a master or have really deep knowledge in something valuable to the company.
Some devs will never want any management duties and you shouldn't give it to them. However, they then probably are going to be a master or have really deep knowledge in something valuable to the company.
There are differences in skill between developers. Titles rarely reflect this though. Titles mostly reflect politics, perception and luck.
I've long maintained a maxim that's something like "Look in the opposite direction of everyone else." So when everyone flocks to the bay area, get the heck out of there. When everyone says "I have no space for junior devs" think about how you can take advantage of that underutilized resource.
Junior devs are cheap. If you're willing to spend the time to sift -- and you will be doing a lot of resume sifting -- and setup a framework for mentorship, you can hire junior devs with more promise than your average senior dev.
Anecdotally, one of my junior hires from a few years ago earned his way through positions quickly and became a senior software engineer in just three years. I actually invited him to be my co-founder on my next venture and he turned me down :-P.
Junior devs are cheap. If you're willing to spend the time to sift -- and you will be doing a lot of resume sifting -- and setup a framework for mentorship, you can hire junior devs with more promise than your average senior dev.
Anecdotally, one of my junior hires from a few years ago earned his way through positions quickly and became a senior software engineer in just three years. I actually invited him to be my co-founder on my next venture and he turned me down :-P.
I understand the appeal of Seattle and the Bay Area, but it sometimes boggles my mind that larger tech companies don't build in cities where there are a large number of new grads looking for jobs. [0] LA county produces the most CS grads in the country, [1] and most of them are moving out of the area and up the coast for lack of junior SWE openings in SoCal. Any of the Big N could have a monopoly on talent coming out of USC, UCLA, Cal Tech, UCI, UCSB, UCSD, Harvey Mudd, Cal Poly, etc.
[0] https://datausa.io/profile/cip/110701/#counties_most_degrees
[1] https://www.ocregister.com/2017/07/24/is-southern-california...
[0] https://datausa.io/profile/cip/110701/#counties_most_degrees
[1] https://www.ocregister.com/2017/07/24/is-southern-california...
Hiring juniors in LA has been delightful; so many strong candidates, no real competing offers. That being said, it's also pretty easy to poach burnt out, fed up experienced juniors from the Bay Area.
Poach said junior devs from the Bay Area to LA or in general? Sort of confused with your second statement. The crazy thing is that every one of my CS major friends I graduated with at USC moved up the coast to the Bay Area or Seattle, or to the east coast in NYC.
Bay Area to LA but in general too; many grads leave the LA area, so it's not a hard sell to get them to come back after they pick up some experience. Bay Area just happens to be the biggest consumer of fresh graduates.
This is one of the most important posts I’ve read on HN in a while. 7 years ago I broke in as an inexperienced dev without a degree because some budget strapped team took a (hedged) chance on me and offered a paid internship. They mentored me a huge amount in a way I have never seen at another company, as well as several other junior devs. Most every one is in a senior position today, and some have stayed at the company. This is not happening anymore as far as I can tell - I know plenty of people with the knack for it but the door seems to be closed, because companies do not want to take the risk.
This has been going on for years. Back in the mid 80's when I was going to college I knew a lot of people had come back to get their masters are even change fields because they couldn't find jobs. Employers wanted 2-3 years minimum experience and the new grads lamented how were they supposed to get said experience? My first job I worked FREE for the first 3 months at a startup (they didn't have the money to make a payroll anyway). Ultimately that launched my career and got me past the 2-3 years experience issue. This was back in the 80's!
>the rate is anywhere from $190-$300 an hour
Well there's your problem. Valley pricing. You can get Sr Devs much cheaper than that. Then you can afford to train up some juniors.
I don't think that's the real problem though. Companies want you to take the risk/expense of learning a technology that might be obsolete next year. They'll pay you back in salary if you lucked up and mastered the right stack. If you didn't, then you keep eating ramen until you strike gold.
The other problem is most Sr.s don't want a Jr. coming in and making negative contributions. Sr.s are frequently the ones doing the interviews. They see most Jr.s as "What's a computer?" level talent that will start fires in production systems.
Well there's your problem. Valley pricing. You can get Sr Devs much cheaper than that. Then you can afford to train up some juniors.
I don't think that's the real problem though. Companies want you to take the risk/expense of learning a technology that might be obsolete next year. They'll pay you back in salary if you lucked up and mastered the right stack. If you didn't, then you keep eating ramen until you strike gold.
The other problem is most Sr.s don't want a Jr. coming in and making negative contributions. Sr.s are frequently the ones doing the interviews. They see most Jr.s as "What's a computer?" level talent that will start fires in production systems.
> The other problem is most Sr.s don't want a Jr. coming in and making negative contributions. Sr.s are frequently the ones doing the interviews. They see most Jr.s as "What's a computer?" level talent that will start fires in production systems.
I think this is pertinent, when you're already too busy doing things and keeping stuff running, who has the time to handle a run-of-the-mill junior?
The most successful launches I've seen is where a junior comes in and can already contribute _at some level_, this is always due to the extra curricular work they've done outside of their education (if indeed they had any higher level education at all).
The spectrum of jobs out there allows a creative (or lucky, in my case) junior to springboard. Think of 'started out modifying and configuring wordpress themes, ended up writing some custom code and extensions, ended up learning laravel and databases' type of progression. You won't be working in bleeding edge AI or at Google on their self driving cars, but you'll be solving problems for people, and that's a career.
I think this is pertinent, when you're already too busy doing things and keeping stuff running, who has the time to handle a run-of-the-mill junior?
The most successful launches I've seen is where a junior comes in and can already contribute _at some level_, this is always due to the extra curricular work they've done outside of their education (if indeed they had any higher level education at all).
The spectrum of jobs out there allows a creative (or lucky, in my case) junior to springboard. Think of 'started out modifying and configuring wordpress themes, ended up writing some custom code and extensions, ended up learning laravel and databases' type of progression. You won't be working in bleeding edge AI or at Google on their self driving cars, but you'll be solving problems for people, and that's a career.
> Well there's your problem. Valley pricing. You can get Sr Devs much cheaper than that.
The article seems to be referring to how much agencies are hiring out their senior developers for. Which, $190-300/hr. does not seem atypical in that scenario, even outside the valley. The developers themselves won't be making anywhere near that much.
Since this company seemingly makes its money by having the senior developers doing billable work for clients, the article suggests that the business doesn't want them spending time helping junior developers and thus not billing (or, perhaps, billing at the junior rate).
The article seems to be referring to how much agencies are hiring out their senior developers for. Which, $190-300/hr. does not seem atypical in that scenario, even outside the valley. The developers themselves won't be making anywhere near that much.
Since this company seemingly makes its money by having the senior developers doing billable work for clients, the article suggests that the business doesn't want them spending time helping junior developers and thus not billing (or, perhaps, billing at the junior rate).
>The other problem is most Sr.s don't want a Jr. coming in and making negative contributions. Sr.s are frequently the ones doing the interviews. They see most Jr.s as "What's a computer?" level talent that will start fires in production systems.
A system where a Jr can easily start fires is a system that's bound to fail. It means whatever you use for production is incredibly fragile and bound to be broken even by a more senior developer making a single mistake.
A system where a Jr can easily start fires is a system that's bound to fail. It means whatever you use for production is incredibly fragile and bound to be broken even by a more senior developer making a single mistake.
I teach at a Bootcamp and see a lot junior developers looking for jobs. Many of them complain of it being hard to find jobs and it is. But I don’t think it is any harder than say 10 years ago when I got started. The main the problem is they’ve never interviewed for a technical position before or aren’t looking in the right places for jobs. Also a lot of jobs are perfectly suited for juniors but it doesn’t reflect that in the job description. So there are a lot of things that make the job search hard and frustrating but the jobs are out there. And I would love to see more companies more actively mentor people too. But those companies do exist today. It’s just a numbers game. If you can hold out, you’ll find it.
I think bootcamps are flooding the market with juniors. This may be the source of the issue. It could be a supply side issue. Too many juniors leads to the perception that nobody is hiring juniors.
Or maybe too many badly trained people (sorry a 6 week JS course doesn't make you a good developper) are trying to bullshit themselves through interviews, which casts a bad light on all of them.
Could be both. Could be too many badly trained people and too many people who are "good enough." I know plenty of bootcamp developers who have successfully gotten a job.
Searching for a job is way easier if you have a professional network to draw on and beginners, pretty much by definition, really don't.
> a professional network
How? Let's say I work at some company...Then I know exactly my coworkers and customers. How does that help me build a network?
I could maybe ring up some buddys from uni that are working somewhere else... But contact to them also gets lost over time.
How? Let's say I work at some company...Then I know exactly my coworkers and customers. How does that help me build a network?
I could maybe ring up some buddys from uni that are working somewhere else... But contact to them also gets lost over time.
I found the job I have now because I was foundering and a college friend put me in touch with a recruiter who was a good match. Now that I've worked in industry for a while, I have colleagues who've moved to other companies I can ask them about. Sometimes old bosses will get in touch and ask me if I'm interested in joining their companies. The more positive experiences people have had working with you the more doors are open.
>But contact to them also gets lost over time
That's probably a mistake on your part, especially when tools like LinkedIn make it so easy.
That's probably a mistake on your part, especially when tools like LinkedIn make it so easy.
Yeah. In particular, it's often your looser acquaintances who have something for you.
Indeed, one of my bigger customers now was in a junior role at a company I did some work for years ago. You never really know where opportunities might lie and it costs little to keep in touch.
I think people also get too shy about reaching out to people they haven't been in touch with. Most people aren't going to be annoyed if you say, "Hey, long time no see. How have you been? Wondering if you know anyone who's hiring" or whatever it is you're asking for.
Completely agree, among my peers at university those who had spent the last four years creating a network on Twitter and Github did significantly better at finding a graduate job than those who didn't.
Most of my friends have the job they have because of a combination of Twitter and attending conferences on discounted student tickets.
Most of my friends have the job they have because of a combination of Twitter and attending conferences on discounted student tickets.
totally agree.
I would say a good 10-20% do have some kind of contact in the industry though and get a job that way.
I would say a good 10-20% do have some kind of contact in the industry though and get a job that way.
Honestly, I think a lot of what you are paying for with the boot camp is the promise that their network and industry contacts will help you. Otherwise it's pretty much impossible (at least in my view) to justify those tuition rates.
Having gone through a bootcamp, I can also say there's the "we know what we're getting," factor. The job I got hired into afterwards, they knew I would be competent to a certain degree because they'd already hired out of that bootcamp before, and the bootcamp had pretty strict standards about who made it to Career Day. That was a definite factor in my getting hired.
Not to say this would or wouldn't justify various tuition rates - but it's definitely part of the equation.
Not to say this would or wouldn't justify various tuition rates - but it's definitely part of the equation.
Well, right, that ties in with the rest of it. It's like having someone to vouch for you to help get your foot in the door.
If you look at long term value, the tuition is really nothing. At a good bootcamp even without any industry contacts you will probably have a job in 6 months. Sure your salary will be lower than a CS grad, but you'll also have way less debt.
But yes look at placement rates at any bootcamp before joining. If people are getting jobs then it's well worth it.
But yes look at placement rates at any bootcamp before joining. If people are getting jobs then it's well worth it.
Right, I suppose what I mean to say is, if you were "just" learning how to program, it probably wouldn't be worth it, because you could learn just as well on your own for practically nothing (order some books on Abebooks and watch some videos on Coursera and you've got a decent curriculum). But if you do that you haven't made any contacts and don't have anyone to vouch for your skills.
A good analogy is a bootcamp is like a personal trainer. Sure you could do jumping jacks yourself but when someone yells at you to get them done, you do it more often and faster. Some people need that extra push through.
But yes some people have plenty of self motivation and can do it themselves. The career networking is really all they need then.
But yes some people have plenty of self motivation and can do it themselves. The career networking is really all they need then.
I did it the free route but I considered a boot camp a bit just for the network, so that's where I'm coming from.
Oh yeah watch out for bootcamps that juice their placement stats by hiring their own grads a lot. It's normal to hire a few grads for teaching assistants but if you see more than that be weary.
I’ve helped several friends get into programming with no prior experience. A few of them did a boot camp. I told all of them that what they needed was to spend a year working hard on a personal project nights and weekends to get enough hours coding, to hit real world problems and have to deal with them, and to have a portfolio piece. The boot camp, if they took it, would be a jump start to get going, but not a guaranteed job.
This recipe worked out for all of them so far. Just being able to code “off script” without the guidance of an instructor, and having something real on Github to show for it, seems to be the difference.
This recipe worked out for all of them so far. Just being able to code “off script” without the guidance of an instructor, and having something real on Github to show for it, seems to be the difference.
What trouble are candidates looking for junior developer positions running into? Lack of openings? Lack of response from companies? Can't get past the interview?
(Also, are these people advertising themselves as a "junior developer"? Perhaps this is just my experience, but I don't think I ever used that; I started my search looking for simply "software engineer" positions.)
(One the one hand, one company I worked for doesn't seem to really have any junior developers, but we're also not hiring period AFAIK. Another company I worked for pretty much only hired interns, b/c hiring was otherwise tight and those were easy to get approval for. Not quite what I think the article means by "junior dev" (I interpret that to mean "entry level software engineer") They were generally very helpful, though I think we learned how much we needed to learn about being mentors.)
> Also their hand wringing about the costs seems like crocodile tears knowing all the time they waste (at least in my opinion) on things like meetings.
I echo this opinion.
(Also, are these people advertising themselves as a "junior developer"? Perhaps this is just my experience, but I don't think I ever used that; I started my search looking for simply "software engineer" positions.)
(One the one hand, one company I worked for doesn't seem to really have any junior developers, but we're also not hiring period AFAIK. Another company I worked for pretty much only hired interns, b/c hiring was otherwise tight and those were easy to get approval for. Not quite what I think the article means by "junior dev" (I interpret that to mean "entry level software engineer") They were generally very helpful, though I think we learned how much we needed to learn about being mentors.)
> Also their hand wringing about the costs seems like crocodile tears knowing all the time they waste (at least in my opinion) on things like meetings.
I echo this opinion.
Once you apply, it's usually - 'We're looking for someone with more experience right now' or 'Experience of 10 years with React'
If you even get a reply in the first place.
The article seems to be about the idea that nobody is seeking to hire junior developers.
>
But let’s say they do start sticking junior devs back into teams again. You have the additional issue which is now senior developers have no experience working with junior devs or training people at all. When I first started working with junior devs I had no idea how to do it. I felt lost and confused. My company was just like basically “give these people something to do so they can learn something.” But that’s really not a lot to go on.
I don't really agree with this. I've had to mentor people and there is not really a special trick. I just kind of pair program, and when we start I drive and eventually they drive and then once that's comfortable I leave them alone and leave them to ask me questions. I've found this mostly effective.
Explaining things to junior developers isn't so different from explaining things to anyone else. In the course of your job you probably have to explain concepts to your co-workers and to non-technical people, right? A junior is somewhere between those and you can calibrate as you go.
I don't really agree with this. I've had to mentor people and there is not really a special trick. I just kind of pair program, and when we start I drive and eventually they drive and then once that's comfortable I leave them alone and leave them to ask me questions. I've found this mostly effective.
Explaining things to junior developers isn't so different from explaining things to anyone else. In the course of your job you probably have to explain concepts to your co-workers and to non-technical people, right? A junior is somewhere between those and you can calibrate as you go.
> In the course of your job you probably have to explain concepts to your co-workers and to non-technical people, right?
I love how this is becoming the norm for engineers. I still run into engineers that seem to just code by themselves in a cave all day and the only human they communicate with is their (often non-technical) manager once every other month.
Communication is one of those skills that feels effortless if you're used to it, and like an nonstop anxiety attack if you're not.
I love how this is becoming the norm for engineers. I still run into engineers that seem to just code by themselves in a cave all day and the only human they communicate with is their (often non-technical) manager once every other month.
Communication is one of those skills that feels effortless if you're used to it, and like an nonstop anxiety attack if you're not.
1 or 2 "senior-level" folks (imho, people with at least a decade of experience within a multitude of environments) are going to outperform a half-dozen junior engineers.
When you're building a monolith Rails application, anything goes. But now that the industry is trending towards (for better or worse) service oriented architecture, stateless cloud deployments, walled gardens tossing data back and forth over RPC, data science teams, etc... you need people who have been to war a dozen times and have already made all the mistakes. That is what you get with a senior engineer: someone who knows what NOT to do.
I have spent most of the last 2-3 years of my career playing bad cop and telling people no. Shutting down wild and exciting ideas. Stopping over-engineering in its tracks. Preventing an investment in a bad technology. Preventing fragmented infrastructure with data in a handful of different databases.
I think that is why the junior engineer has disappeared. Most of us were never trained/educated/encouraged to be good teachers and we spend most of our time putting out fires and trying to keep our hands on the pulse of technology while simultaneously hanging on for dear life within our organizations. Pivots, layoffs, blockchains, shiny new business objectives are all mortars flying at the eng team left and right.
I wish I had junior engineers to mentor and teach and foster into folks who have good critical thinking skills and I can trust 100% to make the right decisions – but there is a tremendous cost involved to the business that I think most are unable to afford. Some of my most rewarding career experiences involved working side-by-side with folks fresh out of a bootcamp or university who were wide-eyed and bushy tailed. It was a lot of fun watching them run off and do a bunch of work then having a discussion on the choices and using each moment as a stepping stone towards a bigger understanding of all the moving parts in modern infrastructure.
When you're building a monolith Rails application, anything goes. But now that the industry is trending towards (for better or worse) service oriented architecture, stateless cloud deployments, walled gardens tossing data back and forth over RPC, data science teams, etc... you need people who have been to war a dozen times and have already made all the mistakes. That is what you get with a senior engineer: someone who knows what NOT to do.
I have spent most of the last 2-3 years of my career playing bad cop and telling people no. Shutting down wild and exciting ideas. Stopping over-engineering in its tracks. Preventing an investment in a bad technology. Preventing fragmented infrastructure with data in a handful of different databases.
I think that is why the junior engineer has disappeared. Most of us were never trained/educated/encouraged to be good teachers and we spend most of our time putting out fires and trying to keep our hands on the pulse of technology while simultaneously hanging on for dear life within our organizations. Pivots, layoffs, blockchains, shiny new business objectives are all mortars flying at the eng team left and right.
I wish I had junior engineers to mentor and teach and foster into folks who have good critical thinking skills and I can trust 100% to make the right decisions – but there is a tremendous cost involved to the business that I think most are unable to afford. Some of my most rewarding career experiences involved working side-by-side with folks fresh out of a bootcamp or university who were wide-eyed and bushy tailed. It was a lot of fun watching them run off and do a bunch of work then having a discussion on the choices and using each moment as a stepping stone towards a bigger understanding of all the moving parts in modern infrastructure.
Is this because people stay for just short timespans? We hire junior devs but we don’t expect much for the first years. I’m 15 years in and in a team of 30, the average is probably 10 years.
It takes a year to just “onboard” someone until they don’t need a lot of mentoring, but until a junior dev isn’t just a dangerous mess-creating junior dev, takes at least a couple of years more.
Learning the domain takes many years too, and without knowing the domain you need to be micromanaged and have everything specced up front or need constant interrupting feedback from product owners (should this be default on? What order should this be sorted? How many frobs will the typical user enter here? etc).
Obviously you can’t stop people from leaving but I wouldn’t even hire someone unless I genuinely believed they are going to stay 5 years.
(For context, this is heavy technical desktop software in a very mechanical engineering-heavy domain)
It takes a year to just “onboard” someone until they don’t need a lot of mentoring, but until a junior dev isn’t just a dangerous mess-creating junior dev, takes at least a couple of years more.
Learning the domain takes many years too, and without knowing the domain you need to be micromanaged and have everything specced up front or need constant interrupting feedback from product owners (should this be default on? What order should this be sorted? How many frobs will the typical user enter here? etc).
Obviously you can’t stop people from leaving but I wouldn’t even hire someone unless I genuinely believed they are going to stay 5 years.
(For context, this is heavy technical desktop software in a very mechanical engineering-heavy domain)
Junior-to-Senior developer ratios are critically important. If I hire too many juniors, then they will write a ton of shit code, and force whatever seniors I have to spend all their time mentoring and not producing.
Seniors are valued because they can write great code, think long-term solutions, take on a project and see all the details to completion, have a more predictable development cycle, and yes, train Juniors.
So my point is... if you graduate too many too fast, you'll end up with people who you can't train, and who also think that working for "the man" a.k.a. big companies is bad, so the perfect combination of limited use, expensive, and unwilling to work in places where they can experiment.
Seniors are valued because they can write great code, think long-term solutions, take on a project and see all the details to completion, have a more predictable development cycle, and yes, train Juniors.
So my point is... if you graduate too many too fast, you'll end up with people who you can't train, and who also think that working for "the man" a.k.a. big companies is bad, so the perfect combination of limited use, expensive, and unwilling to work in places where they can experiment.
As a near-Junior level developer myself sitting at two years of experience I've found myself wondering the same thing. I've put out my resume across the country and found few companies willing to look at it and even fewer positions. Most are looking for mid-tier to senior developers. Even worse I've kept in touch with friends who despite having far more internship experience than I ended up having quite a bit of difficulty find a job post-grad.
Though my current company has had large success in poaching interns into junior devs because we have a strong and genuine sense of teamwork + effective mentoring.
Though my current company has had large success in poaching interns into junior devs because we have a strong and genuine sense of teamwork + effective mentoring.
Two years experience? It’s 2018. You’re Senior now :)
I’m only mostly joking.
I’m only mostly joking.
Companies have woken up to the fact that for the most part people no longer stay in one job for more than a few years.
Training junior people makes sense economically only if they get up to speed and positive productivity within a small fraction of the time they'll be with your company.
Since a bad developer creates enormous negative productivity, it can be years before a new programmer's contributions are productive at all, let alone greater than the ongoing opportunity cost of the time spent mentoring them, let alone the sunk cost of months to years of mentorship.
This time makes sense only to invest if you expect the developer you trained to stay with you for many years. That expectation has become less and less rational over the past couple decades.
Nowadays if you take on and train a junior, you're taking the loss on that training - not to train someone who's going to be a good mid-level developer in your own company, but who's going to jump ship for somewhere else well before you can make back the senior developer time spent on them.
Training junior people makes sense economically only if they get up to speed and positive productivity within a small fraction of the time they'll be with your company.
Since a bad developer creates enormous negative productivity, it can be years before a new programmer's contributions are productive at all, let alone greater than the ongoing opportunity cost of the time spent mentoring them, let alone the sunk cost of months to years of mentorship.
This time makes sense only to invest if you expect the developer you trained to stay with you for many years. That expectation has become less and less rational over the past couple decades.
Nowadays if you take on and train a junior, you're taking the loss on that training - not to train someone who's going to be a good mid-level developer in your own company, but who's going to jump ship for somewhere else well before you can make back the senior developer time spent on them.
You shouldn't have this problem if you 1) hire for intelligence, drive, cooperation, and passion about the mission or opportunity, 2) give them continual opportunities to grow and take on increasing responsibility, and 3) compensate them appropriately (as a manager, privately reevalute title and comp every three months for the first year).
Of course, these are the same things (among others) that are true for every engineer.
There's an endless supply of juniors to choose from, so there's no excuse for a bad hire. If they leave for more money that you could have paid them, that's on you, too.
Do those things and you'll win their loyalty.
Of course, these are the same things (among others) that are true for every engineer.
There's an endless supply of juniors to choose from, so there's no excuse for a bad hire. If they leave for more money that you could have paid them, that's on you, too.
Do those things and you'll win their loyalty.
Is the junior job shortage just a valley bubble thing? I'm a young dev and there are grad/entry level positions everywhere I look, none of my peers have really had issues either.
How good (or bad) companies are at actually training their employees is another matter.
edit: typo
How good (or bad) companies are at actually training their employees is another matter.
edit: typo
Well, where are you based at?
Australia & haven't heard of junior shortages anywhere around the country, I would hazard a guess that this applies to most places that aren't this overinflated Mecca of programmers
That's weird, I'm in Sydney and last year I sent around more than 100 resumes over the span of 6 months, only to land an intern position in a terrible "startup like" company, where I was underpaid and overworked. I had to quit after burning out in a few months.
I know of several other juniors with this same issue.
100 applications with almost no luck sounds really bad but there is a possibility you are missing something in your resume. I work in Melbourne, if you want email me your resume and I will take a look to make sure you are not missing something basic.
Thanks for the offer, I appreciate it. I had my resume looked over at Reddit and by other industry professionals, it was just lacking working experience and qualifications (I graduated from TAFE, not uni). I'm not looking anymore, now, as I got a much better job, although not development related (which was, anyway, what I wanted, after burning out).
I trained a junior dev so well I was laid off because he was cheaper than me. One of the proudest moments of my professional life to be honest.
I've got a junior dev under me that has gotten so good that that the thought of that scenario has occurred to me.
I decided to come to terms with it by accepting that if that happened, it'd be the push I needed to spread my wings a bit.
I decided to come to terms with it by accepting that if that happened, it'd be the push I needed to spread my wings a bit.
Isn't this the goal of every programmer? Programming their way out of a job?
I've built a new of 4 developers team since September. 2 out of those devs are Juniors; or at least, formally they are, as this is their first "real", paid job.
But at the same time, these two are much better than many, many "senior" developers who came in asking for very competitive salaries and couldn't answer the most basic of questions. (My satndard is to ask about stack and heap; most of them just say something along the lines "value types on the stack, reference types of the heap" and cannot even connect stack the data structure with stack in memory.) Meanwhile, one of these "Juniors", when I asked him to talk about something he knew very well and was passionate about, explained AI techniques (game AI, not ML) that I never even dove into myself – instead of checking him, I was learning something new from an intervewee, and it doesn't happen often.
I really feel that I got the best deal, sitting through all these interviews regardless of experience and without any real filters by CV, because in the end I found these two - hard-working, talented and with more knowledge you would reasonably expect from a junior.
Don't save time on hiring. Don't create illusion of knowledge by reading too much from CV or using labels like "junior" and "senior". Rather, admit to yourself that you don't really know someone's skill level until you talk to them or give em the test assingment.
But at the same time, these two are much better than many, many "senior" developers who came in asking for very competitive salaries and couldn't answer the most basic of questions. (My satndard is to ask about stack and heap; most of them just say something along the lines "value types on the stack, reference types of the heap" and cannot even connect stack the data structure with stack in memory.) Meanwhile, one of these "Juniors", when I asked him to talk about something he knew very well and was passionate about, explained AI techniques (game AI, not ML) that I never even dove into myself – instead of checking him, I was learning something new from an intervewee, and it doesn't happen often.
I really feel that I got the best deal, sitting through all these interviews regardless of experience and without any real filters by CV, because in the end I found these two - hard-working, talented and with more knowledge you would reasonably expect from a junior.
Don't save time on hiring. Don't create illusion of knowledge by reading too much from CV or using labels like "junior" and "senior". Rather, admit to yourself that you don't really know someone's skill level until you talk to them or give em the test assingment.
>when I asked him to talk about something he knew very well and was passionate about, explained AI techniques (game AI, not ML) that I never even dove into myself
An aside, would you mind sharing what he shared with you, if you can recall?
An aside, would you mind sharing what he shared with you, if you can recall?
It's a symptom of normalized salary ranges for entry level positions, a saturated market, and massive range in the skillset of entry level developers.
There are two sets of juniors that I've come across. The first critically assesses a problem and it's edge cases, how to integrate the solution into the greater body of work, and considers performance. They might not know the stack of the company but they can be brought up to speed quickly by more experienced team members. The second is one that is incredibly proficient at the most cutting edge tools. They are hired because they are up to speed with what the company considers valuable at that moment. There is a much greater emphasis on getting shit done quickly rather than considering how it fits in later, how performant it is, or assessing how to integrate the solution in larger contexts.
I've found the first type to be much stronger teammates over an extended amount of time. They are also the ones that are able to command higher salaries when starting out because of the approach. The second type sees the salary numbers being set by the first and has an expectation that it is what they too are worth. Now you have two drastically different candidates competing for the same entry level positions, at the same rate. The first won't have an issue getting a job and the second will struggle.
Both can flourish in the right situations. We need to do a better job at distinguishing the two.
There are two sets of juniors that I've come across. The first critically assesses a problem and it's edge cases, how to integrate the solution into the greater body of work, and considers performance. They might not know the stack of the company but they can be brought up to speed quickly by more experienced team members. The second is one that is incredibly proficient at the most cutting edge tools. They are hired because they are up to speed with what the company considers valuable at that moment. There is a much greater emphasis on getting shit done quickly rather than considering how it fits in later, how performant it is, or assessing how to integrate the solution in larger contexts.
I've found the first type to be much stronger teammates over an extended amount of time. They are also the ones that are able to command higher salaries when starting out because of the approach. The second type sees the salary numbers being set by the first and has an expectation that it is what they too are worth. Now you have two drastically different candidates competing for the same entry level positions, at the same rate. The first won't have an issue getting a job and the second will struggle.
Both can flourish in the right situations. We need to do a better job at distinguishing the two.
Just few days ago some company's "Senior" developer posting made it to top of HN feeds. I clicked on it out of curiosity and the requirement was "2 years of experience writing code".
Such posts warrant a WARNING otherwise I may get permanent damage due to severe involuntary eye-roll.
Such posts warrant a WARNING otherwise I may get permanent damage due to severe involuntary eye-roll.
I feel really badly for junior developers today. I was both fortunately and unfortunately never a "Jr. Developer" as a professional.
By the time I got my first programming job right out of college in 1996, I had already been a hobby programmer for 10 years, had been very deep into assembly and C, and had been reading books like "Code Complete". My first job was writing a data entry system from scratch in C.
It was also unfortunate because I spent the first 12 years of my career working at 2 companies where I was either the only developer or one of only two or three and the other two had been at the same company from the beginning of their careers. So yeah, I was a good "developer" (I had the chance to look at some of my old code and it would have passed one of my modern code reviews), but I didn't start learning modern, proper "software engineering" until 2008 when I started job hopping and choosing companies where the goal was more to gain experience than make money. Although the money wasn't bad either.
Even back in 1993 while in college, I got my first programming side gig because another college saw a HyperCard stack I posted on AOL.
If I wanted to break the cycle of no experience <-> no job today, I would do a side project and post on github and link my resume to it. I have experience and a good resume but I'm thinking about posting side projects to GitHub just to get experience in technologies I don't get a chance to use at work.
By the time I got my first programming job right out of college in 1996, I had already been a hobby programmer for 10 years, had been very deep into assembly and C, and had been reading books like "Code Complete". My first job was writing a data entry system from scratch in C.
It was also unfortunate because I spent the first 12 years of my career working at 2 companies where I was either the only developer or one of only two or three and the other two had been at the same company from the beginning of their careers. So yeah, I was a good "developer" (I had the chance to look at some of my old code and it would have passed one of my modern code reviews), but I didn't start learning modern, proper "software engineering" until 2008 when I started job hopping and choosing companies where the goal was more to gain experience than make money. Although the money wasn't bad either.
Even back in 1993 while in college, I got my first programming side gig because another college saw a HyperCard stack I posted on AOL.
If I wanted to break the cycle of no experience <-> no job today, I would do a side project and post on github and link my resume to it. I have experience and a good resume but I'm thinking about posting side projects to GitHub just to get experience in technologies I don't get a chance to use at work.
I've found myself in a "mid-level" limbo. I have lots of knowledge and a fair amount of skill from a lifetime of programming, but I have trouble keeping what feels like an insane pace some others around me seem to manage. I was flat-out told that my output isn't what they expect from a "senior" developer.
Thing is, I never claimed that I was a "senior" developer, whatever that means. I just seem to have been slotted into that category based on years of experience. I didn't want to mislead an employer into thinking I was more capable than I actually was.
I went job searching and specifically said to recruiters and hiring managers that I was "mid-level" and would set my salary requests accordingly. If that meant I'm held to expectations somewhere between junior and senior, and get paid somewhere between junior and senior, that would be just fine.
I found that pretty much everyone was looking for senior devs, a few places advertised junior openings, and interest in mid-level seemed rarest of all.
It's like they think everyone is either a junior who needs to be mentored, or a senior who can deliver a story every day or two. I feel perfectly capable of doing the work, but need some time to think my way through it. I don't quite understand why I'm finding that to be such a hard sell in a job market where it's supposedly so hard to find developers.
Thing is, I never claimed that I was a "senior" developer, whatever that means. I just seem to have been slotted into that category based on years of experience. I didn't want to mislead an employer into thinking I was more capable than I actually was.
I went job searching and specifically said to recruiters and hiring managers that I was "mid-level" and would set my salary requests accordingly. If that meant I'm held to expectations somewhere between junior and senior, and get paid somewhere between junior and senior, that would be just fine.
I found that pretty much everyone was looking for senior devs, a few places advertised junior openings, and interest in mid-level seemed rarest of all.
It's like they think everyone is either a junior who needs to be mentored, or a senior who can deliver a story every day or two. I feel perfectly capable of doing the work, but need some time to think my way through it. I don't quite understand why I'm finding that to be such a hard sell in a job market where it's supposedly so hard to find developers.
What is a junior developer? Is a junior developer somebody without experience but with a good technical background. We hire those for sure.
But we dont hire people who dont have a solid basis, and just know a little bit of javascript programming.
For computer programming in a serious field, you need to know the basis to be good one, to solve real problems.
We actually dont use the name "Junior" developer. You're a software engineer or you're not. Junior developers are often names for people who can't program. We don't hire them.
But we dont hire people who dont have a solid basis, and just know a little bit of javascript programming.
For computer programming in a serious field, you need to know the basis to be good one, to solve real problems.
We actually dont use the name "Junior" developer. You're a software engineer or you're not. Junior developers are often names for people who can't program. We don't hire them.
You don't hire junior devs then.
I’m the cofounder of a YC-backed Computer Science academy (https://LambdaSchool.com/computer-science), and we’ve noticed a few things:
1. The junior dev market is flooded. It’s also flooded with people that cannot code. We’ve done quite a bit of analysis, and we’re talking 10% can write fizzbuzz.
Bootcamps are pumping people out as fast as they can collect money, and while some are solid juniors many are just completely lost. I’ve seen some code bootcamps with <10% placement, and their curriculum is 11 weeks of HTML and CSS and 1 week of jquery. Then they’re told to pound pavement for React roles. It’s worse than you think. Truly.
It’s also 95% of the same people who can’t code applying to every single job in existence. Remarkably many somehow get hired. Bootcamps as a whole have 100% earned their negative reputation. I can only imagine the learning curve encountered by some bootcamp grads.
As an aside, it’s not only bootcamps that pump out people that can’t code. Some CS programs are equally guilty, but probably not as many of them, and having four years to write code if you’re even a tiny bit self motivated is an enormous advantage. You give me a moderately intelligent person and I tell them to write code for four years and they’ll be hireable by the end for sure.
2. Many excellent companies, especially startups, have no appetite for junior developers whatsoever. Junior devs take a long time to integrate by definition, and rapidly moving companies don’t have the resources to care. It’s much, much easier to place juniors at mammoth companies that actually dedicate resources to training. A lot are just paying huge recruiter fees and bonuses to go after the people with experience.
3. Once you get even six months of experience the whole world opens up. I’ve never seen job security so quickly gained as a developer that has spent one year anywhere. Promotions come fast, offers come faster, and the big companies that actually are dedicated to investing in juniors see them poached for $30-50k extra by companies that don’t.
4. People that can still code absolutely do get hired, and quickly. We are dangerously close to 75% of the class that graduated 3 weeks ago being hired or contracted.
All that said, we take it for granted that we’re in an industry where people go from cold start to 6 figure salaries in 3-6 months. I’ve not aware of that ever having happened in the history of the world. It’s no longer write a couple lines of code and raise your hand for a job like it used to be, but software development is still an incredible industry to be in, and with a couple of years of experience you’ll reliably be complaining about salaries and working situations that almost any other industry would kill for.
1. The junior dev market is flooded. It’s also flooded with people that cannot code. We’ve done quite a bit of analysis, and we’re talking 10% can write fizzbuzz.
Bootcamps are pumping people out as fast as they can collect money, and while some are solid juniors many are just completely lost. I’ve seen some code bootcamps with <10% placement, and their curriculum is 11 weeks of HTML and CSS and 1 week of jquery. Then they’re told to pound pavement for React roles. It’s worse than you think. Truly.
It’s also 95% of the same people who can’t code applying to every single job in existence. Remarkably many somehow get hired. Bootcamps as a whole have 100% earned their negative reputation. I can only imagine the learning curve encountered by some bootcamp grads.
As an aside, it’s not only bootcamps that pump out people that can’t code. Some CS programs are equally guilty, but probably not as many of them, and having four years to write code if you’re even a tiny bit self motivated is an enormous advantage. You give me a moderately intelligent person and I tell them to write code for four years and they’ll be hireable by the end for sure.
2. Many excellent companies, especially startups, have no appetite for junior developers whatsoever. Junior devs take a long time to integrate by definition, and rapidly moving companies don’t have the resources to care. It’s much, much easier to place juniors at mammoth companies that actually dedicate resources to training. A lot are just paying huge recruiter fees and bonuses to go after the people with experience.
3. Once you get even six months of experience the whole world opens up. I’ve never seen job security so quickly gained as a developer that has spent one year anywhere. Promotions come fast, offers come faster, and the big companies that actually are dedicated to investing in juniors see them poached for $30-50k extra by companies that don’t.
4. People that can still code absolutely do get hired, and quickly. We are dangerously close to 75% of the class that graduated 3 weeks ago being hired or contracted.
All that said, we take it for granted that we’re in an industry where people go from cold start to 6 figure salaries in 3-6 months. I’ve not aware of that ever having happened in the history of the world. It’s no longer write a couple lines of code and raise your hand for a job like it used to be, but software development is still an incredible industry to be in, and with a couple of years of experience you’ll reliably be complaining about salaries and working situations that almost any other industry would kill for.
> All that said, we take it for granted that we’re in an industry where people go from cold start to 6 figure salaries in 3-6 months. I’ve not aware of that ever having happened in the history of the world.
There have been plenty of trained or semi-trained labour shortages in the history of the world, with similar results.
There have been plenty of trained or semi-trained labour shortages in the history of the world, with similar results.
Not sure any have been at this scale and lasted for this long.
There's multiple examples of this. Looking at Detroit's boom during post-war decade of American cars. In a bigger flash of the pan examples like the North Dakota oil fields. Where unskilled labor was in extreme demand to have 18 year olds making 6 figures.
This will always happen as long as the profits are there to sustain it. But I agree with your general sentiment, having said that, its just part of the human condition. When I attend a bitcoin/ethereum meetup most of the people there are only there for the lure of the quick buck. Not the long term technical implications/learn about the projects.
This will always happen as long as the profits are there to sustain it. But I agree with your general sentiment, having said that, its just part of the human condition. When I attend a bitcoin/ethereum meetup most of the people there are only there for the lure of the quick buck. Not the long term technical implications/learn about the projects.
What bootcamps are teaching their students HTML/CSS for 11 weeks? You should call them out by name.
What I get from your post is that in less than 10 years, people that get such a short training will be good regardless. Maybe then good programmers will become a commodity: this will surely change a thing or two.
I think that would be true if the demand for programmers weren’t also increasing exponentially
This all rings very true to me.
I like the premise of the article. I think bean counting, short sighted companies killed the junior dev....and that role died a long time ago in many places (even farther back than 2010).
I also think the article needs some copy editing. A few paragraphs were rough to get through.
I also think the article needs some copy editing. A few paragraphs were rough to get through.
My undergrad degree was in music and when I decided to move into software development, I got into a master's CS program that was heavy on theory, light on practicalities. I graduated quite green and unconfident with basic tools/systems like vi or Unix. Hell, I could barely type.
Once out of school, I opted to take a software test development (SDET) position, which provided the sort of hands on training and practical exposure I needed at the time. And, while technically it was a "QE position," the role did provide opportunities for coding in the form of automated tests, deployment scripts, test frameworks, etc...
Although I ended up staying in QA longer than I desired -- the bursting of the web bubble in 2000 sort of pulled the rug out from under me -- I eventually laterally shifted into a dev role and have been quite happy ever since.
I think this sort of path is still a viable option for aspiring Jr. devs, especially given our increasingly complex ecosystems/stacks. It's a great way to learn, and these days there seems to be less clean separation between QE/Dev roles in any event. QE people write code, devs write tests (or rather, they should ;)). (Note, I'm explicitly recommending an SDET role, not a manual testing role.)
Once out of school, I opted to take a software test development (SDET) position, which provided the sort of hands on training and practical exposure I needed at the time. And, while technically it was a "QE position," the role did provide opportunities for coding in the form of automated tests, deployment scripts, test frameworks, etc...
Although I ended up staying in QA longer than I desired -- the bursting of the web bubble in 2000 sort of pulled the rug out from under me -- I eventually laterally shifted into a dev role and have been quite happy ever since.
I think this sort of path is still a viable option for aspiring Jr. devs, especially given our increasingly complex ecosystems/stacks. It's a great way to learn, and these days there seems to be less clean separation between QE/Dev roles in any event. QE people write code, devs write tests (or rather, they should ;)). (Note, I'm explicitly recommending an SDET role, not a manual testing role.)
> Who Killed the Junior Developer?
The educational system.
I've seen horrible things happening to production code due to junior developers. In the end the senior/lead needs to spend way more time fixing all bad code/ideas than if he'd write it himself in the first place. I know a company that has a medior dev that is now already more than 2 months working on a feature I can write in just 2 weeks. Besides that, my code will likely still be better because I code with experience, using proven strategies, making it more scalable, preventing pitfalls, potential bugs, etc..
I don't think the companies are to blame. A junior dev should not write rubbish if he/she is a software developer graduate. Current IT education is very limited. Most of the things you learn in 5 years can be interesting and a good foundation, but not really relevant for most developer jobs out there. You actually have to start learning to code once done with your study. And learning to code is not a short journey, I guess at least some 3 years of full time study before you'll get the hang of it. And I didn't even touch the idea that you definitely need some talent or feel for it. You can study arts, but that alone won't make you an artist.
The educational system.
I've seen horrible things happening to production code due to junior developers. In the end the senior/lead needs to spend way more time fixing all bad code/ideas than if he'd write it himself in the first place. I know a company that has a medior dev that is now already more than 2 months working on a feature I can write in just 2 weeks. Besides that, my code will likely still be better because I code with experience, using proven strategies, making it more scalable, preventing pitfalls, potential bugs, etc..
I don't think the companies are to blame. A junior dev should not write rubbish if he/she is a software developer graduate. Current IT education is very limited. Most of the things you learn in 5 years can be interesting and a good foundation, but not really relevant for most developer jobs out there. You actually have to start learning to code once done with your study. And learning to code is not a short journey, I guess at least some 3 years of full time study before you'll get the hang of it. And I didn't even touch the idea that you definitely need some talent or feel for it. You can study arts, but that alone won't make you an artist.
The ideal hiring process imo is actually a training process that is less focused on 'finding the best' but rather focused on helping their local community become good engineers. Companies fund their own bootcamps and pay students $15/hr (with no engineering experience). Students learn and help each other how to code (following a structured curriculum) with mentorship by engineers from the company. When students have finished the basics, they work on open source projects or internal projects following proper engineering process / tools that the company use. When a student has proved that he/she learned how to work well with other engineers and has built a few features, they get hired by the company as an engineer and this engineer would be immediately productive.
This might seem like a crazy idea, but its actually not. The previous companies that I have worked for all offer paid volunteer hours which could go directly to this initiative. The cost of hiring is around 30k per engineer (conservatively), which could help train someone living paycheck to paycheck for an entire year.
This non-profit does this: https://garagescript.org
This might seem like a crazy idea, but its actually not. The previous companies that I have worked for all offer paid volunteer hours which could go directly to this initiative. The cost of hiring is around 30k per engineer (conservatively), which could help train someone living paycheck to paycheck for an entire year.
This non-profit does this: https://garagescript.org
What I run into over and over are largely attitude issues in all parties involved.
"Junior" is not an insult nor does it / should it demand an insulting salary level. I don't look at someone's title and think "they must be bad" or "I am better than them" etc etc but I see that attitude a lot. I see seniors take interesting work for themselves, I see them shove off juniors and I see juniors complain about the work they have to do.
And even worse is when someone holds the explicit junior title they are only interested in getting the senior title. Then we have seniors that shouldn't have that in their title feeling threatened by who does and doesn't have / get sr added to their title. It's all a dreadful game and I'm tired of playing it.
As others have said- I enjoy mentoring. I'm not ashamed that I enjoy someone taking the time to listen to me and what I have to say. I have 13 years of mistakes I can share. I don't enjoy working with people that are only interested in the "title game" and that complain about the types of work they have to do. We're all paid very well to do the type of work we do and ultimately we're paid to do what the company asks of us. We don't have to believe it's the grandest technical challenge of all time yet I see Jrs complain they aren't given the "big work" without realizing they don't know what they don't know- they just see some sort of prestige associated with it.
And shame on the seniors for taking work that is interesting to others first and shame on management for not making time for a junior to tackle a bigger task. I do feel for Jr engineers that get stuck in the cycle of doing menial tasks because no one makes time for them to make mistakes.
If you've got Sr in your title did you get it by being hired in to the title or by earning it in some fashion? Did you earn it by being a workaholic? Did you earn it by putting in time with the same organization? Did you earn it by growing your responsibilities? Ultimately- who helped you do it? Who gave you the chances and which manager wasn't threatened by you and allowed you to be promoted? Try to imitate those values and lead by example. Sadly I see a lot of insecure engineers who don't want to help and would never stand for a coworker, not the least someone they helped mentor, surpass them. And it IS a shame.
"Junior" is not an insult nor does it / should it demand an insulting salary level. I don't look at someone's title and think "they must be bad" or "I am better than them" etc etc but I see that attitude a lot. I see seniors take interesting work for themselves, I see them shove off juniors and I see juniors complain about the work they have to do.
And even worse is when someone holds the explicit junior title they are only interested in getting the senior title. Then we have seniors that shouldn't have that in their title feeling threatened by who does and doesn't have / get sr added to their title. It's all a dreadful game and I'm tired of playing it.
As others have said- I enjoy mentoring. I'm not ashamed that I enjoy someone taking the time to listen to me and what I have to say. I have 13 years of mistakes I can share. I don't enjoy working with people that are only interested in the "title game" and that complain about the types of work they have to do. We're all paid very well to do the type of work we do and ultimately we're paid to do what the company asks of us. We don't have to believe it's the grandest technical challenge of all time yet I see Jrs complain they aren't given the "big work" without realizing they don't know what they don't know- they just see some sort of prestige associated with it.
And shame on the seniors for taking work that is interesting to others first and shame on management for not making time for a junior to tackle a bigger task. I do feel for Jr engineers that get stuck in the cycle of doing menial tasks because no one makes time for them to make mistakes.
If you've got Sr in your title did you get it by being hired in to the title or by earning it in some fashion? Did you earn it by being a workaholic? Did you earn it by putting in time with the same organization? Did you earn it by growing your responsibilities? Ultimately- who helped you do it? Who gave you the chances and which manager wasn't threatened by you and allowed you to be promoted? Try to imitate those values and lead by example. Sadly I see a lot of insecure engineers who don't want to help and would never stand for a coworker, not the least someone they helped mentor, surpass them. And it IS a shame.
Most IT companies have not succeeded in having a technical growth path. So the 'new' acceptance is that technical people will just be with the company for a short time before moving on unless they 'mature' into management. With that comes the expectation that employees need to be productive from day 1. So there will be no 'investment' in training or mentoring.
To quote Feynman...
When I was at Princeton in the 1940s I could see what happened to those great minds at the Institute for Advanced Study, who had been specially selected for their tremendous brains and were now given this opportunity to sit in this lovely house by the woods there, with no classes to teach, with no obligations whatsoever. These poor bastards could now sit and think clearly all by themselves, OK? So they don't get an idea for a while: They have every opportunity to do something, and they're not getting any ideas. I believe that in a situation like this a kind of guilt or depression worms inside of you, and you begin to worry about not getting any ideas. And nothing happens. Still no ideas come.
Nothing happens because there's not enough real activity and challenge: You're not in contact with the experimental guys. You don't have to think how to answer questions from the students. Nothing!Got a side question.. how do I tell my junior developer who's still junior that he's not ready for being promoted. He feels he is because he understands more of the code base now, he often makes a lot of mistakes and is ready to point out the mistakes of others. He also does not get off his desk to communicate or question requirements.
Find or create a skills matrix for developer seniority. There are a few floating around out there if you Google.
Along the same lines, decide what the bar will be for promotion, tell them where they're lacking, and when they reach that bar, promote them.
Thanks
The roles that mentees would have been have largely been outsourced/offshored. The days of spotting a talented helpdesk or QA worker and growing them into a fully fledged sysadmin or developer are gone. Some of the finest engineers I know came into the field that way 20 years ago. They wouldn’t get a look in now.
The word ’Junior’ killed the Junior Developer. Nobody wanted to have that title and it was also an easy target for recruiters to hire them away promising software developer roles.
In many of the companies I worked for in the past, the word "senior" was also seen as an alternative to a pay raise.
One telco I worked for opted to change the title from developer to senior developer for five people in one year, this is on a 15 person team, where 4 people where already senior developers. The title change was seen as an alternative to a pay raise, equal in value.
Personally I don't care about titles and I prefer to just have the title of developer, and no "junior" or "senior" prefix. It's not helpful anyway, you just use the salary to compensate for the difference in skill levels.
One telco I worked for opted to change the title from developer to senior developer for five people in one year, this is on a 15 person team, where 4 people where already senior developers. The title change was seen as an alternative to a pay raise, equal in value.
Personally I don't care about titles and I prefer to just have the title of developer, and no "junior" or "senior" prefix. It's not helpful anyway, you just use the salary to compensate for the difference in skill levels.
Related: "Senior" developers with two years of experience.
There's just a hell of a lot of title inflation in general, I think.
There's just a hell of a lot of title inflation in general, I think.
Its a large mix of problems. There is infinitely more demand for the top ~20% of developers then the bottom ~80%. There is a glut of new undergrads and transitioning professionals. There is a larger-then-other-industries capital expenditure in hiring, training, and managing, developers - which compounds the hiring difficulties of most small companies including almost every start-up. Oh and there's massive conglomerates with near infinite resources (Google, AMZ, FB, MS) hoarding top tier talent - which plays into developer validation of who the top 20% is.
It's a mess, and it paints a single reality. The tech industry isn't as easy to break into as pop culture has labeled it over the past decade, and in my view it won't be getting any easier... sorry to the younger generation paying big $$$ for a CS degree.
It's a mess, and it paints a single reality. The tech industry isn't as easy to break into as pop culture has labeled it over the past decade, and in my view it won't be getting any easier... sorry to the younger generation paying big $$$ for a CS degree.
Well, sure, but I think this is one of the few industries left where someone with the talent can not have any credentials and just be able to do the job. I've never sat in a computer science class in my life (which is not to say I've never learned anything about the subject). It's not easy but it's not outlandish, like it would be in many other similar fields.
> paying big $$$ for a CS degree
This isn't law...even the cheap universities offer CS degrees.
This isn't law...even the cheap universities offer CS degrees.
Is this a small company vs large company thing?
We hire interns and recent graduates most years. I've had 2 interns/summer for as long as I've been in a leadership role. The majority of my team was hired straight out of college. My employer is a well-established software company (35+ years, 400+ employees, R&D offices in 4+ countries).
We also have a robust on-boarding program for college graduates. So, we can deliver all that early training once with willing SMEs instead of many times. Yes, it costs money (travel/housing for remote new hires, travel/expenses for remote L&D staff, catering, extra-curricular events, etc). That doesn't completely alleviate the mentoring load, but it seems to work well. Plus, the new hires make friends quickly and rely on each other more than they might otherwise.
We hire interns and recent graduates most years. I've had 2 interns/summer for as long as I've been in a leadership role. The majority of my team was hired straight out of college. My employer is a well-established software company (35+ years, 400+ employees, R&D offices in 4+ countries).
We also have a robust on-boarding program for college graduates. So, we can deliver all that early training once with willing SMEs instead of many times. Yes, it costs money (travel/housing for remote new hires, travel/expenses for remote L&D staff, catering, extra-curricular events, etc). That doesn't completely alleviate the mentoring load, but it seems to work well. Plus, the new hires make friends quickly and rely on each other more than they might otherwise.
Having recently had to do a lot of hiring and also played too much FIFA, I couldn't help but wonder if a argument couldn't be made for software engineering job contacts to work more like soccer player contracts. One issue is you might hire a junior dev, train them and just when they start to provide value BigCorp makes them an offer they can't refuse and you are left with the bill. If on the other hand the was a contract where a new employer had to pay some amount of money to the previous employer that might help with the situation. Hiring a upcoming super star and coaching them might turn from a risk into a business model in itself. Of course there are lots of potential issues that would need to get figured out, but at least for junior devs this might be a net win.
That is pretty ripe for abuse - junior developers take whatever since the first job is critically important to get, and then have zero negotiation power since it costs an exorbitant amount of money to "poach" them and pay them their fair market value.
I mean, yeah, it'd be good for employers. Not so much for employees. Likely an illegal or unenforceable contract, too.
I mean, yeah, it'd be good for employers. Not so much for employees. Likely an illegal or unenforceable contract, too.
Why would it be illegal or unenforceable for software development but legal and enforceable for sports?
I thought about this idea too, but in practice, this should be what equity/options is designed for. So, a promising developer at small company A gets a lower salary, but greater share of equity that he/she has to forgo if they leave the company before they can vest their options.
But in reality, the amount of equity offered by most startups to junior developers is negligible, and is too low to form any sort of incentive to stay. Perhaps offering them a clear contract with lock in would make things more clear, but enforcing (no moonlighting) might be illegal in some states/countries.
PS. if you ever end up playing PES on the PS4, give me a shout!
But in reality, the amount of equity offered by most startups to junior developers is negligible, and is too low to form any sort of incentive to stay. Perhaps offering them a clear contract with lock in would make things more clear, but enforcing (no moonlighting) might be illegal in some states/countries.
PS. if you ever end up playing PES on the PS4, give me a shout!
Do people really think this is a problem? I feel like everyone is taking the article at face value instead of reading between the lines: people don't want to hire bootcamp grads.
Developers fresh out of college with a BA in computer science have no problem getting a job.
Developers fresh out of college with a BA in computer science have no problem getting a job.
I had a similar reaction. Boot camp hires haven’t worked out very well when I’ve hired them in the past — even allocating a lot of mentoring time. I don’t care about degrees of big time jobs, but in my experience it takes several years of being a curious coder hacking on learning projects before you reach a level where I can give you work to do.
There are plenty of people who fit that bill, but we can only handle a ratio of 20-30% junior or we can’t really give them the support they need to grow, otherwise we’d hire more.
There are plenty of people who fit that bill, but we can only handle a ratio of 20-30% junior or we can’t really give them the support they need to grow, otherwise we’d hire more.
Really? The "killing" of the junior developer seems like an anecdotal claim. Hasn't ageism been a concern here on HN? Doesn't that tend to suggest that older, and thus more senior developers are "discriminated against" in favor of younger, CHEAPER labor? The reasons being that either:
- you don't need a senior developer for your needs
- you can't fork out for a senior developer
- you could really use a senior developer, but won't fork out for a senior developer because your penny wise and pound foolish
- you don't understand the difference between a junior and a senior developer
- there is a labor shortage in software development and all you can hire are junior developers
- you don't need a senior developer for your needs
- you can't fork out for a senior developer
- you could really use a senior developer, but won't fork out for a senior developer because your penny wise and pound foolish
- you don't understand the difference between a junior and a senior developer
- there is a labor shortage in software development and all you can hire are junior developers
>- you don't understand the difference between a junior and a senior developer
I think it is this. The title Sr Engineer is handed out constantly to people with little to no experience. You are basically Junior for a year then you get the title change. It is a bit absurd.
So yes, there is a shortage of Jr engineers... but there are plenty of not very good Sr Engineers who should be Jr Engineers.
I think it is this. The title Sr Engineer is handed out constantly to people with little to no experience. You are basically Junior for a year then you get the title change. It is a bit absurd.
So yes, there is a shortage of Jr engineers... but there are plenty of not very good Sr Engineers who should be Jr Engineers.
You're absolutely correct on this point. My first job after obtaining my CS degree was "Senior Developer" even though I had never developed software professionally before. I got the Senior title because the company had their pay buckets tied to titles so in order for the company to bring me on at the rate I requested, they gave me the Senior title. Titles apparently are nonsense, at least from what I've seen.
We kinda did. This is because we like to hire interns.
Usually intern in our area:
* studies programming at a university
* costs around a 1/2 of a junior
* is part-time with really erratic schedule
* work output still on on par with few juniors we hired
I suspect this is mostly because there isn't as much of a difference between what can one work in 8h compared to 4h (I spend 2h out of those on meetings an email anyway, so it can be productive to route most of these around your intern)
Second part is, we are well known as a good employer in the area, that has a tradition in accommodating for students erratic schedules, which means we get students who would get a full time non-junior position elsewhere, but they don't want to give up on school.
Usually intern in our area:
* studies programming at a university
* costs around a 1/2 of a junior
* is part-time with really erratic schedule
* work output still on on par with few juniors we hired
I suspect this is mostly because there isn't as much of a difference between what can one work in 8h compared to 4h (I spend 2h out of those on meetings an email anyway, so it can be productive to route most of these around your intern)
Second part is, we are well known as a good employer in the area, that has a tradition in accommodating for students erratic schedules, which means we get students who would get a full time non-junior position elsewhere, but they don't want to give up on school.
> I suspect this is mostly because there isn't as much of a difference between what can one work in 8h compared to 4h
This is so true. I don't really understand why 8h workdays are the standard for "creative" jobs. Most people can't fully focus for that long. Tbh I personally just spread out 3-4 hours of proper work time to just fill the 8 hours. Otherwise I'd just run out of power / focus in the early afternoon.
This is so true. I don't really understand why 8h workdays are the standard for "creative" jobs. Most people can't fully focus for that long. Tbh I personally just spread out 3-4 hours of proper work time to just fill the 8 hours. Otherwise I'd just run out of power / focus in the early afternoon.
In my case, I work 8 hours because I still get pay by hour :)
If, one day I would manage to get into consulting, I probably would work less on average work-day.
I mostly disagree with this article, but not entirely. I do think there's a trend by the bigger companies to look for senior talent, but there are plenty of firms that rely on one or two senior devs with a team of junior/mid-level devs and I'd say most smaller companies still hire and train junior developers. I'm in the Chicago area and it's possibly unique in its diverse market of employers and thus able to support all manner of dev team make-up.
I'd also say that many junior devs are offshore and are given test and support tasks, and this is especially true in larger corporations.
I'd also say that many junior devs are offshore and are given test and support tasks, and this is especially true in larger corporations.
It was the Middle Manager, in the Small Conference Room, with the PowerPoint.
Did I win? <opponent reveals a card> Nope.~
"Junior" implies training, and American companies don't do training. If you're lucky, they have an internship program, which is apparently enough experience to get you a 6-month contract-to-hire as a "regular" developer.
It's a name game. "Developer" is actually "Junior Developer", "Senior Developer" is actually "Developer", and "Lead Developer" or "Principal Developer" is really "Senior Developer".
Did I win? <opponent reveals a card> Nope.~
"Junior" implies training, and American companies don't do training. If you're lucky, they have an internship program, which is apparently enough experience to get you a 6-month contract-to-hire as a "regular" developer.
It's a name game. "Developer" is actually "Junior Developer", "Senior Developer" is actually "Developer", and "Lead Developer" or "Principal Developer" is really "Senior Developer".
> My company was just like basically “give these people something to do so they can learn something.” But that’s really not a lot to go on.
That really is how it works though. You need to start doing before you can learn.
That really is how it works though. You need to start doing before you can learn.
> Who Killed the Junior Developer?
Those who thought it a good idea to promote people to senior level after 6 months or a year.
Those who thought it a good idea to promote people to senior level after 6 months or a year.
It's funny, my experience is completely different. I've always loved to hire juniors because you can mentor and they usually come with less preconceptions.
That makes discussions much more fruitful. And they usually make you think about your decisions much more, because they can challenge things that any engineer with experience with just take for granted or accepted.
The learning curve can be an issue though. You want to be constantly be welcoming newcomers to have a rolling scheme of new 'seniors'.
The learning curve can be an issue though. You want to be constantly be welcoming newcomers to have a rolling scheme of new 'seniors'.
I recently put together a dev team from scratch. I specced it out as: One Senior Dev, one Project Manager, one Team Leader (an existing employee experienced in the company politics and able to manage), one Ops/Infrastructure role, and one Designer.
Needless to say it didn't quite work out like that. We ended up with two junior devs, one developer, one project manager, the ops guy, and the team leader. One of the people we interviewed for a Junior Dev role was actually pretty experienced (not enough for the Senior role though). Two of the devs could design well enough to be able to do the UI work. We're still looking for a Senior Developer. The team will need to learn as they go, but I'm able to cover for them enough so they can make mistakes (ahhh, the pleasure of being a CEO with a techie background).
I hope to continue bringing on new Junior Devs as the team grows and learns. Creating a pipeline of talent is essential to finding the best people. Because the best people aren't found randomly, they're trained and coached, built up to be the people that the team needs.
It's all about long-term planning rather than short-term thinking. I'm pretty sure that in about six months this team will be doing all the things we need it to, and in about 18 months we'll have lost (at most) one of them and the team will be exceptional.
Needless to say it didn't quite work out like that. We ended up with two junior devs, one developer, one project manager, the ops guy, and the team leader. One of the people we interviewed for a Junior Dev role was actually pretty experienced (not enough for the Senior role though). Two of the devs could design well enough to be able to do the UI work. We're still looking for a Senior Developer. The team will need to learn as they go, but I'm able to cover for them enough so they can make mistakes (ahhh, the pleasure of being a CEO with a techie background).
I hope to continue bringing on new Junior Devs as the team grows and learns. Creating a pipeline of talent is essential to finding the best people. Because the best people aren't found randomly, they're trained and coached, built up to be the people that the team needs.
It's all about long-term planning rather than short-term thinking. I'm pretty sure that in about six months this team will be doing all the things we need it to, and in about 18 months we'll have lost (at most) one of them and the team will be exceptional.
Personal story time...
I was a journeyman electrician for nearly a decade before obtaining my CS degree. The company that hired me, in order to pay me what I was making as a topped-out journeyman, brought me in as a Senior Developer (and its corresponding pay "bucket"). This was my first job actually developing software and I was, in title, a "Senior Developer," even though I knew next to nothing other than what was covered in my college curriculum.
TLDR: Titles don't mean much...
I was a journeyman electrician for nearly a decade before obtaining my CS degree. The company that hired me, in order to pay me what I was making as a topped-out journeyman, brought me in as a Senior Developer (and its corresponding pay "bucket"). This was my first job actually developing software and I was, in title, a "Senior Developer," even though I knew next to nothing other than what was covered in my college curriculum.
TLDR: Titles don't mean much...
Minimum wage killed the junior developer. I love mentoring and teaching, and I do this as part of my current role, and would gladly take on more people and train them and in 6 months they will be capable of going out and getting a 100k salary - I would have an open offer for anyone who feels like taking me up on this opportunity if I could, but that would be illegal. Much better we get people to spend 50k on a piece of paper /s.
My title for my first programming job, circa 1992-3, was Junior Programmer. I was sent for two weeks of Oracle training on my first day. We didn't have a formal mentoring program, but the team was small and everyone was open to helping me anytime I needed it.
My recollection is that "Junior" positions phased out along with training programs as companies demanded pre-trained people. It seems like companies have basically shifted all the cost of training to the individual. This is having an effect on college computer science programs as students and their parents demand programs more catered to industrial needs. (The paradox is that industrial needs change before a student can actually graduate.)
Personally, I would love to work with Juniors and mentor them. In the absence of Juniors, I suggested that I do "lunch and learns" with our Help Desk people so they can be more than just ticket routers: maybe act as analysts before tickets get to senior people like me. As of yet, my manager and the Help Desk manager haven't approved. So, we keep riding the carousel of status quo.
My recollection is that "Junior" positions phased out along with training programs as companies demanded pre-trained people. It seems like companies have basically shifted all the cost of training to the individual. This is having an effect on college computer science programs as students and their parents demand programs more catered to industrial needs. (The paradox is that industrial needs change before a student can actually graduate.)
Personally, I would love to work with Juniors and mentor them. In the absence of Juniors, I suggested that I do "lunch and learns" with our Help Desk people so they can be more than just ticket routers: maybe act as analysts before tickets get to senior people like me. As of yet, my manager and the Help Desk manager haven't approved. So, we keep riding the carousel of status quo.
Isn't the problem the high turnover rate in the industry? Why invest in educating someone if they are going to quit in one year or so?
What I've seen (and frankly even what I experienced in my own career) is that really junior people are grateful to the company that gave them their first opportunity and also (to a degree that might even be called naive) invested in what their companies do, and for that reason tend to stay at companies a long time compared to more senior people.
More ops than dev, though still have to do both, but this has been the case with me as well. I have been open to staying at a company longer given they are willing to pay a reasonable salary and have the right type and amount of work. No point in switching every year if you're somewhere decent.
'Why invest in educating someone if they are going to quit in one year or so?'
'What happens if you don't invest in them, and they decide to stay?' - Quote from a management guru, can't remember his/her name
'What happens if you don't invest in them, and they decide to stay?' - Quote from a management guru, can't remember his/her name
But what if the company's plan is to exit or bust in a few years? There's not much of a future for them either way..
You know you are living interesting times when companies bust on purpose !!!
It's a bit of a chicken or the egg problem. Why stay at a company that doesn't invest in you?
Most developers doing the one year stint thing don't care about anything other than salary. No matter what you do for them they will jump after a year. Seeing that pattern on a resume a big warning sign. These people are simply mercenary and deserve to be treated as such.
Maybe, but how many times do people sign on at positions that either weren't at all what was pitched or else have changed so much as to be completely unrecognizable in a few years after the company changes hands and turns everyone over a few times?
Most companies seem to think that a good years raise is just a cost of living increase. If one side acted better I could see getting all high and mighty about it, but that's not the case. When companies decided to cut all loyalty to employees they shouldn't be surprised when the feeling is reciprocated
This. Loyalty is a two-way street. Seeing a series of one-year terms on a resume means that the candidate is probably mercenary now, but it also means that none of those previous companies invested anything into retention or morale. They could probably be converted back to a company stalwart if only someone would treat them right.
On my resume, the "at-will" terminations outnumber the number of times I jumped ship for a better situation, 5 to 1. This last year's raise was just a cost of living increase, and they crappified the health benefits, so I may have to even those numbers up a bit soon. The only thing stopping me is the horrid, nauseating, bile-raising gauntlet of developer interviews.
On my resume, the "at-will" terminations outnumber the number of times I jumped ship for a better situation, 5 to 1. This last year's raise was just a cost of living increase, and they crappified the health benefits, so I may have to even those numbers up a bit soon. The only thing stopping me is the horrid, nauseating, bile-raising gauntlet of developer interviews.
The problem is that devs can get much larger salary increases by jumping to a new company rather than staying put. The solution to this problem is to reward them for their performance and increased usefulness, especially in their first few years.
It should just be budgeted in as part of their total cost
The demand for developers is such that no company can ignore hiring and training junior developers.
IMO companies have relabeled them to developer and even to senior developers, presumably to make hires feel better that they joined exclusive group of people.
This may also be a result of some tension in HR departments where they are expected to provide some number of headcounts on different levels but they can't. So there may be natural inclination to prop up the hires to meet plans.
The body leasing companies are also inclined to prop up their candidates to offer them for higher rates.
Some regions of the world (my experience is with India) don't seem to have any junior developers. As soon as they are done with their training they have gained enough experience to be marketed as developers.
I work for one of very large companies in financial sector and people who barely can write a loop in Java are still named senior developers.
All this depreciates value of the official recognition of seniority and forces people to discover this on their own.
IMO companies have relabeled them to developer and even to senior developers, presumably to make hires feel better that they joined exclusive group of people.
This may also be a result of some tension in HR departments where they are expected to provide some number of headcounts on different levels but they can't. So there may be natural inclination to prop up the hires to meet plans.
The body leasing companies are also inclined to prop up their candidates to offer them for higher rates.
Some regions of the world (my experience is with India) don't seem to have any junior developers. As soon as they are done with their training they have gained enough experience to be marketed as developers.
I work for one of very large companies in financial sector and people who barely can write a loop in Java are still named senior developers.
All this depreciates value of the official recognition of seniority and forces people to discover this on their own.
I have seen the "we don't want to waste time teaching people. So, hire only senior developers" scenario play out at couple of my previous employers. And, it doesn't end well.
Senior devs have expectations around salary, growth and work. Over time when the company starts running out of steam - funding, growth or even interesting work it gets difficult to keep the senior devs happy.
Once that scenario plays out, companies start scrambling to find interns or junior devs and find out, not many are not interested in working for them because they heard "rumors" about company's hard-ass culture on "not learning on the job".
Slowly, company realize that a team made of only senior devs is too costly for the value they provide. And company starts to cut down, put in hiring freeze telling the senior devs to produce more per person. Some even go to the extent of firing some seniors and getting junior devs and then allowing people to learn on the job.
Senior devs have expectations around salary, growth and work. Over time when the company starts running out of steam - funding, growth or even interesting work it gets difficult to keep the senior devs happy.
Once that scenario plays out, companies start scrambling to find interns or junior devs and find out, not many are not interested in working for them because they heard "rumors" about company's hard-ass culture on "not learning on the job".
Slowly, company realize that a team made of only senior devs is too costly for the value they provide. And company starts to cut down, put in hiring freeze telling the senior devs to produce more per person. Some even go to the extent of firing some seniors and getting junior devs and then allowing people to learn on the job.
>Senior devs have expectations around salary, growth and work.
A Junior Dev will have them, too, though. Not the ones fresh out of college, but maybe the ones that already worked for 6 months or so.
A Junior Dev will have them, too, though. Not the ones fresh out of college, but maybe the ones that already worked for 6 months or so.
No doubt about it. The only difference is Junior Devs expectations can be tempered a bit. Senior Devs are more demanding.
My experience at Google and Facebook is that junior devs are hires in great numbers. Intern season means you can’t find a parking spot because there are so many of them. This article doesn’t ring true to me, but my view of the world is narrow since I’ve only been at big companies. Is he talking about startups? I thought those skewed young too.
I suspect this is referring the world of software at large, outside the SV sphere of influence.
The investment an organization makes in helping junior developers get up to speed pays off in the longer run if the workplace isn't toxic. Ideas flow better when there is a difference in experience level in the team. Mentoring also helps experience people learn more as opposed to settling down in a comfort zone.
This is one of those "each generation thinks it invented sex" issues - each company looks like it never trains internally, and we assume it's driven by reasons X (cheaper to not train anyone than train people and lose them)
my personal view is that most organisation structures are designed to prevent code quality and hence the reason to train anyone (senior or junior) is diminished.
My idealised view of a software dev org is a well defined code area owned by a single dev lead. that person has responsibility for certain metrics from "quality" to "performance" and "style" and some business kpis derived from the code area - and then stop measuring features produced to measuring how well those features are implemented.
sorry it's a bit early to get this clearer - will revisit in an hour just wanted a opinion
my personal view is that most organisation structures are designed to prevent code quality and hence the reason to train anyone (senior or junior) is diminished.
My idealised view of a software dev org is a well defined code area owned by a single dev lead. that person has responsibility for certain metrics from "quality" to "performance" and "style" and some business kpis derived from the code area - and then stop measuring features produced to measuring how well those features are implemented.
sorry it's a bit early to get this clearer - will revisit in an hour just wanted a opinion
The OP is missing a rather obvious point. A junior dev after months of training could jump ship for much better comp now that they're less junior or that suddenly some other company's product interests them more. Another point missing is that sometimes there are very hard problems (eg. self-driving cars, fusion power, DNA pattern matching) that need solving quickly and that's what some companies try to do, there are other type of companies that solve more mundane problems (hr software, customer relation management software, email tool) that have been solved over and over again. To bundle all companies into one category when it comes to training junior devs is a mistake, junior devs could be trained at companies working on easier problems much more cost effectively and efficiently.
I'd disagree with you in this part:
>Another point missing is that sometimes there are very hard problems (eg. self-driving cars, fusion power, DNA pattern matching) that need solving quickly
If you have let's say 5 senior devs and 1 junior. Then the problem still can get solved quickly while the junior will learn a lot. Obviously, hiring 1 senior and 5 juniors would be a mistake.
>Another point missing is that sometimes there are very hard problems (eg. self-driving cars, fusion power, DNA pattern matching) that need solving quickly
If you have let's say 5 senior devs and 1 junior. Then the problem still can get solved quickly while the junior will learn a lot. Obviously, hiring 1 senior and 5 juniors would be a mistake.
>If you have let's say 5 senior devs and 1 junior. Then the problem still can get solved quickly while the junior will learn a lot. Obviously, hiring 1 senior and 5 juniors would be a mistake.
Perhaps that is true, what I was saying is a matter of degrees not absolutes. Let me rephrase for you: to the extend that a company is working on hard problems they should minimize the ratio of junior to senior devs.
Perhaps that is true, what I was saying is a matter of degrees not absolutes. Let me rephrase for you: to the extend that a company is working on hard problems they should minimize the ratio of junior to senior devs.
I agree that the fault does lie largely with employers, but it's not just them. Jr Dev positions are there, but more often than not they are at small local companies that likely aren't paying market rate (or at least their mico-local market rate). For example: there are lots of places in Birmingham (AL) with Jr dev positions, paid internships, etc.., but you can't expect to make > $65k out of the gates.
Then again, small shops are the best place for a first dev job in my opinion. You get exposed to WAY more stuff than you would at larger more established places most of them time. There are downsides, but I personally think the most important thing for a first job is getting exposed to a lot of new stuff and learning to get comfortable in an unknown environment/stack quickly.
Then again, small shops are the best place for a first dev job in my opinion. You get exposed to WAY more stuff than you would at larger more established places most of them time. There are downsides, but I personally think the most important thing for a first job is getting exposed to a lot of new stuff and learning to get comfortable in an unknown environment/stack quickly.
When I got started, Junior developers were assigned to senior developers doing maintenance programming. It was important work but it also gave you time to come up to speed on the system without the crush of new feature development deadlines. Sadly, it seems that not only do companies not do that these days but the new breed of developers seem to think they are too good to do maintenance programming. I learned a great deal about how systems really work and how to write robust software from some great mentors who had been moved to maintenance work as they neared retirement but companies these days are quick to lose older developers in favor of less experienced and less expensive younger developers. Lots of tribal knowledge is lost in that fashion every year.
I think some of this is based on the time horizon of the company. Larger companies (especially those who favored promoting from within) historically have had large batches of fresh graduates, and trained and mentored them. Without these programs, they wouldn't have future executive talent.
Smaller companies had less relative incentive. By the time someone is good, you might be flipping the company, or bankrupt. (This isn't to say it's not worth doing, just less incented)
This shift was one of the largest differences I had to adjust to going from large to small. (It isn't just that mentoring isn't rewarded, it's that there are short term disincentives - the benefits from mentoring likely come in the next company, or the one after that)
What's this mean? Just that the burden is on the mentee.
Smaller companies had less relative incentive. By the time someone is good, you might be flipping the company, or bankrupt. (This isn't to say it's not worth doing, just less incented)
This shift was one of the largest differences I had to adjust to going from large to small. (It isn't just that mentoring isn't rewarded, it's that there are short term disincentives - the benefits from mentoring likely come in the next company, or the one after that)
What's this mean? Just that the burden is on the mentee.
In Germany at least we have apprenticeships and working students.
There is a apprenticeship program for developers (Fachinformatiker für Anwendungsentwicklung -> Qualified IT Specialist for Application development) which gets rather much practical knowledge, since they only go, I think, 2 days a week to school and 3 days a week to work. This takes 3 years, so they have much time to transition from a newbie to a junior to a senior.
The main problem is, most "professional school" are quite shitty. So if your company doesn't have good apprenticeship programs, you're basically stuck with learning outdated stuff at school and nothing of value at your company.
I studied computer science and worked as a web developer on the side, so I wouldn't finish my studies without practical knowledge.
There is a apprenticeship program for developers (Fachinformatiker für Anwendungsentwicklung -> Qualified IT Specialist for Application development) which gets rather much practical knowledge, since they only go, I think, 2 days a week to school and 3 days a week to work. This takes 3 years, so they have much time to transition from a newbie to a junior to a senior.
The main problem is, most "professional school" are quite shitty. So if your company doesn't have good apprenticeship programs, you're basically stuck with learning outdated stuff at school and nothing of value at your company.
I studied computer science and worked as a web developer on the side, so I wouldn't finish my studies without practical knowledge.
Probably a good time to say that we're trying to hire a Junior Developer in London, and I'll be providing as much mentoring as they want.
https://news.ycombinator.com/item?id=16285477
https://news.ycombinator.com/item?id=16285477
> When they didn’t understand there would be a lag as I taught these people.
In a world run by MBAs who figure that any programming task, regardless of complexity, ought to take an hour (MAYBE two) and if it takes longer that means the programmer is incapable, this is hardly surprising.
In a world run by MBAs who figure that any programming task, regardless of complexity, ought to take an hour (MAYBE two) and if it takes longer that means the programmer is incapable, this is hardly surprising.
People talk about a "developer's union" ever so often, and one of the most commonly brought up counter-points is "well, but what would we need to fight for as a union?" (not that I agree there isn't anything (else) to fight for, but:) it occurs to me that this is an excellent possibility.
Devs change jobs. This is good, but (as pointed out) means you maybe don't want to train people up; it's the next company that benefits, not yours. But, maybe if everyone paid in - companies AND people - a scheme could be figured out where you'd know that it's fine to train up, since you'll get the benefit of someone else being trained up.
It's still long-term thinking, which others are pointing out isn't common.
Devs change jobs. This is good, but (as pointed out) means you maybe don't want to train people up; it's the next company that benefits, not yours. But, maybe if everyone paid in - companies AND people - a scheme could be figured out where you'd know that it's fine to train up, since you'll get the benefit of someone else being trained up.
It's still long-term thinking, which others are pointing out isn't common.
> "well, but what would we need to fight for as a union?"
Improved compensation, benefits, bonuses, stock options, paid conferences, training, etc...
Improved compensation, benefits, bonuses, stock options, paid conferences, training, etc...
Bottom-up control of the development process. Our own apprenticeship pipeline. Our own certifications. Genuine influence over interviewing and hiring practices. Minimum contract terms. Our own lobbyists. Promoting business for members outside of Silicon Valley. Our own jobs board. A general strike fund. Our own retirement planning and pensions system. A backup health insurance option.
The lobbyists can start by bringing down the exemptions on overtime pay for tech workers, and by trying to loosen immigration restrictions on the people of our industry.
The lobbyists can start by bringing down the exemptions on overtime pay for tech workers, and by trying to loosen immigration restrictions on the people of our industry.
> "loosen immigration restrictions on the people of our industry"
I don't think a U.S. union would try to loosen immigration restrictions...they'd care about protecting the rights of U.S. workers...also, why would a union representing U.S. workers want to increase the labor supply?
I don't think a U.S. union would try to loosen immigration restrictions...they'd care about protecting the rights of U.S. workers...also, why would a union representing U.S. workers want to increase the labor supply?
Naturally, it would be to ensure that all the best people in the world are members of the union, and employing filthy non-union scabs would therefore mean lower quality product.
The companies are multinational, so the unions have to be multinational, too. If the company tries to skirt around the union by doing the work in India instead of the US, the union should anticipate the move and surprise the company by already being there, still demanding a better deal for our people.
I anticipate the demand for people with technical skills will continue to rise in the future. There is no need to artificially limit the labor supply anywhere, even worldwide, because the world's universities already can't crank out enough people with official credentials. (And when they do, the new graduates still can't get jobs, because that degree apparently still isn't good enough to meet business expectations.) The union could still eat up much of the bootcamp and intern business with its own apprenticeships. That's when it might try throttling the supply, after gaining some control over it, by operating at the optimal point for monopolistic competition. Restrict it just enough to squeeze more money out of the market, but not enough to allow a new competitor to enter.
And it benefits all of us to be able to shop around to different jurisdictions as easily as those who employ us. The countries and companies that provide the most attractive environments will get more of us, and therefore prosper, while those who are hostile will get less of us, and therefore rapidly descend into a new dark age of wretchedness and despair, where nothing works properly and half the kiosks and infoscreens either show BSoD or a console screen with no attached keyboard. Then they will rue the day they snubbed the nerds, and weep into their low-tech cloth pillows.
(WARNING: This post may contain hyperbole.~)
The companies are multinational, so the unions have to be multinational, too. If the company tries to skirt around the union by doing the work in India instead of the US, the union should anticipate the move and surprise the company by already being there, still demanding a better deal for our people.
I anticipate the demand for people with technical skills will continue to rise in the future. There is no need to artificially limit the labor supply anywhere, even worldwide, because the world's universities already can't crank out enough people with official credentials. (And when they do, the new graduates still can't get jobs, because that degree apparently still isn't good enough to meet business expectations.) The union could still eat up much of the bootcamp and intern business with its own apprenticeships. That's when it might try throttling the supply, after gaining some control over it, by operating at the optimal point for monopolistic competition. Restrict it just enough to squeeze more money out of the market, but not enough to allow a new competitor to enter.
And it benefits all of us to be able to shop around to different jurisdictions as easily as those who employ us. The countries and companies that provide the most attractive environments will get more of us, and therefore prosper, while those who are hostile will get less of us, and therefore rapidly descend into a new dark age of wretchedness and despair, where nothing works properly and half the kiosks and infoscreens either show BSoD or a console screen with no attached keyboard. Then they will rue the day they snubbed the nerds, and weep into their low-tech cloth pillows.
(WARNING: This post may contain hyperbole.~)
God no.
I don't want to be mandated to strike and pout over not getting enough money. As long as I am treated fairly (I am) and paid fairly (I am), I am not paying any percentage to some company to tell me to screw over my employer.
If some company wants to unionize, have fun but I am not joining that party.
I don't want to be mandated to strike and pout over not getting enough money. As long as I am treated fairly (I am) and paid fairly (I am), I am not paying any percentage to some company to tell me to screw over my employer.
If some company wants to unionize, have fun but I am not joining that party.
Have you ever been in a union?
> "...pout over not getting enough money"
You're trying to make striking sound childish but there are plenty of legitimate reasons why unions go on strike.
> "...pout over not getting enough money"
You're trying to make striking sound childish but there are plenty of legitimate reasons why unions go on strike.
>Have you ever been in a union?
No. There is a reason I went into software development and not blue-collar work. ;)
(Nothing wrong with it, just not the stuff I want to deal with. Unions included. I lose enough money already to the gov't.)
No. There is a reason I went into software development and not blue-collar work. ;)
(Nothing wrong with it, just not the stuff I want to deal with. Unions included. I lose enough money already to the gov't.)
I went the trades route because I didn't have any concrete plan for college when I finished high school and I wanted to get some form of gainful employment so an electrical apprenticeship seemed like a good idea until I figured out something else.
I have been in a union before (nearly a decade of industrial electrician/power plant operator work before I obtained my CS degree). You bet there is corruption in some unions, but perhaps it is different in the "skilled trades" though, at least it seems that way from my personal experience.
Avoiding blue collar work is a primary motivation for my transition to full time software dev...we'll see how it turns out though because the office culture/work environment is very foreign to me in many ways.
I have been in a union before (nearly a decade of industrial electrician/power plant operator work before I obtained my CS degree). You bet there is corruption in some unions, but perhaps it is different in the "skilled trades" though, at least it seems that way from my personal experience.
Avoiding blue collar work is a primary motivation for my transition to full time software dev...we'll see how it turns out though because the office culture/work environment is very foreign to me in many ways.
I'd like to think that a tech worker's union composed of people already aware of white hat, grey hat, and black hat distinctions would be set up with some structural impediments to corruption. In my head, it would have similar structure to working groups, where stuff gets done by consensus, without anyone having so much authority that they can do an obviously wrong thing and still preserve their influence.
I'm not sure how it would work to have a union that can essentially fork itself whenever the leadership goes bad, or even one that has no leadership to begin with, and manages everything with a consensus/compromise algorithm.
I'm not sure how it would work to have a union that can essentially fork itself whenever the leadership goes bad, or even one that has no leadership to begin with, and manages everything with a consensus/compromise algorithm.
[deleted]
So I've read through most of the complaints listed here and it seems like having a Software Developer Union would be one way to go. You could then have your jr devs undergo an apprenticeship similar to how we did it in the trades (5 years to become a Journeyman).
My company hires junior devs. We mentor them and train them up. When their skill level goes up they get paid more after reviews. Some have left and that's fine and is natural in a company. We take interns on too and have hired from that pool as well.
Underwhelming article. I'd say the junior devs are now funneled through contract positions. My experience has been that my companies I work for typically take on junior level roles as interns or contract positions. Take on a couple of contract gigs in the early part of your career till you find a place you like and become a recognized and appreciated contributor. Then when your contract expires push for converting to full time, which usually works best with a counter offer in hand. Throw the dice on dice.com but withhold your full contact information and only give it out to roles you wish to filter. You'll thank yourself in the future in avoiding future spam.
First of all, absolutely no employer (at least the sane ones) cares if you are junior/senior/old/ninja or superman. The goal is, to hire people that generate a cash turnover. If you cannot deliver a value that the company can capture as a profit - you are denied. It is that simple.
Maybe these "Junior" people just don't know enough to be productive? How can I hire someone who will waste my time on explaining something that is so basic, one can learn by being involved in open source?
And here is the conclusion. Stuck in Junior limbo (what ever that means)? Commit to some open source project, show me value you can create. I guarantee you, you'll be hired.
Maybe these "Junior" people just don't know enough to be productive? How can I hire someone who will waste my time on explaining something that is so basic, one can learn by being involved in open source?
And here is the conclusion. Stuck in Junior limbo (what ever that means)? Commit to some open source project, show me value you can create. I guarantee you, you'll be hired.
The existential angst experienced by Hacker News developers is amazing. One moment I am reading articles proclaiming that "nobody hires Senior Developers" (which is nonsense). And people freak out. Followed shortly by "nobody hires Junior Developers" (which is also nonsense). With an equal amount of freaking out. So should we conclude, based on the "wisdom" of Hacker News, that nobody hires any Junior or Senior or any other Developers of any age/sex/...? Of course not. Because developers get hired every day, all the time.
Wait I see so many comments about how junior devs not being hired that much anymore. So is this really a bad time to consider software development as a career path if I have no degree or required formal training?
Shameless plug: I’m starting a newsletter writing about career advice for junior developers. I’m at the point in my career where I feel like I can share my experiences and give direction on what I learned and what junior engineers should focus on when it comes to soft skills. I won’t be getting too technical. It’s the soft skills that I struggled with so it’s the soft skills that I want to help with.
If you’re interested you can subscribe at https://exponentialbackoff.substack.com
If you’re interested you can subscribe at https://exponentialbackoff.substack.com
I find this surprising. My experience is that companies are generally competing for developers, even junior ones. Some actively go to universities to advertise their company for this exact purpose.
Companies want to hire junior developers because they can pay them half of what they pay senior developers. But they also want the junior developers to have the same experience ...
I had a similar experience. 15 years ago, with less than 1 year of experience I couldn't get a job to save my life. I had to work for companies for free! 5-10 years later, I was getting up to 5 offers for a job while interviewing.
And yet, it's not like junior developers suck. I've seen plenty of junior developers who can build up an application, no problem. There might be some mistakes along the way, but they're able to get the job done.
And yet, it's not like junior developers suck. I've seen plenty of junior developers who can build up an application, no problem. There might be some mistakes along the way, but they're able to get the job done.
I've seen junior devs hired and trained/mentored in pretty much every shop I've worked in (could be an Austin, Texas thing). But, if this is a problem generally, would it not just be a consequence of not expecting to be able to keep junior developers long enough to benefit from them? Or, if the hiring managers intend to flip the company in a year or two, not really caring about the long term pool of senior developers?
Hi - Melissa's blog post and the ensuing thread encouraged us at WSO2 to share our views on this topic in a response essay that talks about the importance of junior software engineers in a company.
https://medium.com/@tylerjewell/bringing-life-to-new-softwar...
https://medium.com/@tylerjewell/bringing-life-to-new-softwar...
Smart junior devs make good algorithm designers. Most senior devs don't remember algorithms unless they do that sort of work - they just call into it.
Hire several and put them to work under a good mentor, on a project that requires little domain knowledge. They won't slow the seniors down, and finding a single successful one is worth the cost of taking a chance on the bunch.
Remember, most startups happened with teams of fresh grads.
Hire several and put them to work under a good mentor, on a project that requires little domain knowledge. They won't slow the seniors down, and finding a single successful one is worth the cost of taking a chance on the bunch.
Remember, most startups happened with teams of fresh grads.
I'm lucky to work where I do. We have the best system I've seen for growing junior developers. Our team is about 60 engineers and I'd say close to 20 of them are from non-traditional backgrounds (coding bootcamps or self taught). It's not that we're doing anything revolutionary, we merely accept that we can handle them, assign them a mentor, and let them learn.
Junior devs are significant drain on senior devs resources which could otherwise be spent more productively. And once he or she matures a bit, he or she gets hired somewhere else as senior for double the money. Thus hiring seniors and not bothering with juniors have obvious business sense (until there is a way to bound juniors somehow - for example by immigration).
> For my own part, I’m happy to mentor folks
Oh joy, I can't wait to be mentored by someone who held a bunch of random front end positions for about 8 months, has 2 endorsements for javascript, nothing for backend, no degree in this field, considers themselves an author now and uses their gender as a weapon/excuse in their public musings.
Oh joy, I can't wait to be mentored by someone who held a bunch of random front end positions for about 8 months, has 2 endorsements for javascript, nothing for backend, no degree in this field, considers themselves an author now and uses their gender as a weapon/excuse in their public musings.
Stack Overflow pops up plenty of "new grad" level jobs all the time, for example https://stackoverflow.com/jobs/155829/google-software-engine...
[deleted]
Does anyone have any suggestions on how to make myself available for mentoring over the internet? I'm sure there's many possibilities, but has anyone had actual success with any?
Preferably I could get paid doing it, but if that's not really feasible then I wouldn't mind pro bono.
Preferably I could get paid doing it, but if that's not really feasible then I wouldn't mind pro bono.
Find a Slack or IRC channel and hang out there. Example: I spend a lot of time in #FoundationSites, #Symfony, #Aurelia and answers questions there.
Off topic, but this is the first Medium membership-exclusive content I've come across.
Discussion about it: https://news.ycombinator.com/item?id=13933550
Discussion about it: https://news.ycombinator.com/item?id=13933550
This piece reminded me of my days in the restaurant business as a teenager. Was common for everyone to do a tour there, but now the jobs are mostly done by the “undocumented.” Don’t care to discuss the politics of that but it feels similar.
This is of course because of outsourcing. Junior devs usually do repeatable tasks guided by a manager closely, which is exactly what outsourced heads can do, definitely cheaper than the junior devs in the U.S. would. This is normal.
Guess who won't have senior devs in 10-15 years.
Outsourcing destinations, because there is little demand for senior outsourcing heads. They become harder to manage, and their jobs are high impact enough to justify the expense of hiring them in the Valley directly.
People who outgrow junior level will just make their own startups, or move to U.S. from the locations: outsourcing shops won't need them; more: they will take conscious effort to prevent them from ever growing, because growing, they become threats to these body shops.
People who outgrow junior level will just make their own startups, or move to U.S. from the locations: outsourcing shops won't need them; more: they will take conscious effort to prevent them from ever growing, because growing, they become threats to these body shops.
Here's a plausible answer: https://blog.codinghorror.com/why-cant-programmers-program/
Seems like one week I read that firms only want to hire freshly minted engineers because they are cheap and easy to exploit, then next week I read they only hire senior developers because they're more productive.
The great irony of this article is that the author has degrees in forestry and agriculture and a very weak development skillset based on their LinkedIn profile and they still got a junior developer job.
The economy killed the Junior developer. If we ever are in a situation where there are more applicants than jobs and the economy isn't doing well you can be sure the junior developer will be back.
Part of the problem is head count, at least in the company I work for. We had a hiring freeze and now we are allowed to hire two heads. I would love to hire one senior and two juniors but I can't.
pretty sure the easy answer is Bootcamps
Or just read a "Learn FancyNewLanguage in 14 Days" book.
/s
/s
Is out there any data or evidence that support her article? to me it sounds the typical bubble problem: you think it's generalized problem but the data shows another thing.
300 $ / hour ?
300 * 8 * 5 * 20 -> 240K$ per month ? It seems far too much.
This might be why they can't afford junior developer.
$300 an hour is about 600k/year. In many cases, this is actually probably a good estimate for developer opportunity cost for the company.
My working career is only a couple years old at this point so I'm more junior but in both of those years I can point to contributions that were worth more than 600k to the company. That being said, I personally don't even make a third of that $300/hour. But that's the whole reason a company decides to hire you -- they think you'll make them more money than you'll cost.
My working career is only a couple years old at this point so I'm more junior but in both of those years I can point to contributions that were worth more than 600k to the company. That being said, I personally don't even make a third of that $300/hour. But that's the whole reason a company decides to hire you -- they think you'll make them more money than you'll cost.
What's the "5" in your equation? :)
However it's still way too much. 300 * 8 * 22 * 12 = 0.63M per year. In my opinion you must be at least Linus Torvalds's deputy to pretend on that.
However it's still way too much. 300 * 8 * 22 * 12 = 0.63M per year. In my opinion you must be at least Linus Torvalds's deputy to pretend on that.
Did she mean daily rate? I wonder if a junior ask for this rate, of course the company has no chance to afford a senior dev.
I am so pissed of that "Only members of Medium may see responses to this story."
I thought I was a member but I learnt that it is 5$/mo.
I thought I was a member but I learnt that it is 5$/mo.
In an industry, glorified itself with automation, it is not really that hard to find out the automation first happens within itself.
There are always higher abstraction levels and new problem domains. If you lose your job to automation as a software dev, you've gotten complacent.
Put junior devs to work on the new stuff, not what you started on yourself.
Put junior devs to work on the new stuff, not what you started on yourself.
Junior dev needs to establish trust before they can be put into the 'new' stuff. They are called junior, for a reason.
Ultimately, this industry now has enough people to spare, impact is what everyone is fighting for, this applies for junior dev as well.
Ultimately, this industry now has enough people to spare, impact is what everyone is fighting for, this applies for junior dev as well.
Junior developer here.
I worked as a programmer for 1.25 years. I left 3 years ago, the company went bankrupt yesterday. When I last checked about it, I saw several of my coworkers replaced with someone else.
The boss kept adding people to his 10+ sales team, and I remained the only developer. Not very long after I joined I prepared a speech about needing a lot of time and preferably an extra developer to clean it up. The web app was written by 1 person for 4 years. No documentation of course, not tests, guess what also no version control. The boss had a sales background and I guess he considered salespeople sources of income, while developers - sources of expenses.
I guess I should be grateful that he hired me? Yes, but the only thing he cared about was if it works and how it looks from the outside. The few online comments there were on the bankruptcy article included one that said the place had mobbing, and another he was lucky he was rejected when asking for a job there because the interview was terrible. (When I was applying, I got a proposal to work with no contract in exchange for higher pay. I rejected that one.). I thought I was maybe paranoid or oversensitive, but now I'm sure I got hired in the first place because I looked desperate.
If I performed stellar, I would have a good success story, but there's limit to how many advanced topics a junior developer can pick up alone while still cleaning up. REST endpoints could really have helped against competition, but then again if he hired an experienced dev after me he would have saved him too. I made a point to write reST documentation describing everything I learned during refactoring/upgrading process, how to run tests, what the various modules are for, where the bottlenecks are, the staging server image, etc.
I fucked up when switching jobs and didn't sign a contract immediately. I thought a verbal agreement was enough. Then I was fired after 4 days, citing poor performance, slooow work speed etc. I never thought I was amazing, but with his other hand the new boss offered me to enter an internship program. He said I would learn a lot. He also sent me some Python video tutorials made by his friend (who works at a university). I told him I took mine from MIT and certainly don't believe a country whose best university is not in the top 400 globally could produce something better... and it was basically a backwater university, not even the top one. Later I found out he had a deal with an (state-funded) employment bureau. He was providing internship programs for aspiring programmers, and the bureau was super happy to send people on "training programs with guarantee of employment". Both parties were happy - the crook had a constant influx of temporary cogs, the bureau had could boast high effectiveness. I keep seeing new entry level developer jobs from that place, and yet the company is NOT growing.
Let me tell you it takes a tremendous amount of willpower just to train at home and remain employable. I've found that hands down the best thing I can do to keep getting job interviews is to regularly commit to github. I enjoy programming, but I'm not passionate about it. You can like strawberries, but 3 pure strawberry courses a day is too much for most of us. It helps to have not one but a variety of side projects so you can alternate between them, and at least one extra programming language (I rewrote someone's glitch art app in Rust).
It doesn't help job interviewers are kinda autistic. I don't mean in the "they suck" sense, but that they have major communication problems. They never tell why they didn't like you, you must infer it from their behavior and observe what kind of behavior gets you more interviews. They always think they can get another one, so why bother explaining anything. Depression + anxiety doesn't help. Dating is super fun by comparison. At least you get to see a pretty girl.
The bottom line: some people only hire junior devs to cut costs.
I worked as a programmer for 1.25 years. I left 3 years ago, the company went bankrupt yesterday. When I last checked about it, I saw several of my coworkers replaced with someone else.
The boss kept adding people to his 10+ sales team, and I remained the only developer. Not very long after I joined I prepared a speech about needing a lot of time and preferably an extra developer to clean it up. The web app was written by 1 person for 4 years. No documentation of course, not tests, guess what also no version control. The boss had a sales background and I guess he considered salespeople sources of income, while developers - sources of expenses.
I guess I should be grateful that he hired me? Yes, but the only thing he cared about was if it works and how it looks from the outside. The few online comments there were on the bankruptcy article included one that said the place had mobbing, and another he was lucky he was rejected when asking for a job there because the interview was terrible. (When I was applying, I got a proposal to work with no contract in exchange for higher pay. I rejected that one.). I thought I was maybe paranoid or oversensitive, but now I'm sure I got hired in the first place because I looked desperate.
If I performed stellar, I would have a good success story, but there's limit to how many advanced topics a junior developer can pick up alone while still cleaning up. REST endpoints could really have helped against competition, but then again if he hired an experienced dev after me he would have saved him too. I made a point to write reST documentation describing everything I learned during refactoring/upgrading process, how to run tests, what the various modules are for, where the bottlenecks are, the staging server image, etc.
I fucked up when switching jobs and didn't sign a contract immediately. I thought a verbal agreement was enough. Then I was fired after 4 days, citing poor performance, slooow work speed etc. I never thought I was amazing, but with his other hand the new boss offered me to enter an internship program. He said I would learn a lot. He also sent me some Python video tutorials made by his friend (who works at a university). I told him I took mine from MIT and certainly don't believe a country whose best university is not in the top 400 globally could produce something better... and it was basically a backwater university, not even the top one. Later I found out he had a deal with an (state-funded) employment bureau. He was providing internship programs for aspiring programmers, and the bureau was super happy to send people on "training programs with guarantee of employment". Both parties were happy - the crook had a constant influx of temporary cogs, the bureau had could boast high effectiveness. I keep seeing new entry level developer jobs from that place, and yet the company is NOT growing.
Let me tell you it takes a tremendous amount of willpower just to train at home and remain employable. I've found that hands down the best thing I can do to keep getting job interviews is to regularly commit to github. I enjoy programming, but I'm not passionate about it. You can like strawberries, but 3 pure strawberry courses a day is too much for most of us. It helps to have not one but a variety of side projects so you can alternate between them, and at least one extra programming language (I rewrote someone's glitch art app in Rust).
It doesn't help job interviewers are kinda autistic. I don't mean in the "they suck" sense, but that they have major communication problems. They never tell why they didn't like you, you must infer it from their behavior and observe what kind of behavior gets you more interviews. They always think they can get another one, so why bother explaining anything. Depression + anxiety doesn't help. Dating is super fun by comparison. At least you get to see a pretty girl.
The bottom line: some people only hire junior devs to cut costs.
Some data that's not anecdotal would be nice. I work for a fairly large SF company which hires mostly newgrads every year.
Hire and develop the best: Leaders raise the performance bar with every hire and promotion. They recognize exceptional talent, and willingly move them throughout the organization. Leaders develop leaders and take seriously their role in coaching others. We work on behalf of our people to invent mechanisms for development like Career Choice.
edit: this is from the Amazon leadership principles
edit: this is from the Amazon leadership principles
>Or track the people struggling with development into a place where they can succeed like project management
Do you really want project managers who couldn't cut it as a developer?
I'm assuming we are talking about software projects here. If so, the idea of putting someone who couldn't make the grade on the bottom rung in charge of the whole enterprise seems like a bad idea.
Do you really want project managers who couldn't cut it as a developer?
I'm assuming we are talking about software projects here. If so, the idea of putting someone who couldn't make the grade on the bottom rung in charge of the whole enterprise seems like a bad idea.
companies need to follow the 80/20 rule. 80% non-junior developers and 20% junior. Juniors should do 80% of the work and seniors should have 80% of the knowledge. if the juniors are busy doing things then the seniors that focus on hard tasks.
the guy that code reviewed him
Senior Developer in the Screen Share with the Pull Request.
That feels too dumb to be real (which is exactly why it's probably a real thing).
You don't hire senior devs to code - good junior devs can code not only "just as fast", but probably faster too! You hire senior devs to guide you WHAT and HOW to code. And they can do that so much more effectively if they don't have to actually code all that stuff themselves! "Mentoring" is basically the job you hire a senior dev to do... how can people say with a straight face that they can't afford to let them do it?
I don't view this as "tragedy of the commons" as other people here suggest. I view this as plain human stupidity (which we're all guilty of, sometimes... it's just good to realize when you're being stupid before it seriously hurts you).