Hacker News new | comments | show | ask | jobs | submit login
Who Killed the Junior Developer? (medium.com)
803 points by gregorymichael 8 months ago | hide | past | web | favorite | 777 comments



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

That feels too dumb to be real (which is exactly why it's probably a real thing).

You don't hire senior devs to code - good junior devs can code not only "just as fast", but probably faster too! You hire senior devs to guide you WHAT and HOW to code. And they can do that so much more effectively if they don't have to actually code all that stuff themselves! "Mentoring" is basically the job you hire a senior dev to do... how can people say with a straight face that they can't afford to let them do it?

I don't view this as "tragedy of the commons" as other people here suggest. I view this as plain human stupidity (which we're all guilty of, sometimes... it's just good to realize when you're being stupid before it seriously hurts you).


In my current job, for a tech company with less than 12 people, at least 5 are interns. Two of them were recent hires (January) and before they were onboarded, i had a meeting with my boss and the other senior developer regarding the new interns and my boss stated he didn’t want me and other senior dev spending too much time mentoring the interns and that if they couldn’t manage by themselves, he would just let them go (one is software dev intern, relocated from Lithuania).

As far as i know, management provided zero training (online courses, conferences, books etc) and the dev intern is receiving 500€/month for 40h work week, which around Amsterdam/Netherlands hardly covers housing expenses in shared accommodation, even though the intern is soon expecting Erasmus support, which will alleviate his situation apparently.

Needless to say i find the situation rather vile independently if it’s a common practice or even if non-paid internships are common.

Recently i took the dev intern out for dinner and beers, gave him a few tips on how to improve himself to be ready for a decent job (online courses, writing blog posts etc) and told him he could repay me by paying forward to an intern at his next proper jobs.

As a note, another intern (part time) is also working on his maybe 5 years old laptop that apparently crashes a lot and can hardly run something like Pycharm.

I’m looking for another job :-)


The Netherlands is a special place in Software Hell. Where the non-suits are only a cost.

"Devs can't be cheap enough! We can't find decent devs!"


That's a silly generalization. I've got a pretty good overview of software development in Western Europe and NL isn't a special place for better or worse compared to the surrounding countries.

If you want to get paid a lot more and you have the right skills the City or Silicon Valley are good options (assuming you are allowed to move there).


Perhaps a bit over generalized but I do feel that there’s an unusual large gap in salary between suits and devs even when comparing to countries like Germany.

It doesn’t need to be a huge tech hub at all. Luckily English resembles Dutch so most Dutch speak it well enough to survive a job abroad.


The city-to-city variations in Germany are far larger than the city-to-city variations in NL because of the German history and the presence of Poland. So when you are comparing countries you need to go a bit deeper than that.

I know very well paid developers in NL and very poorly paid ones, it is mostly a matter of knowing what you are worth and refusing to charge less than that. You might find 'your spot' taken by a skilled immigrant but that's a relatively small chance.

I'd hate to have to find a developer job in Spain or Portugal judging by the number of people from there that have moved to either NL or DE. Anything East of the German-Polish border is going to pay a lot worse unless you are willing to move to Finland where there are pockets of start-ups with reasonable compensation.

Dutch developers moving abroad to increase their salary is not a trend as far as I can see.


Yet across the Polish border developers are relatively well paid versus the suits and it's actually an attractive profession for people that are career oriented. I always see more women working in IT where the job actually pays well, including the US.

I know well paid developers as well, some niches pay pretty well. SAP for example. Or simply people that have domain knowledge that's irreplaceable and know how to negotiate. But something average like C#, RoR or Node development doesn't really pay well in The Netherlands. It's a decent salary but nothing to brag about.


> Yet across the Polish border developers are relatively well paid versus the suits and it's actually an attractive profession for people that are career oriented

My take on this: it's so easy for Polish developers to move to and find a job in Western Europe, that local companies have to pay salary that provides at least a roughly comparable living standard (vs the West)- as otherwise talented people would just leave. For "suits", on the other hand, there's far less opportunities abroad, so their wages don't need to track Western standards so much.

This effect is even stronger in Ukraine, where a teacher will be paid $300 (per month) while a dev will make $3000.


What city?


"the City": London's financial services sector.


"The City" - also refers to NYC if you are in the surrounding area, refers to Manhattan if you are in an outlying Borough, and refers to San Francisco if you are in the outlying Bay Area. I am sure there are more :)


Well, if you're an exploited contractor from India or China or a member of a family that already has residence you should have no problem. If you're a well-educated person from the Netherlands you'll never get in - unless you try moving to Canada and use their point system.


As a Netherlander, I agree. There are so many bad developers here, and that's from somebody who considers himself barely able. Also, as a developer you're expected to do lots of unpaid overtime while getting paid the absolute minimum.


STEM "shortage" in a nutshell.


Just want to point out that often the interns will receive additional compensation from their programs. When we hire interns from Erasmus+, they are given 500 euro from us, as well as 500 euro from their program. Additionally, Erasmus students are eligible for student housing from UvA or the VU. Finally, because they are in a special class, as interns, here in NL, we can actually get in trouble with the government for paying them more than 500 euro. It sounds to me like your management team isn't giving them the resources they need to survive in the city, but know that they are there. We have taken on four interns over the past two years, and after their internships placed them at large companies like Trivago and Elsevier, hired one on fulltime, and are working with the last to land a job in his preffered location. With the proper mentorship, it can be a great deal for students! If you are looking for a company where you are expected to mentor the junior devs and interns, send me a DM and we can see if you would be a good fit :)


I have a hard time believing that you will get in trouble for hiring interns and compensate them more than 500 euros. In the NL you aren't even obliged to give them any compensation and if you are compensating them you are free to do so as much as you'd wish.

Internships in the Netherlands are akin to modern slavery imo. You work full time and with luck you get a compensation of 500 euros a month,though often no compensation is more likely to be the case. You will get a maximum loan of 1100 euros a month from the government, so a lot of students have to take on a second job if they don't get any compensation at all at their internship.

National institute of neuroscience provides no compensation whatsoever, and for applied mathematics students the average compensation is around 200 euros.

Obviously not wholly related to your comment but the internship situation in the Netherlands really grinds my gears.


Normative answer (in Dutch), I have no practical experience either way: https://www.rijksoverheid.nl/onderwerpen/minimumloon/vraag-e...

Your employer has no obligation to compensate for your internship, but is not prohibited either. There is no minimum or maximum amount set for this compensation.

The focus for internship should be on training, not work. If the Inspectie SZW (employment auditor) finds that the internship consisted of mostly paid work, the employer will be ordered to salary the intern according to normal wages [effectively, minimum wage].

However, there is a practical limit to compensation: students earning more than E20,000 a year are no longer eligible for the student loans you mention.


AFAIK that maximum is only for the "gift" that was superseded by a loan which has no max income limit.


Oh believe me... Coming from the US, the summer between my first and second year, I was compensated 5k for three months of work. When I first heard what was standard in NL I was shocked. Then again, I was also paying 50k per semester for school, soooo yeah, take your pick haha. I wouldn't say slavery, more like indentured servitude. Anyways, I make it my personal goal to give our interns as much of mine and our senior devs' time as possible, as well as support after their internship is over.


I would hope you'd make more than $5k working in software for a summer. I was making that a decade ago wearing a hard hat and pushing a broom in a power plant on my summer breaks...


> I have a hard time believing that you will get in trouble for hiring interns and compensate them more than 500 euros.

Student visas?


>Finally, because they are in a special class, as interns, here in NL, we can actually get in trouble with the government for paying them more than 500 euro.

Hmm...I don't think you are correct, or possibly you are misconstruing a limited, special case to generally apply.

From my own experience I earned more than 600eur as an intern in the NL, and I had classmates who earned full minimum wage as interns too (~1200eur).


He is being paid with generous social security net (for which he doesn’t necessarily qualify) and with the priviledge of living in developed country with extensive infrastructure... /s


I understand your sarcasm, but what is sad some people actually think this way.


> I’m looking for another job :-)

Good, I was just going to suggest that!


Is there no room to fight management or make them understand?


High probability of “not productive effort”, i’m fighting my own rather serious battle with management at the moment.

On further note, before i started the contract i was asked to bring my own laptop as work computer, i didn’t necessarily agree (for all the obvious reasons as security and business/personal risk) but he was being pushy about i said i could take my laptop (at least to get started) and i was expecting to get a working computer. I never did. Management recently purchased brand new macbook pros and iphonex for themselves (which they are in their full right to do).

So i didn’t even dare to criticize them regarding the interns. I already got myself in boiling water by criticizing management in that the way projects and tasks were being managed was highly unprofessional and my only wish is if i could leave a warning sign for interns (and devs) to keep clear of this company (or think really hard on how much they need the job)

Edit: which is unfortunate given that the projects there are interesting in my opinion


    I already got myself in boiling water by criticizing
    management in that the way projects and tasks were being
    managed was highly unprofessional...
Communicating with managers is a bit of an art. I think a large part of what makes a developer "senior" is their ability to do this effectively.

I'm not making any comments on your personal situation, but as a general rule it's important to talk in terms of solutions and not problems. So don't say, "we have a problem and here is my recommendation to solve it". Say instead, "I think we can improve our productivity by...", or "I think we can save some money by...".

Do some calculations to help sell your case. You want to spend time optimising the build process? Record how long it takes to build the code currently. Maybe it takes 5 minutes. Maybe you build the software no fewer than 12 times a day. That's an hour of productivity wasted per developer. Do the maths, convert it into dollars. Then say, "we can save X dollars a week by optimising the build process. We spend a week working on this, we will have made our money back within a month (or whatever it is)."

Your manager will be quite happy to go to the board to tell them that he's improved efficiency by a factor of X.

Highlighting existing problems, even whilst providing solutions can put a manager on the defensive when you really need him to be your ally.

Obviously I'm not saying never highlight problems. Sometimes you have to highlight problems, but it requires delicacy and if you don't need to, then don't. You probably don't need to a lot more than you think. We developers tend to put the problem first and the solution afterwards and it's quite hard to put aside that mindset when talking to stakeholders. Even Elon Musk finds this hard to do when talking to the press. It's quite funny to hear him talking about all of a Tesla's inefficiencies while trying to sell it!

Also be patient. Your manager actually needs to be convinced of what you're saying; he can't just take your word for it. So if you see an example of how your solution would have prevented a problem that just had to be dealt with, point it out. Take him on a journey, to use an old cliché.


This doesn't work if you need help and resources to find solutions to said problems. You cannot solve everyone else's problems and implement solutions for them. You can suggest solutions, but someone has to give the okay and devote the time to implementation. If every problem you see requires you to submit a lengthy solutions proposal to the people who should be solving it themselves, you'll get burned out.


No, but you can solve the problems you can solve. That will give you currency to buy respect, trust, and responsibility.

I'm not suggesting you shouldn't do anything without getting permission first, but for the things you do need permission for, the above advice might help.


Do you really want to use that currency to buy, trust respect, and responsibility for things outside your job description?

You have to watch out that a "go getter" attitude doesn't result in you just getting overburdened.


