"..manage these people more efficiently by retaining them."
Yep - not retaining people is definitely not efficient management... <facepalm>
The idea that some software developers matter more to coding projects than others is controversial, particularly among open source projects where community cohesion and participation can suffer if contributors are not treated fairly. Scott Hanselman, partner program manager at Microsoft, argued against the notion of rockstar …
The trouble is, inefficient managers don't care. Their focus is on their next promotion, seducing their assistants, stealing office supplies etc. Companies full of these people may or may not go bust in the long run, but in the short run they simply exploit whatever talent they have on hand, without worrying about retention. In fact heroes are a bad idea for them, since a large department of mediocrities is usually taken as a better sign of status than a small one of rockstars.
Even efficient managers fall prey to this. In a large corporation the number of people you manage counts for far more than how productive they are. The manager of a small group of rockstars might get a bonus while the manager of a large group of average programmers might get a promotion. And a promotion means more pay, more benefits, and more job mobility both internal and external. Such is the way of the corporate world.
"The trouble is, inefficient managers don't care. Their focus is on their next promotion, seducing their assistants, stealing office supplies etc."
Oh, they care. They probably just think the coders are interchangeable cogs. A "hero programmer" that knows they are one might be a real prima donna, or legitimately ask for more money or flexibility. Of course, at that point they will be replaced by this type of manager.
*Side note, I don't care for this term. In the US they call football players "hero" too, to me this degrades the term for people that have actually done something heroic. But I also don't care to come up with a different term so OK 8-)
@Henry Wertz 1
A "hero programmer" that knows they are one might be a real prima donna, or legitimately ask for more money or flexibility.
You forgot "High Strung", like the underwear designers, as Ray The K (Atari) considered game developers to be.
Been there, done that, got the tee-shirt (literally)
Even if you are a rockstar developer there will be a manager who will find fault with you and deny you a pay rise or promotion. They see it as their sworn duty to keep the buggers down.
I suffered this a few times and eventually came to the opinion that British Managers are trained to accentuate the negative and find it really hard to give praise. I had no such problems in Germany, France or the USA. It was then that I started to play the game. You don't need me to tell you what that means.
TBH, it is not worth busting a gut to achieve anything here. Do the work. Put in the hours and don't forget to tip your forelock to the Boss and then lick his boots to a mirror shine.
The next 10 years is going to be interesting. It will get a lot worse before it gets better.
Kidding aside, at some point where you have a very large workforce your policies have to choice but to become mostly anonymous: what actions, incentives, bonuses etc. will keep turnover at the lowest. It makes sense, what I want to hear from HR is "employee turnover in the dev team was only 5% this year".
But we have a few heroes too, and we pay special attention to them - tailored policies to keep *them* happy because while i want to retain each and every dev, if I was forced to pick between losing 5 of those "heroes" or 20 others, I'd prefer retaining those 5.
This is what they were bringing attention to I believe: some devs are "more equal" than others ;)
I look forward to hearing/reading/seeing if there be many heroic programmers happy to comment here on this El Reg thread.
Methinks it would also be an excellent therapy for all to both alleviate and vanquish the motion and notion that stress is something to be suffered and given credence.
Which of course need to be sought after, paid a lot because they are "special", "not replaceable", and make revenue increases a lot.
But we cannot have "hero" developers - they should be all equal - where equal means "paid as low as the unskilled ones" and "replaceable, especially when we find someone who costs less".
It just looks to me that some highly paid executive can't accept the success of a software products is most of the time because some people are highly skilled, have the right ideas and can build them.
I met some of them. They were fixated with the idea that developers should be like blue collar workers, assembling software blindly on production lines as in an old Ford factory, from the requirements set by managers - which they thought was the real value - writing software in their mind was so easy everybody could do it, and especially, they didn't want anybody who could menace their well paid job.
By the way, blue collar workers are not the same too - when you have to build something very difficult and complex you'll find there are highly skilled, competent ones, and those who are not. In the old companies, the former can even climb the ranks of clever companies.
IMO the missing piece here is "where to climb?".
The thought seems to be that you need to become a manager to get that noticeable rise in pay.
We might be partly to blame ourselves. A good dev is quick to consider the "bus factor" and is actively supporting the idea that he/she him/herself should be replaceable.
Perhaps we should take a page (or ten) out of the BOFH's playbook.
On a related note, my employer got acquired by their biggest competitor a year ago. Our old manglement refused to invest in a web frontend for 7+ years while we kept adding somewhat meaningless features to our windows based client. When they announced the acquisition their main excuse was that customers suddenly had web as their main requirement, and our inept sales staff (coincidentally headed by our very incompetent CEO) were dead in the water. We had a good dev team, so we stuck by the company all those years because we figured we'd be able to come up with something reasonably fast given half a chance. (and I believe it is hard to find other good dev teams to join, so I never went looking)
The problem is this, together the fact that to become a manager you need now to have some kind of background in commerce/economics only - which wasn't true in the past. I met people, now in their eighties, who climbed the ranks starting working as blue collars. They become directors of production, and the like.
IMHO it all started with the idea of "maximizing shareholder value" regardless of the company health in the long term. It's clear that to achieve it you don't need domain experts in the company products, you need people expert to manage just the sales/financial part, regardless of the products. From there the idea of the "professional manager" who can switch from a company making drinks to one making computers without any need to learn anything and gain experience.
So you can climb the higher ranks only if you are proficient with the sales/financial issues, not the production/technical ones. So tech people are often hindered to get high-level roles - even when they would be better suited to understand and manage production. I'm not saying you don't need sales/financial experts too, I'm saying you'd need different skills at the higher level too to run a company well. companies would need a dual track system, and be able to promote highly competent and skilled "tech" people as well. Some do, but are not the majority.
It's no surprise that once company get bigger, and their upper level becomes full of "professional managers", they usually stop to innovate too because there are no longer the people with the rights skills to do that at the decision levels, and "meeting quarterly targets" becomes the only important thing.
It is also a clever way to hinder competition for well paid jobs. If you are able to cut the pool of possible candidates, it's easier to keep your job, climb the ranks, or offer a new one to friend. Call it caste system, if you like.
The managers understand why that is, namely they can't manage to make it any other way. If something happens to a celebrity in whatever field it might be, the public is displeased. If something happens to a software dev, the public won't find out until the next release at the very earliest and probably won't get enough information to figure out that's why it's buggy. Without some external pressure, there is a lot of freedom to treat people with exactly the level and type of respect you want, down to and including none at all. There isn't a great solution to this, but there shouldn't need to be as treating important people, which they almost all are, without respect is stupid in the medium or long term. Sadly, those with the power to decide what policies and behaviors are in play haven't noticed this yet.
Not true. Oh sure, the real megastars get stupid money, but the vast hordes of merely mid-ranking entertainers are often much less well off than you think. Even those who've been household names across four continents for a couple of years - are not necessarily financially secure.
The biggest money in entertainment goes to publishers. Just like software.
But we don't have "hero civil engineers" any more - projects are more successful and more reliable when you have teams of people with complementary skills working together and checking each others' work. They've even worked out that it's usually not a good idea to fight with your subcontractors when things go wrong, but to work together collaboratively to put them right: much cheaper in the end.
Although it probably isn't impossible to be heroic whilst remaining meticulous, methodical and collaborative, it's the latter three that have to take priority. There is really no practical consequence if a sports player or singer turns out to be useless and CEOs, executives and marketdroids are usually considered to be complete tossers, so I'm not sure they're a useful benchmark.
The fundamental difference between civil engineers and programmers is that civil engineers are required to be qualified and to demonstrate competence to rigorously defined external standards. Consequently, there are very few negligent or incompetent ones, and absolutely no entirely self-taught or self-certified ones.
"Hero" programmers probably stand out not so much because they're excellent but because their peers aren't.
Actually, not true. First, we have star architects, designers, etc. Then, even in highly skilled teams of those studios able to tackle the most difficult and innovative projects you have the "hero" ones with the most experience and skills. Remember a "hero" member of a team is not a "lone wolf" who doesn't collaborate - they are someone who are able to tackle difficult problems and be highly productive - and they can usually bring the whole team to higher levels by example and teaching.
Anyway, civil engineering as some thousands of years of experience - software engineering has at most sixty years, and it's still evolving at a very fast pace. There are far less "standard designs and procedures" to follow in software than in civil engineering, even for smaller projects.
You may consider "CEOs, executives and marketdroids" complete tossers, but that's not how most of the world sees them - and pay them.
Why, for example Apple & C. made a cartel to pay developers less, but not executives?
We are heroes in some projects and not in others. Much depends on our level of enthusiasm. It's difficult to be enthusiastic if project goals seem pointless or are poorly communicated. It's difficult to be enthusiastic when dealing with an existing mess or where developers are seen as a homogeneous resource, like toner for the printer ("We'll need a couple of coders over the next three months").
I agree with LDS (above).
Yes, having been a hero in some projects and a battler in others: it's not that clear-cut.
Also I've observed that a hero can suck the life out of a project and demoralize other team members - the more time you put into the work, the more you know the codebase (often through having been the prime developer) & are therefore best placed to make rapid and high-quality changes. On the other hand coming into another project where someone else is already the hero, you only get to nibble round the edges and are often in perpetual catch-up mode, reacting to change driven by the "hero".
I spent the first half of my working life putting in crazy hours to solve interesting problems - but ended up upsetting colleagues by changing things overnight and this ultimately hurt the long-term viability of those products (too much locked up in one head).
Post-burnout I try to be less of an ar$e - yes still striving to shape system architectures, but now making a point of spending time with junior colleagues to develop their capabilities, and also making a point of praising their work to management.
IMHO; a "hero" developer is not the "lone wolf" or "rockstar" type. A "hero" must be able to drive his or her "companions" towards the common goal, making them grow in the voyage - yet being the one able to face the most difficult issues when needed - it may not be the leader, and there could more than one, you understand who they are because they are those who take responsibilities when others don't - and deliver a good solution. Maybe in a humble way, and often not working alone but leading others too to achieve it.
For a manager, the difficult part is to identify the different types, especially when the manager isn't able to understand design and code quality and may not be well aware of who did what.
"IMHO; a "hero" developer is not the "lone wolf" or "rockstar" type."
Absolutely. I'm glad to have not worked with many "rockstar" programmers (by which I mean the attitude: I've worked with a lot of really awesome IT people) but those I did encounter potentially did more harm than good. Memories of the "I'm too important to talk to you" quickly followed by "why did you do that without checking with me?!" Er, because I needed to do my job some time this week and you were too busy being a rockstar.
"a "hero" developer"
I don't really understand this concept at all. One does not praise hero engineers when their bridge doesn't collapse. One doesn't praise hero mechanics when the tyre they replaced doesn't explode after ten miles. In both these cases, the non-hero options would be unacceptable.
Why should developing be different? Wouldn't it make more sense to retain (and nurture) the good developers, and replace the bad ones as soon as possible?
The hero engineer delivered the cantilever over spec and under cost. Unfortunately they also improved the design in a way that meant using it broke all the shimming pins. The pins weren't the hero engineers remit.
That's why they're a problem. They're not part of the team so they disrupt more than they contribute. They deliver stuff that looks good on the surface so management overlook the problems they cause. The team can't iterate and improve because they don't control the domain they work in, there's always random external contributions coming in that they are unprepared for.
That's why the superhero pattern is an anti-pattern.
On the various occasions in the past when I was job-hunting, I recall seeing a number of "opportunities for rockstar/ninja/[whatever]" developers...
... these immediately went on the "nope!" pile.
Maybe it's that I got into computers on the back of writing games as a kid, but the instant I see "rockstar", I read "must be willing to work all the hours under the sun to deliver the solution".
I've also met several developers who I would consider the software equivalent of rockstars - while they haven't actually said "do you not know who I am?" or chucked TVs out of windows when things didn't go their way, they've certainly had egos of such magnitude that I would not put such behaviour past them.
If I were ever to post a job ad for a developer, I'd want it worded that I would be looking for a "philosopher developer" - someone who actually thinks about the wisdom of what they're doing...
"... these immediately went on the "nope!" pile."
Unfortunately, managers seem to love the 10x/rockstar developer/IT person. In exchange for free food, ego stroking and/or wacky office furniture, they get someone with zero life outside of work. They can then hold this individual up to the rest of their team and say, :"Why can't you be more like our rockstar Bob?"
Tech startups are all the rage again, just like in 1999, and the environment is similar. Management is in FOMO mode and is convinced that hiring a bunch of prima donna geniuses will turn their stodgy insurance company into a FAANG or high-flying tech unicorn. It's going to take another recession to bring things back in line and get them to focus on doing a good solid job.
"Maybe it's that I got into computers on the back of writing games as a kid, but the instant I see "rockstar", I read "must be willing to work all the hours under the sun to deliver the solution"."
I think you're 100% correct, most listings I've seen for a "rockstar" programmer, it appears they are wanting one person to do the work of a small to medium development team. And they will want that job on schedule so naturally that would add up to massive work hours. (For the most part; I do figure a few of these listings are just overenthusiastic, if they were looking for a waiter and a cab driver it'd be an amazing waiter and phenomenal cab driver.)
Open source projects are generally driven by need or interest, unless they're being paid for by a company. So contributions will always be skewed by those who are the most interested in the work in much the same way in any volunteer organisation. Over time, they're likely to become experts on the project though this doesn't necessarily make them any more suited or talented than anyone else. The big problem with the approach is that code review isn't automatic and criticism is likely to be taken personally because of the investment.
Company projects are very different because you often don't get to choose what to work on…
I would go one stage further. Many Open Source projects start as a dream by one or sometimes a small group of people who have a vision, who go on to write the initial concept code and start the project. Others join in, but the initial instigators probably remain the largest contributors, possibly until they either get board or come up with another project to start.
They people producing this study should probably have limited their study to projects older than a few years, and will more than a vertain number of contributors overall.
In the past I have encountered developers who are not productive and generate poor quality code. They come up with stupid excuses as to why their work is not up to scratch but it all boils down to they are simply no good at software engineering.
So if these guys exist, of course programmers who are more skilled than the average exist. Calling them "heros" is a little bit shite though. They should be called for what they are; "highly skilled professionals who deserve a higher pay for their higher quality work".
I like working with these guys; they make projects go much smoother for the rest of us :)
...between a hero developer and a rockstar. The former will be capable, competent, open to discussion/explanation and an all round 'good guy'. The latter will think they're capable and competent, but not be open to discussion/explanation, and a pain in the proverbial to deal with. Two very different people.
There's also a big difference between rockstar and rockstar.
One rockstar is the one who is always front-and-centre on stage all night, playing their guitar with great skill, soaking up the glory. Then they go back to their hotel after the gig, drink like a demon and trash the hotel room. Hey, they're a rock star - that's what they do.
Then there's the rockstar who is the focus of the band and holds everything together.. They take their guitar solos in the spotlight, but also know when to step back and just provide a solid groove while their bandmates do their thing. After the gig they also go back to the hotel bar, but they sit in the bar and tell stories about earlier days on the road with <whoever> and buy the odd round of drinks for the rest of the gang.
Translate from a music context to a software dev context - there's still one type I wouldn't touch with a bargepole because they're a potential liability, and another I'd welcome onboard as they would be an asset both in terms of production and team spirit.
If you look around you'll often see a spectrum of skills, disease resistance, aptitude, physical ability and so on. The majority are the mediocrity. Roughly 10% are left handed. Roughly 10% have double-strength tooth enamel. A few develop awesome memories of who won the FA Cup. Some should never be allowed to drive ever. Organisations are either founded by way-above-average people or only tolerate them if they're safely in a 'cage'. For example political parties.
In my mind there is no doubt that some people are massively more productive than others when it comes to niche skills or singular vision. Ego and arrogance can negate those benefits. Knowing what you're talking about can be uncomfortable when your potential employer has a more miserable, expensive, muddles vision. (Eh? Why are you recruiting six people for six months when one person could do it in six weeks with no sweat? I didn't get that job.) But of course there is more to projects than cutting code. Every Batman needs a Robin is a good place to start. You're likely to need at least half a dozen different inputs into a project. Make sure you have a team-leader, or better a 'house-mother' who develops everybody's skills as they go. Why keep test data and testing separate from feature development. Why keep design away from user experience?
This post has been deleted by its author
>The researchers define a "hero" project as one where 80 per cent or more of the contributions come from 20 per cent of the developers.
Or instead of all that talk about "heros" you could simply call them "core team".
It's not uncommon to have a bunch of guys how only contribute one or two parts. Either because they find a bug and decide to fix it themselves. Or because they have special knowledge about one functionality or because they think the project looks interesting but decide against contributing any further..
There are many possible reasons and I really think we should avoid the term "hero" or "rockstar"..
"Core team" - Exactly that. I can't think of any venture where it hasn't been that way, whether it's software development, running a residents association, local festival, protest group, political party, or government.
Quite often our "hero" is the one who brings it into existence, sets it on a footing to succeed, brings people together in common cause. Things will then be run by "heroes" who are the main driving force to keeping it going, providing impetus, the "core team".
But amongst the "hangers-on" there will be "heroes" in their own right, in their own field of speciality. And, while it would be nice if everyone were "core team", there's nothing wrong with "hangers-on" - That's usually where the future "core team" emerges from.
It is not about "us and them", "gods and mortals", "heroes and hangers-on", it's the whole.
Biting the hand that feeds IT © 1998–2020