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!
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.
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.
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.
>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.
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 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.
How would you feel about mentoring non-technical people? Uber seems to be piloting an apprenticeship program for people from non-technical backgrounds:
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.
> 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.
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?
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.
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.
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.
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.
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).
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.
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.
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.
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.
> "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.
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.
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.
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.
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.
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.
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.
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.
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".
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.
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.
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.
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 ?.
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?
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.
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 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.
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."
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.
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.
> 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.
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.
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
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.
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
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.
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.
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.
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'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).
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").
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.
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.
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.
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?
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...
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.
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 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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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 :)
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'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 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.
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.
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 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.
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.
> 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?
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.
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.
Given everything that has been discussed on this very page, what's wrong with mercenary tactics? WTF? Companies hold no loyalty to anyone except maybe their inner circle, MBA types are the most mercenary pigs around, and yet you expect a developer with actual skills and something to offer to act differently? How about no?
You get maybe 25 years to make all the money you're ever really going to make as a developer. That's it! So you better fucking be a mercenary. What you're really saying when you see that on a resume is: "Here's someone I can't exploit, mistreat, or fuck over" and that terrifies you.
I'll change jobs whenever and however it suits me. Hell, I once quit a gig because the bathrooms stank too much!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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 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.
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.
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?
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.
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.
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.
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.
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.
> 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.
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.
> 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.
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 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.
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.
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 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?
>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.
> 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 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.
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 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.
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.
>
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.
> 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.
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.
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).
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)
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.
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 _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.
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
I have to disagree with this point. Switching jobs is a very stressful and scary experience. Most people don't want to jeopardize their income without having some very strong motivator. In my experience, the most common reasons someone changes jobs is:
- Promise of a higher income
- Low perceived stability at the current job (employees want to secure a new job before they're layoffs)
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!"
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.
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.
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.
> 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.
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.
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.
> 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?
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
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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
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
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.
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.
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.
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).
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 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?
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.
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.
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 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.
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'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.
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.
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.
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!
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.
802 comments
[ 4.1 ms ] story [ 478 ms ] threadWell 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 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).
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.
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.
(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.
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.
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.
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.
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.
If not, over what time span are you considering?
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 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.
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.
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).
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.
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.
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.
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.
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.
> 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.
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.
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.
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".
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.
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 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.
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?
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.
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.
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.
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.
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...
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.
(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.
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
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.
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.
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 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.
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.
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.
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.
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 love hiring and mentoring junior developers, but the barrier to entry is quite high. Employers love junior developers with aptitude and enthusiasm.
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?
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.
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.
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.
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.
This isn't law...even the cheap universities offer CS degrees.
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.
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 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!
If other companies are willing to pay those salaries, why would you say they don't deserve them?
Why would you equate availability with appropriateness?
Or does your comment apply to fresh grads? Because then your comment would make more sense to me.
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.
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.
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.
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?
But I noticed hiring practices here in Europe are much better anyways than in the US.
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.
You get maybe 25 years to make all the money you're ever really going to make as a developer. That's it! So you better fucking be a mercenary. What you're really saying when you see that on a resume is: "Here's someone I can't exploit, mistreat, or fuck over" and that terrifies you.
I'll change jobs whenever and however it suits me. Hell, I once quit a gig because the bathrooms stank too much!
'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
I would say a good 10-20% do have some kind of contact in the industry though and get a job that way.
But yes look at placement rates at any bootcamp before joining. If people are getting jobs then it's well worth it.
But yes some people have plenty of self motivation and can do it themselves. The career networking is really all they need then.
Not to say this would or wouldn't justify various tuition rates - but it's definitely part of the equation.
Most of my friends have the job they have because of a combination of Twitter and attending conferences on discounted student tickets.
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.
That's probably a mistake on your part, especially when tools like LinkedIn make it so easy.
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 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.
I'm biased though because I got my first two jobs this way.
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.
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 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.
If it means you're still learning something a little extra, that's great! If not, that's okay too.
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.
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.
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.
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.
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.
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 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.
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.
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 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 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'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.
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.
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.
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.
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 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.
/s
How good (or bad) companies are at actually training their employees is another matter.
edit: typo
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)
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.
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.
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.
You mean a salary or title increase? Yeah, that's in the GP's comment.
- 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
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.
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.
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.
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.
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.
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.
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.
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.
Is there a counterfactual? A company with a strong culture of promoting from within that outperforms as a likely result of this attribute?
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.
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!"
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.
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.
It also looks good from the outside.
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.
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.
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.
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?
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
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
There's just a hell of a lot of title inflation in general, I think.
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.
I also think the article needs some copy editing. A few paragraphs were rough to get through.
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.
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 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.
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?
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.
I’m only mostly joking.
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'd also say that many junior devs are offshore and are given test and support tasks, and this is especially true in larger corporations.
That really is how it works though. You need to start doing before you can learn.
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.
There have been plenty of trained or semi-trained labour shortages in the history of the world, with similar results.
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.
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!
I mean, yeah, it'd be good for employers. Not so much for employees. Likely an illegal or unenforceable contract, too.