> which they are in their full right to do

They seem to be scamming the shareholders diverting money from productive investment into their self worth. It's not your problem, but it's not in their full right to do either.


I do not believe they have shareholders. Afaik, the company business model is around providing tech services for humanitarian aid institutions and at least some revenue comes from that type of donor funding


If they don't have money for buying proper productive equipment, but spend what they have in unproductive ostentatious stuff for management, they are very likely defrauding somebody. It may be shareholders, donors, tax-payers, or somebody else, but they are hurting somebody.

It is also almost certainly not the employees (unless it's a cooperative).


That sucks. Posting on Glassdoor could help, unless you risk your position before you have a new one with too much identifiable information. Definitely post after.


I have worked on my own laptop for a while (due to startup lack of money, it was either wage or the laptop at some point due to liquidity issues), with one point made to my employer: All copyright on work done on my laptop belongs to me, and only me. You can 'rent' it by paying me my wage but as soon as I leave, all code on it is mine and I'm taking it with me for future 'reference'. Don't know how this works legally but since I'm not a self employed person who has a business contract, I'm pretty sure you cannot legally force someone to use their own stuff without compensation.

I told them they could pay me a compensation (for using/bringing my own tools) but that is quite expensive since most deductions don't count for this. Even more expensive than buying a proper laptop. Quite quickly I got a proper company laptop after finances improved to resolve the issue.

On another note:

In my experience the term 'middle management' is a synonym for corrupt, useless idiots so getting rid of them saves huge amounts of money since they add no value to any product or to the company as a whole. Unfortunately there is no way to even moderately grow within most companies around here except for a management track which is idiotic since specialists are way more valuable to the gross product of the company.

and: Never underestimate the value of skilled workers and how to keep them or train them. In software they are your main business. Everything else is easily replaceable.


All copyright on work done on my laptop belongs to me, and only me. You can 'rent' it by paying me my wage but as soon as I leave, all code on it is mine and I'm taking it with me for future 'reference'. Don't know how this works legally but since I'm not a self employed person who has a business contract, I'm pretty sure you cannot legally force someone to use their own stuff without compensation.

In the US at least, any work you do for an employer and get paid for is covered under what are called work-for-hire laws which assign the copyright to the company, unless you have a written contract stating otherwise. This is true regardless of what equipment you use, and there’s absolutely zero legal barrier to a company asking you to use your own equipment in the course of a job without any compensation. The fact that your ultimatum wasn’t met with a “lol no” from Legal is pure luck.


Why are the people who are so cocksure always the ones who know the least? “I’ve (incorrectly) interpreted copyright law, and I admit I don’t know how the law works, but I’m pretty sure I’m right.”



They don't think the rules apply to them, so they don't care what the rules are.


>I'm pretty sure you cannot legally force someone to use their own stuff without compensation.

That's the norm in some professions. Welders and mechanics often have their own tools, which can cost a lot more than a laptop.


What kind of dev job are you looking for? The company I work for is hiring.


Cup of tea or coffee?


Sure why not, i’ll drop you an e-mail


The problem I've seen with mentoring, in practice, is the 1 in 3 juniors that takes up all the time. Maybe the particular job doesn't suit them. Maybe they shouldn't be a dev. Maybe it's personality.

Some managers, mentors or such seem to deal with this well. But, in the cases that I've seen having an employee that is not producing value is stressful and time consuming. Largely, it's driven by empathy. You don't want them to get fired, or embarrassed.

Anyway, the person taking up most mentoring time (including:'leave this part, I'll fix it) is also producing the least of the least important stuff. The best juniors can be left to their devices and everything is ok, but basically the time and effort allocation becomes very inefficient.

Mentoring is important, but I disagree with you somewhat. Software is just an ADD industry. Everything is fast. You hire for needs in the next 12 months. Junior devs (all devs, some places) average short stints.

Anyway, mentiring, training and such are long term investments. Makes less sense in industry segments that think in shorter horizons and treat everything from office space to employees or even products as 1-2 year solutions. Entire companies are built around 3-6 year horizons from cenception to exit.

I see this as a byproduct of product development time. MVP and its associated stuff... It's all about short horizons, clean slates and short term planning. Nothing is free and the cost of this is anything that's part of long term strategy, like hiring and training for long term benefit.


> You hire for needs in the next 12 months.

That's like, your opinion, man. Why can't you hire long-term? If all you plan for is short-term, it will only work short-term, and it should be no surprise if on the longer term you fail or you find yourself in a world of pain.

> I see this as a byproduct of product development time. MVP and its associated stuff... It's all about short horizons,

I think you severely misunderstand MVP... it's not at all about short horizons, on the contrary. It's about doing the right thing in the longer term. To put "MVP" in a hiring context - the right "MVP" attitude is to hire temporarily to see whether the person is right for the job - and once you determine you've got a good fit, invest massively in that person to make sure you've got a long-term employee (don't just skim him/her for short-term profit, but invest to build a long-lasting relationship).

> Entire companies are built around 3-6 year horizons from cenception to exit.

I've yet to see that work (and not in the sense that "lottery works" - nobody seriously suggests buying lots of lottery tickets if you want to get rich.


..if all you plan for is short-term, it will only work short-term..

My point exactly, only in reverse. In industries (eg, merchant banking, corporate law, industrial engineering) where the plans are longer term, the thinking is longer term. Here you see highly involved onboarding programs with mentorship, in depth training and such.

Uber, FB, snapchat, netflix or whatnot never had plans that really looked past 2-3 years into the future. Ambitions, possibly. That's different to plans. These are on the young/ADD end of the spectrum, but they have cultural influence industry-wide.

I disagree about MVP. First, I don't think short horizon is bad, it's choice with advantages and disadvantages. Second, I do think MVP is part of a wider, shorter horizon planning mentality. That has certainly been my experience. The idea (IMO) is that instead of planning, you evolve. Evolution and planning are at odds with eachother, to an extent. You can make decisions early, and you get a longer term plan to work with. You can make decisions just-in-time (eg after launching an MVP), this gets you more informed decisions. That's not necessarily related to HR. You're hiring and onboarding could be unrelated to your product and engineering plans (or lack thereof). But (again, in practice), I think that mentality is influenced by these things.

^That's like, your opinion, man. ...always ;)

"I've yet to see that work" ... Uber. Netflix' streaming service.... for large, famous examples. Call those lotteries if you want. They're definitely risky. You may not like high risk strategies but they are a big part of the software industry, especially on the culturally influential wing.


> In industries (eg, merchant banking, corporate law, industrial engineering) where the plans are longer term, the thinking is longer term

I work in banking at the moment, and the thinking is anything but longer term. Management is so desperate to hire enough qualified developers that it fills a lot of the vacancies with contractors, which are, by company's definition, temporary. So, in other words, the company is already planning to let go of people who will build its vital systems. That's myopic thinking at its finest.

What's interesting is that big part of enterprise market in, for example, London seems to operate like that - management pretends that people are replaceable cogs that hold no company-specific knowledge and require no ramp-up time. The stupidity of it is mind-boggling.


> Uber. Netflix' streaming service

I really don't think that Uber and Netflix hired for the short term. Especially Netflix. How did you get that? Netflix in particular seems to have been playing the long game for quite a while.


Netflix has an unusual hr history, worth looking up if you're interested in that sort of thing.


To be fair to the parent commenter, I think the short time horizons are based on how startups are funded. We get 12-18 months funding per round. Everything starts from that - planning, etc. If you work at a large enterprise, then interns have a different role - normally it's more like a long interview process. But for startups, I don't agree with it, but I understand why there is little mentoring.


> Why can't you hire long-term?

You can, but I have never been offered a multi-year employment contract. Employers seem to prefer the flexibility of being able to terminate employment sooner than that.


If someone is on a permanent contract then their employment cannot simply be terminated ever. They can be made redundant, which means that the role cannot be refilled, or they can be fired but only after going through a disciplinary procedure (In the UK these rules only comes into effect after the first 2 years of employment).


So charge the self employed contractor rates then


In my opinion, attitudes similar to yours are toxic to this industry.

I've been working >10 years as a software engineer. If I'd never worked on a (necessarily) complicated system(s), I could maybe understand your viewpoint. Churning out the same CRUD app with minor differences would probably be safe enough to expect a junior dev to 'have at it'.

> Everything is fast

Unfortunately, this is the current 'thinking' on how some un-enlightened people think the industry should work. Ultimately, I think this is a load of nonsense. Software engineering is engineering. Some people may have snuck in & survived as they never had to do something non trivial & deal with the resulting consequences.


Where did I say that?! I never said junior devs should work independently.

Anyway ,it's not about how people think the industry should work it's about how it does work. This is a fast industry, irl. People change jobs more frequently. Companies grow faster. Products go from conception to release faster. Financial horizons are shorter.

A big chunk of the 2018 industry did not exist in 2008. Mobile, for example. Not the companies, not the specializations. It's not philosophy. It's reality. I'm talking about side effects of this reality.

No one at Snapchat thinks "we'll hire this kid, he'll make a great engineering manager in 15 years." They do in some industries. We're on the other end of the spectrum.


If 1/3 of you developers are eating all of your mentoring time I would think that either you've made a hiring mistake, or lack appropriate teaching tools.

In one case you've hired someone who isn't ready to do the tasks you need without excessive scaffolding. In the other you're not providing enough structure and scaffolding for the intern to succeed with help.

Mentoring, particularly in the legal context of what makes an intern, an intern and not a Jr. Developer ought to be a short run project, and frankly if you can't commit time to providing an educational experience you shouldn't be filling your staffing needs with an intern at all.


This has happened to me, but what it exposed was the hiring process gave absolutely no indication of whether the person could code. The 3 juniors assigned to me were interviewed by the VP, and I under him had no say or insight into the hiring process. 2 of them did super well and are now senior devs. One of them took up 30-40% of my time (with my putting up boundaries) and the basic understanding of the platform we were using never clicked for him.

The thing is - they got 2 very driven loyal devs out of it, and cheaper than normal at first. They also had an assessment period of 3 months after which the one who would take up all my time was let go. It was absolutely worth it for the company.


Sounds like senior devs who can't even do teamwork. At my job I'm a junior and guess what I can ask a senior for help cause if my job fails they also fail because oh guess what? Its a team and we are all on the same boat and wait it gets better!

I end up spending my own time helping out senior developers in places they get stuck! (Inconceivable!) Yeah sounds like a management team and a bunch of senior devs who have no concept of a team to me?... Which makes them no-hire types at my job. I help people regardless of what they're working on. If any of us fails it affects all of us in the long run.

I love programming and helping others achieve it and working with others to learn is one of the better and more fun parts of it.


When I was a jr I could not understand how other engineers, jr or especially sr, did not share this passion for helping and learning. Over the years (decades now) I came to accept that even in software development there are all these different types of people.

I learned to not get upset by it but still help/share, trying to inspire others and always learning more in this process.


On the other hand, you have the schmucks that ask the same questions over and iver, make the same mistakes, over and over, and are utterly helpless without their hand being held. It's a spectrum.

My suspicion is that anyone my age or older had to do a lot of banging their heads against the wall, alone in a room with the machine, when they were learning their craft. It becomes very tiresome dealing with people that don't even try to figure things out on their own first.


Completely agree, it should always be team first.


Now I will admit there are exceptions, if helping a junior (or senior : ) takes up your whole day (aside from just helping them get things up and running the first time) unless told to help them 'get it done' by upper management you might want to back off and let them get burned a little bit while you get your own work done.


That's still team first, tbh. Team over your teammate.


As a non-developer who works directly with devs, I've always thought this:

I've heard that being a dev is 90% thinking about code and 10% writing it.

In my experience you hire senior devs to do the thinking part and junior devs to do the writing part while learning how to do the thinking part.


The communication ends up being such a bottleneck that your senior devs might as well do the 10% writing. Incidentally also the reason why outsourcing software doesn't work if you're trying to do anything innovative.


Hiring devs to just think is part of what creates these convoluted mess of systems. It's impossible to convey and idea well enough that another person could implement it in the same fashion. Look at language specifications: they are written by top-tier developers, but when implemented by other equally top-tier developers, there is an inevitable difference of opinion.

Senior developers should be writing code for important systems, and juniors should be writing the less important bits. That way, they get the opportunity to experiment without the company being stuck with a critical system written by a person who reinvented Yet Another Elliptical Wheel.

Mentoring is important and all, but at some point, you just have to start working.


> good junior devs can code not only "just as fast", but probably faster too!

For at least 2 companies I've worked at, this is false. Junior devs cannot complete their work at all without help.

This may be the real problem: there is no way to learn the skills to do the job without actually getting a job first and learning the skills as you go.


But the ‘learning the skills as you go’ part is where the seniors come in. I’ve benefited immensely from the code reviews which took things that technically worked but we’re convoluted and transformed them into code that could be maintained and read easily.

Now that I’ve had some mentorship I can be productive on my own, but yeah, it took some work.

The senior devs get pulled into meetings, customer escalations, bug reviews, etc. all the time. The juniors, now trained and competent are free to code all day and get the work done because they have fewer responsibilities.

Yes, it takes work to get there, but it’s worth the effort.


This is where a high quality on-boarding program comes into play. Yes, a dev fresh out of college or code boot camp, with little or no real world experience, is going to be unproductive individually.

As the employer/manager, you need to work to minimize the period of time this is the case and ensure those junior devs quickly get to a point where they can work individually.

I mentioned it elsewhere in this discussion - we have a 1 month on-boarding program for new devs. They all arrive at the same time (summer after graduation), stay near HQ, and work through all the common training together (some tech, some culture, some "how to be an adult", etc). They also work through a simple, but in-depth (UI, API, build pipeline, etc), group project. And wrap up with a two day hackathon for fun (done in common with the summer interns).


Good junior devs are fairly rare, too - I wasn't claiming you find them everywhere.


> good junior devs can code not only "just as fast", but probably faster too!

Pfft. I'm about as "senior" as it gets and I'm generally the fastest developer in any team I'm on. I've never met a junior dev that could hold a candle to me, and most senior devs I know are the same...we're coding monsters.


Sr Dev with 26 years of experience. I get my edge not by coding fast. I maximize the amount of work that we don't have to do.

- Better (usually simpler) designs.

- Breaking the problem and choosing the order in which things are implemented.

- Setting up usefull feedback loops.

- etc, etc.

It is a lot about judgment.


A deep understanding of your tool set is a huge advantage.


That is "coding fast". Coding fast doesn't mean literally churning out a lot of code and pull requests.


Managers often have trouble recognizing the difference, though. Even if they know the difference, measuring actual productivity is difficult and subjective, measuring number of pull requests or number of JIRA tickets closed is easy and objective.


> easy and objective.

that’s the worst kind of data - gives a meaningless feeling of objectivity.


Dunning-Kruger called, they want their overblown ego steamroller back.


People get better with practice. So, yes senior developers tend to be significantly faster coders. It's not that they do everything faster, but by getting better at the hard parts they finish complex tasks vastly more quickly.

PS: Most people have never worked closely with someone with 25+ years of experience, but the difference is staggering.


Well, I am someone with 25 years of experience, does that count as "worked closely with"?

Good junior devs are... well, by definition, good. They're just younger, and less experienced - but every bit as smart as you are, and pretty skilled in the art of coding. If anything, they have more time than I do and are a lot more eager to "prove themselves".

I don't view the value I add as "can code features faster"...


Good junior devs can also have 15+ years of non professional experience from starting as a kid. It's a wide enough bucket that talking about just the top end is very misleading, however the median jr dev is relatively slow and bug prone.


If they have not done any real coding before going to uni I could understand - this BTW is what the raspberry pi was originally created for.


> I don't view the value I add as "can code features faster"

I do, at least partly. I can code so much faster that my cost per feature is lower than a junior dev.


Your cost is less by being paid more? Seems legit


His projects are most likely successful and profitable. The junior devs is probably a comparative catastrophe. I honestly don't get where this junior devs are faster meme is coming from, it sure doesn't represent my experience.


My cost is less by doing more in the same amount of time.


Which is offset by the fact that you're paid significantly more


The point you keep missing is that the amount I'm paid more isn't equivalent to the amount more I can do than a junior dev. I perform at some X more than the junior dev, but I'm not paid X more.


It's good to know you have such a high view of yourself in comparison to others


It's not my view, it's my manager's view, as well as simple math.


I have.

It was staggering how they had managed to survive for 25+ years. Every person is different.


He may have been far worse 25 years ago. ¯\_(ツ)_/¯

Having not worked with the same person for 25 years I can only speak of the average case.


I can point to my well documented track record: code reviews, bonuses, promotions, code longevity, metrics, etc. as evidence. I can code multiple features in the time that a junior dev does one, even with me mentoring them. That doesn't mean they're bad, or even worse than average. It just means that after a career spent honing my craft, I'm much better than average.


I wasn't questioning your seniority.

I pointed out how you decided to pick out a totally irrelevant, rhetorical sentence out of all points that OP made, and then decided to refute that, by claiming how much experience you have, and setting up yourself center stage, instead of adding value to the actual discussion topic at hand, which is the coaching gap.


I directly disputed the central thesis that OP (the person I was responding to, not the article) was putting forth, that senior developers shouldn't be coding:

> You don't hire senior devs to code - good junior devs can code not only "just as fast", but probably faster too!

> "Mentoring" is basically the job you hire a senior dev to do

What other "points" did OP make?


Your reading comprehension suffers under your fragile ego. Nobody said 'senior developers shouldn't be coding'.

The topic is about a lack of mentoring for junior devs. You being a certified 100x rockstar developer is totally fine but irrelevant, because you don't scale.

What would scale is if you were to start coaching junior devs, because if you don't, all the juniors will keep reinventing 'left-pad' in this week's ES201x iteration, while your retirement keeps getting closer.

Instead of adding to the discussion on how to solve the coaching gap, you decided to defend your coding efficiency and how you deliver features faster than a Junior Dev. You missed the point completely. You're part of the problem the article addresses, don't you realize?


> Your reading comprehension suffers under your fragile ego. Nobody said 'senior developers shouldn't be coding'.

That is exactly what the post I was responding to said, and I've quoted it several times. Here it is a gain, since you keep glossing over it:

> You don't hire senior devs to code - good junior devs can code not only "just as fast", but probably faster too!

> "Mentoring" is basically the job you hire a senior dev to do

So, yes, the person I responded to said "senior developers shouldn't be coding'".

> You being a certified 100x rockstar developer is totally fine but irrelevant, because you don't scale.

How so? I'm a mentor as well as a developer. In addition to doing my part to train the next wave of devs, I also code my ass off. What part of that doesn't scale?

> You missed the point completely.

No. That's what you did though. And are increasingly insulting about it as well.

> You're part of the problem the article addresses, don't you realize?

Who's talking about the article? I was talking about the bogus "point" in the post I responded to.


For what it’s worth I agree with the person you’re replying to. The OP is saying: given two senior applicants with the same coding skill level, the one most suited to the job is the person who can communicate to juniors and delegate effectively.

I’m surprised you mentor, given all the hubris you have displyed on this thread.


> The OP is saying: given two senior applicants with the same coding skill level, the one most suited to the job is the person who can communicate to juniors and delegate effectively.

If that's what he was saying, I'd be much more in agreement. Instead he said, effectively, that senior devs shouldn't be coding because they can't do it any better than junior devs.


No. Read it again. What I was saying is two things:

A. GOOD junior devs can (and often do) outperform good senior devs at the metric of "quantity of code produced" (I later added that IMO in fact they should, not just can)

B. (the central point of my argument, really) If you're working on the premise "we can’t afford to have our senior developers mentor juniors" , you're misusing the senior devs. It's not just cost-ineffective (you're paying a senior do to a junior's work), but you also run into other risks as well (juniors that ask questions force seniors to explain stuff, which in turn forces them to think clearly about it; you may have experienced the phenomenon where you understand something much better after explaining it to somebody else)


And I'm saying that your arguments are wrong. I don't care how good the junior dev is, I can out code them every time.

> If you're working on the premise "we can’t afford to have our senior developers mentor juniors" , you're misusing the senior devs.

Actually, no argument there. Mentoring is indeed a critical function of senior devs.

> It's not just cost-ineffective (you're paying a senior do to a junior's work)

And you lost me there. I'm so much more effective that it's always cheaper to have me do it, assuming I don't have a higher priority task (in which case it's a non-issue, since I'm working on that one). I.E. I'm a 10x (or 100x) developer, but I don't get paid 10x (or 100x).


Look. Aren't you spending time thinking? Do you imagine you think faster than everybody aged 23?

Could you do an MSc at a top-level US university (in your primary domain of expertise) in a week? Because plenty of people (juniors by definition, almost all of them) can do it in 2 years, so if you're "100x" in the sense that you say you are, you should be able to do all that work in 1 week. At least that much should be plainly obvious to you, that you can't possibly be "100x" in the sense that you claim to be. Or well, if you are... you're rather unique, I definitely haven't seen anybody that can even come close to you, and I know some top-notch engineers. So you're definitely the exception, not the rule.


> Aren't you spending time thinking? Do you imagine you think faster than everybody aged 23?

No, but I probably think better...i.e. how to approach a problem, sift out the relevant details, formulate a plan, execute it, understand the trade-offs, etc. As a result, I can deliver more correct code faster than a junior dev.

> you can't possibly be "100x" in the sense that you claim to be.

I never claimed to be 100x. I was just mentioning the reason why I'm cheaper than a junior dev (that I'm not paid in line with my "effectiveness multiplier"). You were the one that mentioned a 100x engineer thing in a link, so I included the number.


> I never claimed to be 100x.

You actually did - look 2 posts up, "i.e. I'm a 10x (100x) dev". But I suspect you didn't actually read that link, just the URL - not fair to chide me for mentioning the number if you didn't read what that meant.

> how to approach a problem, sift out the relevant details, formulate a plan, understand the trade-offs

That's exactly my claim, that you add more value with this sort of activity than the "execute it" part; doing that plus teaching others to do it, you add exponentially more value to the company, than just coding stuff in a corner .

You cling on the fact that a junior dev can't possibly code faster than you - even though it's a completely irrelevant detail. And yes they can, if you remove qualifications like "correct code" or "maintainable" or whatever (I never claimed junior devs will do the right thing all by themselves, that'd make them seniors, right? But - I participated in coding competitions in high-school, got a silver medal at IOI - I know very well that my younger self could code circles around my older self when it comes to raw speed. And I've seen other people like that later; experience can't fight youth when it comes to speed and enthusiasm... it just can't. It's more likely that you just never worked with a good junior dev before, than it is that you can always code everything faster).


Actually, the context that you're ignoring is important:

> I'm so much more effective that it's always cheaper to have me do it, assuming I don't have a higher priority task (in which case it's a non-issue, since I'm working on that one). I.E. I'm a 10x (or 100x) developer, but I don't get paid 10x (or 100x).

The numbers were merely to indicate that my multiplier is sufficient that I'm cheaper than a dev.

> I suspect you didn't actually read that link, just the URL - not fair to chide me for mentioning the number if you didn't read what that meant.

No need to suspect, I confirm I didn't read it. I saw the number in the URL and just dismissed it as puffery.

> That's exactly my claim, that you add more value with this sort of activity than the "execute it" part; doing that plus teaching others to do it, you add exponentially more value to the company, than just coding stuff in a corner .

That was in no way you're claim, at least, not the claim I disputed. Your claim(s) were:

> You don't hire senior devs to code - good junior devs can code not only "just as fast", but probably faster too!

> "Mentoring" is basically the job you hire a senior dev to do

No way. Maybe mentoring is a part of the job, but it's by no means the main job in many organizations.

> if you remove qualifications like "correct code" or "maintainable" or whatever

??? This is a pretty ludicrous statement. Why would you ever count incorrect code? And yes, I probably can code incorrectly faster than a junior dev, too. After decades of experience, I'm a faster typist than most junior devs.

> I know very well that my younger self could code circles around my older self when it comes to raw speed. And I've seen other people like that later; experience can't fight youth when it comes to speed and enthusiasm... it just can't.

Rose colored glasses, to say the least. You seem to be switching back and forth on whether raw LOC throughput is meaningful...first you were "flabbergasted" that it might be a measure of productivity, now you're bragging about raw speed, and even suggesting that creating "correct code" or "maintainable" code is irrelevant, which is insane.

> It's more likely that you just never worked with a good junior dev before, than it is that you can always code everything faster).

I've worked with (and mentored) some really great junior devs, who grew into great senior devs. But they didn't walk into the building as my equals in coding.


Education is a good point. New algorithms are often found in academia that aren't exactly on Hacker News all of the time. It doesn't matter which field either - micro architecture, high performance computing, UX, databases, PL, computational linguistics, you name it. Or hell, math has been around for a long time and you might not know planar graph algorithms off-hand unless you were really smart or had taken the course two months ago.

This whole debate is nutty. I personally would welcome as much strategic and intellectual diversity as possible onto teams I'm running. I wouldn't put all my eggs in one basket, either.


> I personally would welcome as much strategic and intellectual diversity as possible onto teams I'm running.

Me too. I just think the blanket assertion that a junior dev is the coding equal to a senior dev is what's nutty.


The Dunning-Kruger effect is a bias and as such deals with probabilities. It doesn't mean any given individual says they're the best (in their neck of the woods) at something is definitely wrong.


True. But the team as a whole would probably still achieve much more if you were mostly guiding other (less experienced) devs.


I do. But I'm still faster than them in head to head coding throughput (code produced, error counts, etc). I've got decades of experience in developing software. No way someone fresh out of college is going to equal, let alone out-code me. That's not to say they're not good, but the assertion:

> can code not only "just as fast", but probably faster too!

is pure BS.


I am flabbergasted that you're senior and measure your productivity in "code produced". What is that, LOC? Can type faster than a recent graduate?

Good junior devs will be more skilled in some areas than you are. Maybe it's stuff you're not interested in; or just stuff they're really interested in. The only way a good junior dev doesn't "out-code" you, ever - is if you're only skilled in a very narrow niche (bonus points if only few people are interested in it, at all).

Junior devs absolutely can, and often do, build "wrong things" faster than senior devs. The measure of seniority is in my mind about knowing what to NOT build, in the first place.


> I am flabbergasted that you're senior and measure your productivity in "code produced". What is that, LOC? Can type faster than a recent graduate?

Who uses LOC? I'm talking about completed, tested, accepted features, as defined by our project teams.

> Good junior devs will be more skilled in some areas than you are.

Well, yeah...of course. I'm not comparing myself to someone who works in an entirely different field. A junior front-end dev will be better than me at front-end stuff. I'm talking about a junior in my area, who I'd be in a team with or would mentor.

> The measure of seniority is in my mind about knowing what to NOT build, in the first place.

I agree with that statement.


> I'm talking about completed, tested, accepted features, as defined by our project teams.

Still rather strange metrics for productivity in a senior engineer. This is more what I'm taking about: https://zef.me/the-100x-engineer-6d50a690a866

If you're really senior, you shouldn't be working on the kind of features that get delivered at a rate of "5 per sprint". More like on stuff that gets delivered once every year. The junior SHOULD outperform you in "code produced" - they just shouldn't outperform you in dollars produced (or saved).


You do what your team and company needs. If they need me to work on a big re-engineering project, or build a core framework feature, I do it. If they need me to get onto a regular sprint team for a while and churn out the backlog, I do it.


I believe it. Though my experience is that junior devs can be much faster at producing lines of code, and most of it's junk. Senior devs will always be faster at producing bug free lines of code, and certainly at catching more of the edge cases. Moreover, the best devs I've worked with know when not to code at all to solve a problem, which is a totally foreign concept to junior devs who seem to prefer coding to thinking.

When I look at code written by junior devs I often think 'dear god, how is there so much code that does nothing, and how did it all get witten since I last had a chance to look'.

Makes me wonder if there are parallels in writing. My understanding is that the most prolific authors can only write 8 publishable pages a day. I'd bet that amateur writers can produce more pages than that, but no page could be published without at least as much time spent by an editor.


> dear god, how is there so much code that does nothing, and how did it all get witten since I last had a chance to look

This, 100 times over! It is simply incredible how much code and how complex systems a junior dev (junior by knowledge, not by years of coding) can produce in a short time while you were looking the other way... :-D


> I'm about as "senior" as it gets

Senior developers make sure to question their assumptions on a regular basis, FYI


What about cross-discipline? What if a problem comes up that would be better solved with technology Y instead of X and you are an X master but random intern happens to know Y. Are you still the fastest? What if the intern is better at making slides for code reviews that show important trends? Or they can write fantastic documentation? Or tools?

I'm sure you're a quick learner but at least in scenarios I've worked in there are often many, many possible solutions and no specific "right answer."

After all, it's hard for anyone to be right all of the time.


None of that has anything to do with the original blanket assertion of "good junior devs can code not only "just as fast", but probably faster too!".


Aye, but you probably can't code faster if you have to read a manual first? It is easy to construct scenarios where someone from a bootcamp could code "faster" than a principal, senior lead, or CTO of all things. It's just a matter of picking the problem.

A better point is that this drought of new talent is just the other side of the pendulum. In the odd years, the problem is layoffs and difficulty finding work without being a new-grad or knowing the latest tech fad. You've seen some of those summers, too?


> Aye, but you probably can't code faster if you have to read a manual first?

If we both had to read the manual? Yeah, I'd still be faster. It's just as easy to cherry-pick for one side or another.


The general point he makes is that "if I define what speed means, I always code faster", so yeah, he's right. Sort of :)


Welp, get back to me when you're 50 Mr. Senior and we'll see how you fared over the long haul. Because "coding monster" or not, when you hit 40, companies will be less enthusiastic about hiring you, and by the time you're 50, you'll be out, so I hope you're making bank right now and saving as much of it as you possibly can because there are no do-overs.


Really? I'm 54, and constantly have to turn away recruiters who pester me. Long haul is looking pretty good, right now anyway. Even if you're a junior dev, outlooks can change and shift...it's all about staying relevant and proving your worth.


I agree with you and this is the thing that gets lost on both sides. How fast you type and how many lines of code you write and test per day aren't the right metrics. It is about adding value, it isn't an assembly line. There is a major problem with middle/upper management understanding this. However, there is also a large group of people who view themselves as top developers who talk about having too many distractions and wanting a private office so they can lay down a lot of code each day. I'm not saying that isn't how some might be able to add the most value but code/day doesn't guarantee that maximum. Mentoring team members, documenting architecture, building automated tests, talking to customers, etc. will very likely yield more value in everything but the very near term.

All this to say that we need to be careful that we don't point the finger too hard at management and miss our own failings. Software done well is incredibly hard and increasingly complex. Focusing on adding value and not on code/day can help us all stay focused on the real goal and what is best for us and the company and the customers. </r>


> You hire senior devs to guide you WHAT and HOW to code.

Every organization I've worked at (for the past 25 years) has relegated that rule to the much lower prestige, much lower paying, zero career path role of either "business analyst" or "project manager". If you can produce code, you'll be producing code - and by and large, that's the only way to have anything resembling a future unless you're on an upper management track.


A lot of shops view senior devs as the people who write more, better, faster code. Not the people who think about what and how. That's for architectural councils, which meet in misty glades in dark robes at midnight or something.


> You don't hire senior devs to code - good junior devs can code not only "just as fast", but probably faster too!

I think this is a stereotype that will lead to more harm than good. What if a junior dev doesn't code just as fast or faster? Does that mean we hired the wrong junior dev? I agree we can should be open to junior developers, just implanting this stereotype is harmful


I'm not sure what juniors you talk about, but most juniors I've met can code "barely enough", get stuck often and code pretty bad so the pull request will stay there for quite a while before all corrections are applied


Actually, the cost of mentoring is not necessarily only cost of lost productivity. Sometimes (I hope, more likely mostly) there are pieces of old, arcane, barely and wrongly documented pieces of codebase that there is exactly one senior in the company who knows how it works. Assigning said senior from coding literally means pushing deadlines. So it is kind of tragedy of the commons.


That's like, a great motivation to assign said senior AWAY from coding! "Single points of failures" are your greatest enemy, your senior my get a better offer. Or might get sick. Or might get in a car accident. Why would you want to bet your entire company on a single person? I mean... sometimes you have to do it because there's no other way, but it's a big warning sign, and you should diligently work to get out of that situation ASAP. "Pushing deadlines" might very well be a price worth paying in a situation like that.


One of the good reasons to have junior devs around is that (if they're motivated) they'll find holes in the documentation and help prevent this. I usually write many pages of text to document problems and unwritten ideas at my internships.


This is probably the biggest difference between companies who excel and those who don't. Some companies get that employees are assets and training them is worth it even if they might leave.


There were never any junior dev jobs. You have always had to lie, cheat, and steal your way into the field. I have a buddy who legit cheated his way to the top Magento certification and now cycles through $150k+ jobs where they keep him on long enough to realize he doesn't have any coding skills then they fire him.

Reason is software is always an ancillary concern to the business. You see this in other fields, like say accounting, but the difference is that accountants leave school fully capable of employment. HR understands how to hire and manage accountants.

But programming is this black box in the corporate world that no one knows how to understand, value, or hire for. This is why every company wants rockstars, they're hoping that someone whose at least confident to present themselves as a rockstar won't be a net negative to the company.

Eventually they'll figure it out, took them a decade to figure out how to manage IT. Then companies will learn that they can't skimp on middle management for software developers. Some companies will need to give software a legit seat at the table and hire upper management. The political cover will allow shops to stabilize and with stabilization, you'll finally start seeing small and midsize organizations open up positions for juniors.

But it'll never happen so long as companies don't take software development seriously by giving them political cover. If you are a software developer nearing the middle or end of your career, you're pulling the ladder up behind you if you don't seriously consider moving into management. It's too important a job to ignore to go chase your dreams.


My "standard" team typically has two jr engineers, and two Sr engineers. When we hire Sr engineers we hire people that like to mentor others and see it as part of being Sr. Jr engineers know that in order to become Sr one of the skills they need to master is mentoring.

This is 100% a management issue, and it starts at the hiring filter.

Hiring Jrs btw is its own skill as you are filtering for potential not skill or knowledge. Identifying the person who is passionate about learning, has dedication to the craft and pride in their work, and has a natural talent for software is hard. Figure it out though and you have a competitive advantage for life as a manager.

Also, half of the Jrs we hire are women. We could never do that if we only hired experienced talent. Not enough women even apply for those roles.


I'll see your management issue and raise you a leadership one.

At my last job, a $40MM cosmetics and skincare company, the CEO had a great deal of trouble figuring out how to get his e-commerce department properly managed. I was willing to step up, and for a brief time they allowed me to bring in candidates for a position that would report to me, but I didn't have enough political cover over me so that fizzled out.

I cycled through 3 managers in 2 1/2 years at that job, 2 in the "Director of E-Commerce" role, and one in the "VP of E-Commerce" role. All three left for more sane roles.

It's hard to fix management problems at your company when leadership is so confused.


I never thought about it, but "IT / development is crap in legacy industries" follows as a tautology from your perspective.

If the only way to effectively perform the job (in the broader, department sense) is with political cover.

And if political cover is only apportioned in a zero-sum game of high level positions.

And if there are legacy industries in which those positions are, and have been for decades, apportioned to predefined departments (notably standardized before the information revolution).

Then those legacy industries are going to have insufficient political cover over IT/development. And therefore terrible performance.

My current employer recently had a security epiphany, and they definitely empowered a reorganized security department to make necessary changes. But I'm sure there were many points where "VP of X" could have squashed a necessary security change, had security not been of equal seniority.


E-commerce is unique in that it has such a massive impact on revenue generation, but the skills needed to effectively manage it are rarely inline with the core competencies of the business.

Most companies attempt to tackle this problem in house, but without proper expertise, there is massive waste in hiring and poor execution. As a consultant, I’ve seen teams waste _years_ fumbling in this cycle, only for me to ship a product that immediately increases revenue in a fraction of the time. It generally only takes a few basic UI improvements and timing strategic automatic email tiggers.

Find a consultant that will make more from what you already have, and move on to your business problems. You don’t need to pivot into an internet company to be successful.


Hm. I get what you're saying, but I think the three managers they had in my tenure were pretty good in that regard. The team was just me and a front-end guy, and we had no problem keeping up with the workload.

My impression was that we'd squeezed all the blood we could out of the stone, yet the CEO wasn't going to accept "focus on other business problems" as an answer.

Eventually my pleas were heard and they consulted out a new platform. They didn't pick a platform that I wanted to administer, so I moved on. The fourth manager they hired after I left did not appear to have made any purchase on the problem the last time I talked to her.

I naively thought the problem was technology, but the real problem was the expectations of the CEO. There was nothing I could do about it, of course, so it worked out for the best.


That is because business regards its technical staff "in comtempt" and that is a direct quote from one of my previous bosses (a director at on of the largest publishers in the world)


"We keep our developers away from sales teams as they tend to be dreamkillers."

A client one time told me in the past. At the time, I wanted to ask, "so, how badly are you treating them?"


I've seen the same issue, only they never tried it in house. Instead they spent a million or so over 5 years with different consultants who all did an extremely poor job and each time through out previous work and requirements.

This problem isn't unique to in house teams. It's hard to find and motivate competent people whether salaried or consulting.


Well put.

Do you still do consulting?

Please reach me at brandon {at} brandonreiss {dot} com to explore an opportunity with a small e-commerce retailer/wholesaler.


This is absolutely true. Ive been lucky that the last 17 years of my career have been spent reporting to the CEO and have had a large amount of leeway in my position. That's not always the case and a bad leadership team can't create a good culture.


I should have made a case for reporting to the CEO myself. None of the three managers could figure out how to do it, and I spent more time than I should have trying to coach them on how to handle him. But I wanted to be comfortable and reporting to the CEO would have been the opposite of that.


I am philosophically similar, although I generally hire at a 2 to 1 ratio, senior to junior.

I've found that I'm (as in, the boss guy) the most common blockade to ensuring that mentorship is productive and not disruptive. A 2 to 1 hiring ratio is playing the same game you are but on "Easy" instead of "Normal". So :thumbsup: on maintaining a 1 to 1 ratio.

Regarding how this relates to hiring women -- it's not just women. It has been a general diversity boon to teams where I've employed this practice, increasing diversity not just in the "affirmative action" groups (not to diminish the importance of that) but also in programmer background. I've had junior engineers bring insights far outside my sphere simply because they were previously (e.g.) a copywriter.


As a woman currently applying/interviewing for a new grad role, I think you're definitely right about most companies caring only about current knowledge/skill.


Why is that bad? Jobs should be filled based on skill/knowledge. (The ability to learn is a skill too, one that means what you know currently matters less). I take slight offence to your statement. Why is being a woman relevant to anything, unless your company is going for 50/50 male female. But in my opinion that is wrong, and amounts to sex discrimination against men, because if 50% of roles are filled by men, even if there is a better male candidate, then the female will get the role. (And vice versa, but that is generally not the case in my experience). This is wrong. It's about what the person can do, not evening numbers. Sex discrimination gone mad!


This is just the current zeitgeist we live in right now. In my prior career as an electrician, I didn't see any of this brought up by my employer/industry, but now that I'm a software developer, I see it all the time. I think that might be because the work of an electrician is more physical and labor-intensive, and therefore not very enticing to a lot of women looking to enter the workforce.


I think that a women quota is useful in cases where the proportion of female (one could also insert specific cultural backgrounds here) possible applicants for a role (be it junior or leader) is much higher than the proportion in the actual role. For instance, in theatres or hospitals in Germany, a large part of the employees is female whilst the bosses tend to be male. You cannot argue with "but better candidates will be turned down just because they are male" because obviously, the criteria for choosing are heavily unbalanced already. It's harder to determine whether a quota is useful in jobs the reason for not choosing women might be women not applying for the job. But we won't solve the matter by hating each other over the cause. Let's try to be critical, yet empathic.


The very existence of a quota is sex discrimination against both men and women.


It is. Sex discrimination gone mad. All rich industries have it, IT was the latest bastion to conquer. Please join a group for men’s rights, we only get nothing because men never dare to stand up as a gender.


Building diversity is an important component of forward progress, since it engenders a broader experiential pool to draw from.

In the case of gender, female developers have been shut out of the industry for long enough that corrective action has to be taken to balance the scales. Until such time as that happens, "sex discrimination against men" is impossible.


>Building diversity is an important component of forward progress, since it engenders a broader experiential pool to draw from.

Only the pool has to be created in the lower levels (education etc) not imposed at the company level with less good candidates favored just because of their sex.

>Until such time as that happens, "sex discrimination against men" is impossible.

It's very possible, if meritocracy is sidestepped, and the person who gets sidestepped is a man in favor of e.g. 50-50 parity with a woman.

Unless the pool entering the workforce is 50-50 already, then 50-50 hiring requires discrimination.


Gender is only one factor. It's what I focused on here because of context. Nationality, native language, childhood population density, and even hobby choices all play a part in experiential makeup.

"Meritocracy" is almost always a flawed idea, because it relies on the principle of those in positions of authority choosing the best candidate for a given role; the key word here is "best." That's a subjective term, and usually favors a small set of criteria over a more holistic view. People, with some exceptions, are bad at seeing the big picture.

With very few exceptions, I will always favor candidates with broader experience over those with narrow strengths.


>"Meritocracy" is almost always a flawed idea, because it relies on the principle of those in positions of authority choosing the best candidate for a given role; the key word here is "best." That's a subjective term, and usually favors a small set of criteria over a more holistic view.

That's the whole idea. When you need a surgeon you don't need a specifically sexed, or colored, or whatever surgeon. You just need a person good at the "small set of criteria" of performing a surgery.


I completely disagree for reasons I already said above. Meritocracy is the basis of life. Including evolution. Men are better at some things and women are better at some things. And you know what? That's fine by me.

Eg. Imagine if I was at the top of a burning building and my family needed rescued. I would want 5 men to try to save us, not 5 women. Does that make be sexist or normal minded?

EDIT: and off course vice versa for tasks that women are best suited.


It is still descrimination.

"Discrimination: the act, practice, or an instance of discriminating categorically rather than individually" - Merriam Webster Dictionary

Please don't bend what the word means just because others do. If we have our own meanings for every word, than the words mean nothing.


Fair enough.

But it's discrimination with a higher purpose.


I'd like to share a perspective based on an anecdote. The first company that I'd worked for had come to our college to hire interns. They wanted 2. I'd find out later that the CEO had intended one male hire and one female hire, but they ended up hiring 3 (all men) including me. Two of us that got hired were from financially poor background, had lived in tier 3 cities, went to underfunded-corrupt schools with bad educators (as was common in the region we were from), had taken out huge education loans and were possibly the only source of retirement income for our parents (I'm based out of India, poor people have to rely on their children's success here). There were around 10-15 women in our batch. Most were from well off families, had well-educated parents who were also bankrolling their daughters' education, were from tier-1 cities and were exposed to tech long before us. They'd had better opportunities for growth even before joining college and only equal opportunities after, like the rest of us. In retrospect I feel that I had been lucky in a certain sense. Thankfully the recruiters weren't people with the >`But it's discrimination with a higher purpose.` mindset. It would've been a very difficult road to recovery for me otherwise.

I would urge you to reconsider the notion that affirmative action is a sustainable solution for anything. It's hack. You only need to look at the current state of India's government, which over the course of more than 50 years of affirmative action (and other varying factors) has managed to convert the government sector into a cesspool of corruption and bad management.


>You only need to look at the current state of India's government, which over the course of more than 50 years of affirmative action (and other varying factors) has managed to convert the government sector into a cesspool of corruption and bad management.

This seems to imply that India's government fifty years ago was NOT full of corruption and bad management. The Raj was definitely corrupt but I know little about the two decades after India got its independence - were things really that good fifty years ago? Or was it just that it was less obvious?


No, not implying that. I used `more than 50 years` as a range, as these policies were also proposed as part of the Raj's secession. The introduction of affirmative action wasn't a single event, but a growing set of reservations and quotas included in education, govt sector hiring and other places. Even today, the left leaning political parties use this topic as a leverage to increase their vote bank.


This is probably the most reasoned counterargument I've seen here.

I'm going to step away and do some more reading on the subject before responding. Since this thread will likely be stale by then, I'll put up a blog post or similar with my updated thoughts.


well said.


> Hiring Jrs btw is its own skill as you are filtering for potential not skill or knowledge. Identifying the person who is passionate about learning, has dedication to the craft and pride in their work

I think this is so true of software development roles, but doesn't it actually apply to every hire? unless you have a _very_ specific role with explicit skill set, senior roles need to be just as flexible and able to learn new things quickly.


How many women hired would be enough to satisfy those roles you mention?


> Also, half of the Jrs we hire are women. We could never do that if we only hired experienced talent. Not enough women even apply for those roles.

You're giving preferential treatment to your recruits on the basis of their gender?


No. However we get more applicants that are women for the Jr roles and our hiring criteria matches them roughly as often as it matches men. For the sr positions 80% or more of applicants are men which roughly translates into 80% or more of hires being men. Pretty easy to see the math there without having to introduce any sort of preferential treatment.


I'm not the person you're replying to, but I took it to mean that they end up hiring about half women for those roles, not that the explicitly seek them out.


It seems like men and women are applying to the junior roles in roughly equal proportion, while the applications to the senior roles might be more skewed to the tune of 80/20 or worse.

Just ball-parking numbers, but that's what I got from his post.


Then you will need two senior devs. This is because rockstar devs rarely want to mentor junior devs nor attend meetings. Most inventors are not professors.


Then they aren't a rockstar. And frankly, I've spent my career cleaning up the obfuscated, badly documented, untested code of "rockstar" devs.

The idea of a "rockstar" you seem to be referring to has, in my experience, been a dev who can go into a corner and pump out high volumes of code with little supervision or collaboration. That's great, except no one else can make sense of the code they pump out, so when it comes time for the next guy to add a feature to the rockstar's mess it takes 2 to 3 times as long as it should.

I've also had to clean up messes by rockstars who made unilateral decisions about incorporating new technologies into a product. Like building out a single part of the product in React with out asking anyone else. You see, the rockstar didn't like meetings and didn't want to make the case to the rest of the team for why we should all learn React and gradually switch over. Instead, he just stuck it into the code. So now, you have a couple of views built as React components, and the rest of the thing is in Backbone. No one else knows React or has time to learn it, cause we're blazing ahead really fast. They just get very confused when they have to change something in those components and it takes them forever. But the rockstar got to have his fun and play with new tech.

This conception of a "rockstar" isn't a great developer... it's a selfish, cocky developer. When you hear "rockstar" dev, you shouldn't hear great performer. You should think of Keith Moon trashing his hotel room and driving his car into the hotel pool.

A great dev knows the value of documenting their code and writing testable code. A great dev knows the value of taking the extra time to make code easily understood and easily modified -- that sweet spot between spaghetti and over engineering. A great dev loves to mentor junior devs, enjoys walking other devs through their code, is happy to discuss design decisions with the team, and willing to admit when maybe their idea isn't the best one.

A great dev doesn't think they are god's gift to code, they are humble enough to understand they are one part of a team. They put the team first and work hard to teach others what they know, while always remembering they don't know everything.


That's why I've always told people that I'm a "studio musician" developer. Not a rock star, but a competent professional the studio calls when they need to make a record.


That's what I'd been saying for a while -- the best devs are session musicians. They have enough all-around comoetence to deliver what is asked for for that particular recording.


Normaly session musicians are better than rock stars James Jameson (funk brothers) was a better bassist than Paul McCartney, and Paul would admit that.

I have worked with a Musician with Phd in music who taught him self coding after an accident broke all the bones in his feet (drink had been taken)

It was fun in the pub when some hit tracks came on he would say ah I think that's one of mine :-)


I LOVE THIS MORE THAN YOU COULD EVER BEGIN TO KNOW!


That's great. I like to say I'm a "master carpenter" for the same reason.


Near as I can tell, the term stems from the 80s computer gaming industry, in which the game studio heads got the idea to promote the individual developers by name as if they were rock stars, and oftentimes attempt to treat them to the "rock star lifestyle" (girls, parties, etc.) in order to keep their output from flagging. In those days, games were often written by teams as small as one, and no bigger than a handful -- and the studios themselves were often fly-by-night outfits whose idea of "product packaging" was a Ziploc bag to ship the disk and manual in.

Eventually in the 90s, some developers really took the rock star bit to heart and started plastering their own names all over their output (cf. "John Romero's Daikatana", "American McGee's Whatever-American-McGee-Is-Working-On-Now"), but for the most part, developers at the time hated the rock star characterization.


Electronic Arts started as an outfit for people like this, as did Activision. It's saddening to see how much their ethos has changed in the ensuing 30-40 years.


Sid Meier's Civilization!


A great dev gets out amongst his user community and finds out the real feelings of those who are using the software. The great dev tries to understand the actual user requirements (not just what has been supplied by the design docs). The great dev listens to the criticisms of the users and discusses what can and can't be done.

I don't disagree with your "great dev" qualities but there is more needed to make a "great dev". Otherwise all the documentation, code ease, mentoring, being a part of the team, etc. is not going to make the code useful to anyone.


The whole "rockstar dev" branding has always made me cringe, but my opinion is software should be made by rock bands. Sometimes you have to play bass and not get laid.


I like to go with master developer and not rockstar for the very reasons you state


Yup, I'll take Gadd over Moon any day.


First off I hate the phrase "Rockstar dev" because it gives the impression that someone can be successful without the support of the team, which is wrong.

Second, I hear this extremely often: Rockstar devs don't like to mentor, Rockstar devs don't like to write documentation, Rockstar devs don't like to write tests.

At what point do you need to reevaluate your definition of a rockstar dev?

The hiring filter is a powerful thing. It allows you to find very special people if you know how to look. It's also a feedback loop. Getting momentum with a program like this is the hardest part. Once it's going it practically self sustains. The biggest part of your role becomes quickly firing any mistakes.


Related to this: know what you're hiring for.

Are you looking for someone who can parachute in with expertise on a specific tech and churn out working code themselves?

Or are you willing to accept more lag time and less initial code productivity in exchange for a deeper bench and sustainable team?

There are times and places for both of these developer types...


You are confusing senior devs and rockstar devs.

Rockstars are lone wolves, write unmaintainable code that works quickly for demos but gives the company pain for years to come as nobody can figure out how to make it stable or maintain it. A rockstar's reputation is self reinforcing because it's easy to get a lot of shit done when one doesn't have to worry about maintainability, communication with the rest of the team members or the company at large, and service.

Senior devs balance development work and "service", a term I'll borrow from academia - hiring, mentoring, speaking, writing docs, etc. They either find fun in these tasks as well (I legit enjoy interviewing and mentoring), or understand this is a necessary part of being a well functioning team player at a senior level.


You hire the rockstar to write version 1. That's the one that gets you to market fast, and the one you should be planning on throwing away. It's the one you keep in production as your non-rockstar ninja and guru coders write version 2 from scratch. Once you release version 2, you really need to fire your rockstar. They will never be happy in maintenance mode, and that's fine, because they're usually bad at writing for maintainability.

Then you can hire some boring reliable folks from the khaki-and-polo brigade to help upgrade version 2 to version 3. This is when you have an opportunity to hire juniors and mentor them on what good software actually looks like, and how to make good-enough software better. The ninjas will probably leave at this point, and if they have done their job, the company will never need that level of expertise again in a permanent employee. The gurus will stay on to be an expert in your specific system, and teach the new people how to preserve its grandest traditions.

The problem is that a lot of companies never get to what I call "version 3". They might slap higher release numbers on it every so often, but if they never did a clean re-implementation of the quick-and-dirty prototype, that's still "version 1.X", no matter how high the numbers go. You put a junior in that environment, and they're not going to become a stable maintenance developer, and that's where the majority of the jobs will be for the foreseeable future, especially for inexperienced people.

To sum up: rockstars live fast and die young; ninjas quietly demonstrate incredible skills, and vanish; and gurus are the high priests for your established project, who will eventually pay off all your tech debt, if you let them.

There are different breeds of senior developer, and you really want the gurus teaching juniors when they start to run short of other useful things to do. If you don't have the kind of company that is mature enough to evolve a developer into a guru, you won't be able to handle juniors. And there aren't enough companies that can handle juniors. It may be because they aren't honoring the full software lifecycle that includes the long, long tail of maintenance mode.


Well said. Especially the "Version 2/3" part.

I think the never getting there often happens because management isn't aware of the current quality of their software vs hypothetical quality of a rewrite.

And I get it: I imagine every one of them has been burned by an overly optimistic developer. "It'll be rewritten in 3 months and run 2x as fast" types.

As a discipline, inculcating "respect that the years of person-work in the current version weren't done by idiots solving unimportant niche use cases" would be very healthy.


Labels like rockstar, guru and ninja are labels we don't need. We need competent generalists and competent specialists who can work in teams as well as work alone and can communicate with those who are part of the team or part of the management and user bases.

When a person takes on for themselves labels like rockstar, guru, ninja, etc. I don't doubt that they can write code, but I certainly doubt that they can write code that fulfils the needs of those who will be using it.

Labels likes these are a detriment to the profession. If we want businesses to take note and consider those in the IT profession to be anything more than ignored, we need to lift our game a long way.

What is IT known for (in the general sense), games, social media, search engines and lots of crappy software that users have to fight to get anything done.

Yet we have people and companies that produce great software that fulfils the needs of those who use it in a way that is not detrimental to those users.

It's coming up to forty years that I have been involved with the industry and I hear complaints every day from users who are frustrated by the inconsistencies in the software they are using, whether it be social media, business software, games, etc.

In general, as an industry, we are far too arrogant about our own self-importance and what we develop. Whether it be the likes of Apple, Oracle, IBM, Google, etc, the industry has forgotten that they only exist as long as people will tolerate the bull dust that is thrown at them by these companies. We are always looking for the "next big thing", yet many of the actual needs that we could be filling are not being done. We like flashy and not substance.


We don't need titles like that at all. Let's change rockstar to MVP Developer, Ninja to Builder, Guru to Experienced Builder, and the 3rd type of developer described in GP to Maintenance Developer. I think the industry could go a long way if it admits that it needs all 4 of these types of developers, so that expectations were transparent for employees and needs are transparent for developers.


I object to those terms. The rockstar is most definitely not the MVP. To the extent that I have worked with any, they are the insufferable primo donnos that fill the garbage bin and set it on fire then they proselytize their own trash fire to management until they think it is "hot", "energetic" and "enlightened". The rest of us then get stuck dealing with their legacy issues. If you're going to title-ify it, how about "prototype developer"?

The others can be "foundation developer", "transition developer", and "maintenance developer". It's still meaningless as long as different companies won't standardize on those titles.

We likely all know which category we belong to now, and which one we want to be. We also know that any company that asks directly for a "rockstar", "ninja", or "guru" is probably one to be avoided.


minimum viable product


But you see now how the TLA could be ambiguous.


There are those who get it done RIGHT, and those who get it done RIGHT NOW.


Yes to both of these, but there are other options as well.

The frustrating ones are those who talk a good talk about "doing things right" (and, generally, talk a lot...), but then work on something for an age and come back with a solution that's objectively worse than the "RIGHT NOW" solution we've been using in the interim.


This is one of the best summaries of software development practices I've seen. It's maybe even the way it should work.


A gem of a comment. This is why I come to HN.


Great explanation


[flagged]


I have that dream too. It seems that the more years I spend as a developer, the less I am comfortable to taking on technical debt. Maybe it is because there are so rarely opportunities to pay it off - and the interest rate is almost always way higher than anticipated.


"Most inventors are not professors"

This is not a great example. In academia, that's because they are fundamentally different jobs in most cases.

Most of the professor roles are not teaching their research, and where they are, i would bet your best professors are the inventors. But most are researching x and teaching y.

By contrast, in software development, the devs should be teaching, because what they are teaching is what they are doing on a daily basis, and the knowledge they've learned in how to do that well.

The notion that people who refuse to mentor or attend meetings (assuming these are symptoms of the same "not team player" phenomenon, and not something else) are rockstars is, imho, pretty misguided.

Even if you assume the 10x people silliness is true, each person mentoring 2-3 new people and building them will make the organization more productive than your 10x person fairly quickly.

(Again, situation may be reasonably different if you only will have a team of one or two, etc)


> By contrast, in software development, the devs should be teaching, because what they are teaching is what they are doing on a daily basis, and the knowledge they've learned in how to do that well.

I don't agree, senior tasks are often much more high-level and related to figuring out requirements/stories, or their tasks are hard enough that explaining them to juniors is not the most productive.


I'm kind of confused here, so i feel like i missing something. The way this is written makes feel feel like you you don't think the junior devs need to become competent at those high level tasks over time? Otherwise, how do they become senior devs if not by things like "gradually delegate higher level work, see what happens, help them learn by mentoring them based on results". It's not like they read a book and suddenly know how to do that.

"hard enough that explaining them to juniors is not the most productive" I strongly doubt this. Most of the differences i've seen over the years are in approach to complexity, and not level of complexity themselves.


If you don't want to teach, you're not a rockstar. The best developers I know have always been ready to show and explain what and why and how. Inventors love to talk about their inventions.


Teaching isn't a simple matter you can flatten down to like/dislike.

One aspect of teaching is explaining your inventions to your peers.

But another aspect is telling a new graduate what a version control system is and why you need one. Then doing the same for your build system, continuous integration system, staging environment, code review, bug tracker, style guide, and so on.

Seems to me those are quite different skills - I can easily imagine a person who is good at / enjoys one might not be good at / enjoy the other.


To a first approximation there is no such thing as a "rockstar" developer. I mean a few of them exist, but the actual stars (not poseur wannabes) are already locked down doing other things so it isn't possible to hire them anyway. If you're hiring or building a team you have to target developers who are actually available, not the stars.


Thus the need to hire junior developers. Some very small percentage of them will turn out to be rockstars, and they'll already be working for you.


I love that you pointed out the need for political strength within organizations. I agree, and I think it directly conflicts with this line from the post:

Yeah, I’m gonna bring gender into it, because I’m a woman and when women take on roles like this they often get pigeonholed into “den mother” stereotypes. That means less prestige and less prestige usually means less pay.

Having the admiration and respect of the next generation of developers at your company offers far more leverage than the nebulous prestige. If you mentor three engineers, that's three warm bodies at your company who will have good things to say when asked about you. If you do a good job, you now have a team of four capable engineers who can get things done.

What could provide more organizational political power than building a hierarchy of capable engineers that consistently come to you when they need help?


> Having the admiration and respect of the next generation of developers at your company offers far more leverage than the nebulous prestige

“Prestige” and “respect” are essentially synonyms, and careerwise respect of developers in the org often is not as important as respect of management.

> What could provide more organizational political power than building a hierarchy of capable engineers that consistently come to you when they need help?

Being perceived by management as delivering results rather than being the one behind the scenes enabling others to be perceived that way.


> Being perceived by management as delivering results rather than being the one behind the scenes enabling others to be perceived that way.

This is essentially a synonym of the sentence you quoted

> careerwise respect of developers in the org often is not as important as respect of management

You're missing the point. By mentoring developers you become de facto management; it's willful, benevolent career advancement.


Wait until you get old (past 35), I'm a woman (ex web deck "ninja/rockstar/etc") and I can safely say the ageist comments are far worse.

No one believes you can keep up the development sprints, or new technologies.


Molly, you are so right. And this is why internships are a bunch of hooey too. ("hooey" only in the supposedly merit-based on-ramp sense- of course they're valuable for teaching and learning and building a great team) The entire process toward getting tech job is ageist if all we have to offer "junior devs" is the internship role. (all the ads say that interns must be recent graduates or currently enrolled in an undergrad CS program) Nevermind if that's even legal. We know legality doesn't come into it until a whole movement and hashtag gets going. The ageism is sickening. It does seem that those who are the most ageist may suffer the consequences of their culture later. For example, it's interesting that Facebook is now officially the "old(er) person's social media" according to The Guardian and many other sources this week. Do note that "old" had to be changed in rewrite to "old(er)" in the paper, so as not to appear as fully insulting and ageist as the statement to address the data actually is.


I'm a little older but I'm only 6 years in the industry. I worked at a job where they were using technologies from 10 years ago, i.e. tons of custom PHP5 and MySQL on top of Wordpress, while I took the time to learn Angular, Node.js, MongoDB, Postgres, React, and modern tooling like Grunt and Webpack -- this list can go on and on. Now I have a situation where I had to go back in time and learn how to do things 4 years before I started hacking and everyone in any position of power is treating me like I'm a threat. I open my mouth at a meeting and someone will immediately shut me down. At every corner, I'm being mansplained to and I'm a man.


> Wait until you get old (past 35)

39 never noticed anything. Where do you work?


Don't see anything said that's incompatible with the 'Den mother' stigma. If its about pay and promotion, not about being friendly with Engineers, then you want to avoid the role that won't be respected.

You can't imagine all the ways management can dismiss women's actions - "she's a great connector in that department. Let's leave her there, that's working great." or "sure she's got all the guys eating out of her hand. But lets talk leadership - Bob has got everybody afraid of him! Lets promote Bob"


If its about pay and promotion

Pay and promotion is about making yourself valuable. If you mentor engineers and gain a reputation for doing so, you're effectively shaping the culture of the organization, not to mention gives you a ton of leverage with the productive employees you taught to be productive.

It makes you far less disposable. When mixed with even amateur negotiating skills, that leads to promotion and better pay.


If you ignore the part about stigmatizing, which happens to women by default, then sure. An objective management team would act as described.

But the 'den mother' comment comes out of a real issue, of womens roles being sidelined. One pragmatic response is to avoid roles that feed into the stereotype.

In a better world, this would not be a thing. But here we are.


One pragmatic response is to avoid roles that feed into the stereotype.

You make a good point, and I agree with the pragmatism of the choice, but I also believe mentorship can be a means of advancement.

The point of my original comment was to advocate for another choice - one that will both advance the mentor and their proteges. Hopefully, this will give us that better world we're looking for.


If you're mentoring jr devs ten it's going to be years before they rise up high enough to have any influence on you getting promotion.


Depends if the leaders even care what 3 junior devs think.


The leaders will care a great deal if the three devs are well trained and capable.


The leaders should care a great deal.


> always had to lie, cheat, and steal your way into the field

Back in the 90's, when I wanted to move up to working with C++ (the hip, new, "in" thing at the time), I bought a book about C++, read through it, worked the examples, and then started interviewing. The interviewers asked all sorts of arcane questions that I hadn't come across in my few months of study, so I was tanking the interviews. The trick I figured out back then, though, was that the interviewers all tended to ask the same sorts of questions - so after getting my rejection, I'd go look up what the answers to all their questions were so that the next time I was asked the same question, I'd know the answer. I did eventually get a job doing C++ (and did well at it), but... yeah, looking back it was maybe a little bit dishonest.


Your story reminds me of the joke/anecdote of the way to cheat on tests. You religiously look over your notes and the textbook in the weeks leading up to the test, so that when you take the test it's like you have a comprehensive cheat sheet with you, but in your head.

If the hiring process wasn't able to distinguish between you or who they thought they were looking for, then it wasn't your responsibility to inform them of it.



I may be dense here, but what's the difference between a cheat sheet in your head and actually knowing the topic?


That's the point of joke/anecdote. By studying you know the material and don't have to cheat, but the "tip" is voiced by someone more accustomed to cheating than studying, and so it's framed as a dishonest strategy.


That's the joke he referenced. Although there is a difference between knowing something and memorizing answers.


Knowing canned answers vs being able to come up with it yourself.


Well, thank you for your (intentional?) kindness, but back then I did sort of misrepresent how well I understood the language.


this happens in an episode of the simpsons except he studies on accident by getting locked in a closet.


Eh, sounds like smart preparation to play the game on its terms. Did those questions end up being seriously relevant to the work? If so, then you prepared yourself better for the job by learning the answers. If not, well, then maybe it's the interviewers who weren't so honest.


> Did those questions end up being seriously relevant to the work?

Oh, God no. I've never been asked a question in a job interview that was in any way relevant to the work I actually ended up doing.


Only one question has ever been relevant for me. It was about map reduce for locations and the job was using map reduce on location data...


At the job I have now, they spent the whole interview session asking about Python, Scala, machine learning, natural language processing, Spark and Hadoop clustering. I've been doing Angular 2 front-end work since I started.


I would argue that the kind of person with the skill to navigate into a position, is more likely than the person not, to be able to pick up things faster. So the fact that you may not hit the ground running does not matter so much as your attitude and ability to learn quick. Well done.


What you talk about indicates there is a gap between what industry wants/expects and what you learn either from books or in college.


It's only dishonest if you send in a fake interviewee before you in order to get the questions.


> accountants leave school fully capable of employment

Well, fully capable of entry-level employment. Anyone who graduates from a reputable school with a Comp. Sci. or InfoSys type of major is also fully capable of entry-level employment.

Accountants aren't really capable of anything but grunt work until they pass the CPA which normally is after several years of grunt work and additional learning and study.

Programmers aren't much good in a business until after several years of actually programming business systems.

It doesn't seem to hard to understand to me, in fact they seem quite similar.


> Anyone who graduates from a reputable school with a Comp. Sci. or InfoSys type of major is also fully capable of entry-level employment.

No, they're really not, for at least a year. It takes at least that long for most new graduates to get over the hump and learn enough of the practical skills and industry practices that their university left them woefully ignorant of, so that they can start being marginally useful. Once in a while you find somebody who has been doing real work on the side for years during or before college, and thus has a clue how things work, but that's a diamond in the rough, usually.

And unfortunately, many of them just can't hack being a professional programmer, and they never get to the point where they become a net positive, in which case you just hope they leave of their own volition or you can silo them off in some area of little importance that won't cause you problems down the road.


>or at least a year. It takes at least that long for most new graduates to get over the hump and learn enough of the practical skills and industry practices that their university left them woefully ignorant of, so that they can start being marginally usefu

A year?!

You're either scraping the bottom of the barrel for new hires, have a terrible on-boarding process, over-estimating the difference between the code someone fresh out of college writes or have absolutely terrible documentation or some combination thereof.

I'm leaning toward on-boarding and/or documentation. Junior devs are the ones who most need documentation because they're not gonna be able to infer the existence of policy and best practices from existing code and procedures as well as a senior dev will.

Either you and your HR is doing a terrible job giving new hires a lead on what to be asking and where to find information or that information just doesn't exist outside of the heads of existing employees.

I work at a CDN. We have plenty of issues with legacy code, cumbersome interactions between business units, outdated policies/docs, lack of documentation on stuff and all the other BigCo problems.

A huge chunk of new hires at any time are fresh out of school. It takes ~3-4mo before they're dealing with stuff on their own with perfectly fine results.

People aren't idiots but they don't know what they don't know. People with more experience are better at knowing when there's something that they don't know. Fix your process and you'll be able to get good value for junior devs.

If you don't fix your process don't whine when someone who has business practices that let them deliver the same results at lower cost by utilizing cheaper labor comes along and undercuts you.


No, they're really not, for at least a year.

Isn't that the definition of entry-level or junior?

FWIW, the four recent graduates I hired this summer are all capable of completing well-defined programming tasks with minimal assistance. Does that mean I spend more time with my PO ensuring those tasks are well-defined and consumable by the new developers? Yeah (but that's our job). Do the senior team members spend part of their day mentoring? Yeah (but that's their job).

As for some of them not hacking it. Yeah that's true. But, I've also interviewed plenty of "senior devs" who were terrible. I've even hired one or two who didn't work out. I just do my best to avoid hiring them.


All of those things comprise "entry level" to me. Maybe we have differnent concepts of what an "entry level" job is. To me, entry level == first job. The candidate has been a student but never a professional. They won't have practical skills or much knowledge of industry practices.

I'm not an accountant but I did do a business minor and I don't see this being much different for new accountant hires vs. new developer hires.


I worked with and later became a “student programmer” when I was in college. I had classes with some of these guys and I would ask them how long the homework took. “2 hours”? That’s crazy. It took me 10 and I knew people who were 15 hours in and not done yet.

Then I got on a new project as a dev. Within months I was down to 3-4 hours for similar assignments. My last class at school was the first time we had a shortage of hardware (good school). I would sit at home and remote into one of the machines, get my code to compile and show up to the lab the afternoon before it was due to debug. And everybody looked at me like I looked at my old coworkers.

It’s been a while since I’ve talked to undergrads but I always tell them to beg borrow or steal an internship or a job on campus. You have no idea how far a little concrete experience takes you.


Yeah, there was a great incentive to get done with the homework fast, because then you could get back to writing scripted mob behaviors and quest scripts for your MUD.

Finish with the boring programming, and you get to do fun programming.


>Once in a while you find somebody who has been doing real work on the side for years during or before college, and thus has a clue how things work, but that's a diamond in the rough, usually.

Can you define "real work"?


I assume essentially anything that isn't a school assignment.

Something built for a need--whether profitable business, or personal need--tends to provide more meaningful experience than a "write this contrived program to learn how [specific programming functionality] works" project.


Code schools try to solve this problem. But they need to become an actual structural part of the industry before companies can really start to rely on them.


They seem to be on the other side of the extreme though.


Ok, the first part of your comment makes no sense to me. How do you lie your way into a certification? An interview I can understand, but don't you have to take a test to get a cert?

From the second paragraph down, you're absolutely right for non-software companies. They still don't have an understanding of how to build software development into their business model. They don't realize that the low barrier entry to building software does not mean it is a low-cost, low-risk endeavor, nor do they understand how to extract value from a completed software project. They go straight from "Bob the executive has a cool idea," to, "Let's hire 3 full-time devs."


The Magento Certification tests are so divorced from the skills and reality of developing a Magento site and the study materials are so, so, so bad that most organizations just send a couple of canaries to take the cert expecting them to fail, then based on the questions they saw the org will put together their own memorization based study materials and train other devs using their own internal docs.

THIS IS INTENTIONAL on the part of Magento. They want a high fail rate. It ensures that only orgs with lots of money (who can afford a couple failures) will get a large number of certs and become official Magento partners, and since you pay for each test more failures means more money.

They have carefully structured the cert so that about 1/2 the questions are actual general skills and useful knowledge for working with the framework and about 1/2 are rote memorization such as, "What is the EXACT class name and Method Name that does X?" where options are

My_Basic_Class_Car::doThing() My_Basics_For_Class_Car::doThings() My_Class_For_Car::doThing() My_Class_for_Cars::doThings()

You need like 75% to pass... so if you're really lucky you can guess your way through the memorization portion but 90% won't pass on their first try.

If I were a hiring manager looking at a candidate with a Magento cert I could glean 1 of 2 things:

1) This person took the cert independently and cared enough to cheat or pay a lot of money to get it.

2) This person worked at an org with enough institutional knowledge of Magento and their payola process that they probably learned SOMETHING while they were there.


I should have said cheated, he got a copy of the first part of the test and memorized it. The second part of it which requires actual coding he barely passed.


1) The test itself is randomly generated from a huge set of master questions many of which are actually IN the study materials. Everyone studies "from a copy of the test". Its like saying you cheated at a spelling bee because you memorized the dictionary.

2) There are several parts to the exam but none of them involve an evaluation of how you write code, its all multiple choice.

