Rockstar dev debate reopens: Hero programmers do exist, do all the work, do chat a lot – and do need love and attention from project leaders 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.
This post has been deleted by its author
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.
This is stupid. Open source projects tend to have two different types of people who work on them -- the people who _run_ the project and who invest a significant amount of time and work to further the project vision and people who are _users_ of the project and submit the occasional bug fix or quality of life improvement. Yes, most of the work is going to be done by the former group and yes, the latter group is probably going to be the larger of the two. That's not an interesting observation and it doesn't say anything useful about project management or developer productivity.
Perhaps the findings result from the division of software into projects. Really important in architecture (I saw this in a book by Christopher Alexander) is the breaking of the whole into parts. Wikipedia expresses it as: temperance is the state of the whole where each part does not attempt to interfere in the functions of the others.
Perhaps a part which conforms to the 80/20 rule has internal cohesion, without massive external dependencies. Unix pipelines allows people to write small useful programs that fit together. Such as ls, sort, uniq, find and so forth.
Doesn't it make sense that small useful tools fit the 80/20 rule. And that there developers be "local heroes". Perhaps every developer should be a local hero, for a suitable definition of local.
Disclaimer: I've not read the articles linked to, from the Register's article. But I might soon.
I'm not sure what they're trying to prove. So, there are lots of projects where 20% of the staff does 80% of the work. So, there's a core team, and there's a bunch of contributors who toss in an hour or two when they can. It's open source; we're not all doing 8 hours/day 5 days/week on it. How is this weird?
Even if everyone had exactly the same level of skill, you'll still see a lopsided distribution, simply because not everyone is devoting the same amount of time to the project. On top of that, even at exactly the same level of skill, the people who spend more time on the project are going to be more efficient, simply because they know the internals much better, which is going to amplify the effect.
All of this is perfectly normal and reasonable. Why does this situation deserve odd, loaded terminology like "hero" or "rockstar"?
Not as in unskilled and easily replaceable. But as doing a job nobody else does by little or no money, like a dancing monkey.
Praise is cheap as hell, and is usually the only thing people working in an open source project gets paid with. Thankfully donations are becoming more common, but those barely cover anything.
I disagree. The most productive developers have a vision and an understanding that lets them write the right code, quickly, ideally combined with the skill and expertise to write it well.
That's very different to the order taking 'write me this feature' codemonkeys.
In any organization there are people who have key domain knowledge and are very skilled at developing software. This would make them a local 'rockstar' as they have the knowledge and skill to understand the problems and figure out possible solutions quickly. This has been noted by many above. Anyone who joins the team has some learning to do whether it is domain knowledge and/or programming skills.
The problem with the 'study' is not that a project does not have a few 'rockstars', they do. But it is both the domain knowledge and skill that makes one a rockstar. The assumption most make is a rockstar dev can be parachuted into another project with very little domain knowledge and excel; not going to happen. IT is not like playing a musical instrument or a sport where changing bands or teams does not have a steep learning curve.
Also, most real rockstars devs I have met were rather unassuming not egotists that is implied by the term.
The assumption most make is a rockstar dev can be parachuted into another project with very little domain knowledge and excel; not going to happen. .... a_yank_lurker
Ever met a real rockstar dev which allows and assists in the parachuting of your project into their excellent domain. There your knowledge will be attended to, ideally according to joint wishes, for mutually beneficial outstandingly rewarding positive satisfaction.
Putting the shoe on the other foot allows for an altogether quite different dance, where ignorance of primary facts does not halt or hinder prime secondary actions in support of ...... well, it is difficult not to conclude in such cases that they be Real Live Advanced IntelAIgent Operations on Super Sensitive Stealthy Secret Missions.
And some would gladly tell you that is Phenomenally Good Progress in the Sight and Light of an Exponential Existential Threat Impossible to Contain without a Remote Command and Virtual Control Obtainment Exercising Advantageous Leverage for Aspiring Worthy Leaderships.
The assumption most make is a rockstar dev can be parachuted into another project with very little domain knowledge and excel; not going to happen.
Sure, but they will excel much faster. And people who can write good code, spot edge cases, test well, and have a high bar for themselves generally, and do all the same for other team members, will always be a lot more valuable than someone who can't, almost regardless of domain.
Also, most real rockstars devs I have met were rather unassuming not egotists that is implied by the term.
The term exists because these sorts of engineers were so undervalued in businesses.
People who spend more time working on a codebase are more familiar with it and therefore produce fewer bugs.
Whodathunkit?
Equally, if you have lots of people working in parallel on specific bits of codebase, it's quite likely that Person A will do something which will have unexpected consequences and/or will conflict with changes Person B is working, unless you have really good communications.
Whodathunkit?
Really not sure what the point of this article was, nor why it made such a big fuss about the term "hero". Why not just call them the Primary developer and/or Primary communicator? Or is that too simple a solution?
It seems to me like the researchers were looking for the 20% of contributors who made around 80% of the contributions, and, of course the researchers found them because that's how things work. It's pretty self-evident that for projects there is a core team and other people who contribute a bit, and of course 80% of contributions could be made by 10%, 20%, or 40% depending on the nature of team and project but it's normal.
The research seems to say nothing about the code quality (ie are the people contributing most code also contributing BETTER code than the rest?), nor does it say anything about the overall project quality compared to the ratio of contributions:contributors (ie, is the final solution better or worse if you have more of a core team vs a more distributed effort). THAT would actually be a question worth answering
They did take a crack at the quality of submitted code, saying that the code submitted by "heroes" produced fewer bug reports. Of course, that's just common sense. The primary developers are more familiar with the internals of the project, so they won't be hitting any weird parts in their contributions, while at least some first-time contributors won't know everything and will make minor mistakes that get reported. Similarly, any good primary developer will occasionally catch bugs while implementing something else and fix them, meaning that the existing contributions, which are primarily written by the primary devs, are more likely to be frequently debugged. The combination of these two factors makes it very predictable that primary developers' work is likely to generate fewer bug reports.
Honestly with all the COCs flinging around over the last couple years, how can you be progressive and inclusive if you treat one or a few better than the rest cause they are just better than the rest.
BTW I do agree that everyone should be treated the same under the law but I don't believe everyone is "the same" though. People just have different talents thus making them better at certain things and less so at others. So no people are not equal but all people should be subject to the same rules.
Equality of opportunity yes
Equality of outcome no
Many years ago I managed a small group of 9 or 10 programmers. In that group there were three of us who could be called 'rockstar programmers' (including me, BTW) -- we could out code everyone else both in quantity and quality. Did that mean that the others were redundant (the subtext in this article, BTW)? Not in the slightest. Because, unfortunately, there's a lot more to running a firmware group than just churning out reams of code. The others had useful functions, some of them irreplaceable -- for example, one fellow wasn't a very good coder at all but his signature property was that he could read, understand and digest IBM technical documentation without falling asleep. Others we doing seemingly unproductive tasks like digesting IETF documentation, probing for obscure bugs and generally keeping themselves occupied.
The danger of talking about 'rockstar' types is two fold. One is that unless the coder is disciplined and focused there's a good chance that all that they'll turn out is reams of crap. (Seen it......diva type I inherited.....knew all there was to know about writing code, including how to make creative and obscure bugs.) The other is that if the bean counters get wind of what you're up to they're likely to assume that the group is overmanned by a headcount of six. The effects of such RIF take a little time to permeate so they're heroes in their own way for cutting costs -- long enough for them to make their escape before everything goes belly up.
GitHub projects sound much the same as any volunteer group: you have your core of especially passionate, knowledgeable people that keeps the whole thing running, surrounded by a broader halo of people who pitch in to do whatever low-level stuff is needed as time and life allow.
When it goes well, this means you have a stable core which applies its institutional knowledge to keep things running, and to mentor new people.
When it's not working well, your project collapses because one key person left and they were a silo who never shared their knowledge, or they've already driven all their possible replacements away by being a toxic person, or they fell out with some other long-time person and decided to wreck things on their way out the door.
I'm surprised people find this controversial. Everywhere I've worked there have been the Go-To people: people you went to to get things done, correctly and on time. And there were always the other type, and everyone knew who they were too.
A big part of management is to:
1) Acquire and keep the first
2) Try to help the people in the second group move in to the first or, failing that, out of the door.
" But it's important to distinguish between equality as a civil right – everyone deserves equal treatment under the law – and equality as an assertion that everyone is the same."
Been called all sorts of bad things for saying this truth for decades. Glad not to be alone. Why do most insist on lying to themselves in denial of this? And
why do those commonly self-described as "woke" deny this the most?
FWIW, as one who toured and worked with actual rock stars - the most talented are the most humble, at least in day to day life. As a software guy and
later the owner of e consultancy, we used this terminology anyway - even though we were inwardly laughing.
You never get anywhere if you think you've already arrived.
I'm surprised it's seen as controversial to say that some developers perform much better than others. In all fields where performance can be indisputably objectively measured, e.g. playing chess, playing computer games, athletics, there is an obvious huge difference between the best and the worst performers, and even a big difference between the performance of e.g. the top 0.01% vs top 0.1% vs top 1% etc.
Firstly, as mentioned above, the definition of superhero used in this study just captured the core team. Having a core team isn't inherently a problem.
The second problem is that this is a study of open source development. When people are being paid to develop there is a completely different dynamic to a project where contributors choose to contribute.
The superhero pattern is a problem in a work environment where a group of developers are trying to work as a team and one team member, often cto or "lead developer", doesn't work with the team and instead pushes their work on to the team as the team are trying to focus on their own work.
This behaviour often plays out to the hero's advantage. A team nearly completes a feature, the hero pushes a super new widget that performs ten times faster but breaks the teams feature. The customer sees a performance improvement from the hero and a failed delivery from the team. Bad managers facilitate this behaviour by not calling out the hero for breaking the feature.
By all means be a hero on your hobby projects. When you come to work on a team then you need to focus primarily on working in a team, all your clever code means nothing if you're just screwng up every body else's work.
Although I think having a dnd style character class and level would be better, oh look there's Bob a lvl 6 fronted paladin, there's Jane the lvl 20 regex mage, watch out for Jimmy he's a lvl 1 bard with theif tendancies, beware his crtitical attack on a 2+D6 the feared cargo cult stack overflow copy and paste
And you call a lead dev who actually leads the team and not just there architectural "vision" (interface to the interface of the virtualised abstract base class anyone???) a DM/GM
This post has been deleted by its author
If you say you are a "rockstar" you probably aren't.
Of course the second rule is "never admit you are that good". Just show what you can do. No more, no less.
Oh, and programmers aren't "fungible". Skill sets vary, and without absorbing more knowledge, the half life is very short!
There is another way of looking at it. What they call the "hero's" are just normal competent programmers. The "not hero's" are in the group that contain those truly awful programmers who never test for an error condition, possibly because they can't work out what to do if the test finds one. Also when they bother to test the functionality of their code (or more often it is pointed out by someone else) and discover out by one errors on every loop they "fix" them and introduce out by 2 errors. Hero is a relative term.
Principled individuals may reject the notion of software heroes outright because the very concept can be taken as antithetical to the abstract notion of equality. But it's important to distinguish between equality as a civil right – everyone deserves equal treatment under the law – and equality as an assertion that everyone is the same.
How is this even on the table? Don't forget arithmetic equality - we don't mean that one either.
And other principled individuals will say that some people are more valuable to a project than others. That's one of the reasons why we compensate them differently.
There are the ego type Rockstars, that gets their own isolated parts of the system, as nobody wantys to work with them. They are not really rockstars.
To me the Rockstar has a fanbase among the other developers, he is the one people comes to and asks for advice, and uses for sparring about new ideas. He is the one that will actually help the team as a whole, and communications is part of this. In a pure nerd group, comms is different than in a mixed skills group.
And no, I had no ego and was definitely not a rockstar.
I was simply the best at languages and able to spot any bug when colleagues would lose days of debugging.
End of the day ? It didn't get me any sufficient pay slip (was in Paris in the 90s, to put this in perspective), since I was still a junior, and I ended up leaving dev. entirely ...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
