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.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

"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.

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.

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.

"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.

But it's discrimination with a higher purpose.

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.

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?

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

I 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.

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

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

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.

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 :-)

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.

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.

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.

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...

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.

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.

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.

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.

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

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

The 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 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)

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.

"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.

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.

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?

“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.

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.

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

39 never noticed anything. Where do you work?

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"

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Can you define "real work"?

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.

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."

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.

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.

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).

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

http://randsinrepose.com/

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

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.

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.

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.. ;)

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?