3) The cert itself and studying for it doesn't prepare you for actually building a Magento site in any way. The Magento certification program is really just a way for businesses to get access to "leads" and get free advertising from Magento. Having more certs just helps a company look good.

4) If your buddy is experiencing a lot turnover my experience of the eCommerce industry and Magento shops specifically is that they are more inclined to put a heavy emphasis on "culture fit" and be high stress environments. They say, "If you see assholes everywhere, maybe you should look in mirror..." but it might just be your friend is experiencing the reality that eCommerce development is NOT the same environment as the Wordpress chop shops he may have started in.


You can get through a Magento certification by memorizing the answers that are all over the internet, http://magecert.com ect.


Most certification programs can be gamed. Generally there is a simulator - if you play enough with it and memorize the questions you will nail 60% or more in the official test. Take the test a few times and luck will kick-in.

Last year I worked with a certified LPIC-3 system administrator and deploying a trivial wordpress website at AWS took him 1 week. He was fired 1 month later. His CV is very impressive with lots of certification badges (I checked the codes of several badges and he is really certified).


What do you suggest for those of us who believe we would be terrible at management? Add to that, I also think I would be miserable doing it.


Find an employer that values career programmers? We have a "Technical Fellow" career path for devs/engineers/architects who want to remain in a technical role beyond the typical "tech lead" or "principle whatever" roles.


