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

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.