I've come to terms that I want to be a developer for as long as possible.

This thread can also help: https://news.ycombinator.com/item?id=7372997


Open your own consulting firm. The people you contract with, generally will not care if you're a 55 year old programmer so long as you can get the job done on time and on budget. Further, as you grow the business, you create your own security, as you can eventually turn yourself into more of a business owner/operator/manager, than only a programmer. This is one of the better ways to beat ageism in tech.


Subscribe to Rands' blog, read through his archives, and get on his Slack.

http://randsinrepose.com/

https://rands-leadership.slack.com/?redir=%2Fmessages%2Fgene...


That the system is stacked against us.


Nah this is not true. I started out as a junior dev and remained a junior dev for many years. I've progressed through the ranks over time by continuing to learn new concepts and tools, to observe my mentors and managers, and to adapt.

There may be environments like Silicon Valley where companies lean towards experience, but I can tell you in the Chicago areas University of Illinois and other comp-sci graduates get hired consistently.

It's too complex of an issue to throw a blanket over it. The market matters, the person matters, and the hiring team matters.

I don't believe there's any inherent bias against hiring junior developers. It all depends on a company's needs.


Depends on the business of course. Try getting interviewed by competent developers, they'll quickly find the holes.


I used to believe this, now I'm skeptical. Even if they find holes in the developer's competence, interviewing is not a task, it's a business process orchestrated and controlled by middle management. Say the competent developer finds holes in the interviewee's knowledge and skills, his findings become a line item in the report passed up to said middle management.

The middle manager, hopefully not in HR, has to weigh all the items in the report, and as a result the actual skill level of the developer gets buried deep, under cultural factors and attitude. There's also the human aspect, does Jimmy Mid-Level know how to raise issues with an interviewee's competence convincingly? If he doesn't, his concerns are likely to get written off.

This all ties back to the lack of political cover that software development shops in non-technically oriented organizations usually exhibit. Developers need to be in those middle management positions if they want their concerns to be taken seriously.


This is a symptom of managers not understanding the jobs of the people they're managing. I don't know if that kind of management works under any circumstances, but it definitely can't work if people who don't understand programming (and I specifically mean programming, no matter how well they understand the rest of a developer's job) are managing junior developers.


Of course it is. But in most organizations, managers do not understand software development. That competence is extremely hard to hire.


I'm fortunate to work for a manager who is a half-time developer. He's really good at interviewing people, and finding out if they're what we want.


This is why it's imperative that software devs get on the management track.


So true! My first (student) job..10 years ago... I landed because of personal recommendation through a friend and yeah, for the rest I built on that. Confirming what you say about politics, all following jobs there was a lot of of it involved rendering the jobs eventually mechanic/boring.

Especially the non-technical people at the places had really unrealistic understandings of IT and DEV in particular to a degree that tech colleagues thought everybody in MGMT must be completely stupid or insane. After having left these places after some time it's just funny.

And yes, for many non-tech people hiring Junior devs is no option in my experience. No idea what these people think, but maybe this is then changing as tech becomes more relevant.. ;)


> You have always had to lie, cheat, and steal your way into the field.

This terrifies me in terms of my rewriting my resume for my next job cycle. Is any minuscule semblance of honesty on a resume completely dead as a zombie shot through the brain?

I'm serious here. If I have never used XYZ tech, should I list that as a matter of course now should the position require it, and then fudge the results with a few searches and try-out "tests"?

In "current year": "I know what color it is" truly makes me an expert if I can snake-oil my way into it?


"Fake it 'till you make it," is a statement of pure wisdom, at least with regards to success in America. Especially in IT.


It seems to me that it's not uncommon for upper management to try to goad developers (and others) into becoming managers.. The catch is that it involves lots of free work by taking on increased responsibility with no increased pay. So I suspect most developers will think that it's not worth the hassle.


This might be a tech company vs. IT cost center in a traditional business thing. What major tech companies don’t have internship and new grad recruiting operations? Netflix is the only one I can think of.

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: