I think this is true for high risk, cutting edge tech, the problem is that A LOT of companies think what they're doing meets that definition when it really doesn't. They think their NoSQL datastore with 10 million records and a single page frontend is the like putting someone on the moon.
And really maybe the point of the article is more that we should reconsider what makes one a superstar. Raw technical ability is one component, but communication, and teamwork are other very important components. It's like in basketball, someone may be an elite 1v1 player, but someone who is a great passer, defender, and leader is probably more valuable to a team.
Can you back that up with data? The majority of companies in the US have zero problems hiring developers who aren't rockstars even when their business model is unique for their industry. My evidence is the disproportionate number of questions from developers on Stackoverflow asking things that they would know if they had a decent amount of mastery in their field.
And that they need to interview you, accordingly.
In Montreal, we have tons of AI people here - their code is sometimes a nightmare. They are AI guys, 'code' to them is like 'mathlab'. Fortunately, it's surprisingly not a lot of code.
But the general point stands: it depends what you're doing.
Developing frameworks is a good example: you generally want experienced people who have 'seen it, done it, been there' and have the 'wisdom' of that - plus - hopefully, an ability to actually 'get stuff done'. Doing 'new' is hard.
But 'in general' I think the post makes sense: 95% of companies need 'professional, thoughtful, collaborators' who can take mildly complex problems, write clean, safe, simple code, document, test, release and move on ...
Great technical star probably don't know AI algorithms and may ressent having to implement math based routins with little tech knowledge being needed.
Someone who is great in algorithms might not be best for tasks heavy on configuration. Someone who constantly seeks new might have trouble to perform routine tasks.
Great under pressure performer might fail in "as much time as you need" situation (and vice versa).
No - AI and ML stuff does not need technical superstars (i.e. from a programming perspective). Usually it is a rinse-test-repeat kind of job. It needs people with patience and who can interpret data and who can be comfortable with uncertainty and then can make their bosses comfortable with uncertainty on timelines.
In most of the other cases, hiring superstar developers help you save costs in the longer run. It helps product (or SaaS) companies.
But for consulting biz that means less of the recurring consulting work. Superstar developers cost higher - means more work in fetching some consulting work. Consulting/service businesses will rarely value superstar developers. Because it does not help the topline as much.
I think research is the key word here. If you are developing fundamentally new ML techniques (like the folks at Google), you'll probably need some serious technical chops.
> Usually it is a rinse-test-repeat kind of job. It needs people with patience and who can interpret data and who can be comfortable with uncertainty and then can make their bosses comfortable with uncertainty on timelines.
That sounds less like research and more like applying established tools (Tensor Flow or Keras or whatever).
Nope, still no superstars needed. The most technically challenging thing they've built is probably is what they are doing with the TPUs, but even there you "just" need people expierienced in the right fields. Most groundbraking research stuff these days is mostly on the mathematical side, not the implementation.
This is what most AI, ML and data science people do from my experience. It's really not that groundbreaking.
somehow that isn't a definition of a technical superstar. I suppose a superstar is a DC/Marvel style character who do software engineering impatiently, skipping the test-debug-fix-repeat ... Well, save for the missing Batman mask it is basically the lowest productive engineers i've ever met, and probably you really don't need these superstars.
I didn't see that specified.
> docile
Yes.
> does what they are told
Yes.
> works well with others
Yes.
Even the average CRUD plus workflow application is only really routine & repetitive if you're using suboptimal tools. If you're good, you're good at choosing the optimal tools and automating all the tedious stuff.
In large companies, managers would rather have a mediocre team of six doing this type of thing than a stellar team of two even though it costs more. This is mainly because they're aiming to optimize their headcount rather than company profit.
In small companies, most managers are simply stingy, and feel affronted by paying over 'average' for something like that.
In both cases, measuring actual software developer productivity is pretty much beyond every manager who cannot code (which is most) so it isn't hard to justify this suboptimal behavior either to themselves or others.
>What you really want are people who are technically not outstanding but quite capable and have very strong soft skills.
No, not really. Soft skills are vital for team lead and product management but being able to write a good email and butter up your superiors isn't too important for other developers.
That is, unless you're using soft skills as a proxy for "writes clear, maintainable, easy to read code".
>people who are good at prioritizing their own work;
This is a product manager's job and if you're pushing that job onto developers then it's almost guaranteed to interfere with their other work and to be done poorly. It's a bad idea to ask them to do your accounts and file lawsuits too.
Yes, in the real world you sometimes have to work with poor product managers who have little empathy with customers, who deliver unclear specs and vague priorities. That doesn't mean a good developer is somebody who can handle the parts of their job that they failed at.
"Communicating clearly" is important, but when developers fail, they usually fail at writing clear, functioning code, not explaining why they did something to others in a conference room.
It is not possible to write specs completely without ambiguity - just like no one writes code without bugs. A developer who can ask questions to customer with empathy is more valuable then the one who plays telephone and needs interpreter.
What you are describing is junior work - juniors are closely supervised and fed every detail.
Estimation is not a communication skill.
>explaining clearly to pm why is feature harder to implement
A PM is probably not interested and does not need to know why they just need to know that it is hard to implement. I've typically done that by assigning a number (1, 3, 5, etc.) to a story indicating its difficulty.
If your communication problems extend to not being able to state numbers then you do not have a lack of soft skills, you have crippling brain damage.
>He may be unable to explain why more time for refactoring
Developers usually don't have to explain to other developers why more time is needed for refactoring, showing them the code in need of a refactor is usually enough.
PMs may ask why but they don't need to why and they probably don't care why anyway.
>It is not possible to write specs completely without ambiguity - just like no one writes code without bugs.
And? Going over to the PM and asking them to clarify a few details isn't exactly the hardest part of a developer's job. Average levels of communication skills suffice. It only becomes challenging when the PM writes horrendously ambiguous specs.
Nope, showing the code is not enough to explain to other developers, unless we are talking about something extremely clear, simple and small. And yep, developers tend to have different opinions about what is important. The expectation that they will automatically share your concerns is pretty much how developers with lower social skills fail - and why lack of it slows everyone down. (And then they complain about everyone being stupid while the issue is they did not expressed themselves clearly and did not listened to contraarguments).
And PM IS interested, good one that is. It helps him to argue to customers/his bosses/other departments. It helps him to trust you. It helps him to distinguish between something that can wait and something that need to be done soon (you had him doing all prioritization and you claimed developer does not need such skill). Software estimates are wrong often enough that good PM won't take them as granted. At minimum she needs a sense of risks. It helps him to change the spec so that new one is doable faster.
Have you even consider entry that PM can react to reasons why something take long by changing spec, changing priorities, negotiating more or finding someone more experienced I that are to help you? Good pm do all the above. Which is why they can achieve more if people under them cooperate.
On your last point - given that developers with bad communication skills ask badly phrased questions or don't ask anything at all (just generically complain about bad analysis and insult pm - true story), yep it matters.
You jumped from "bad social skills" to "average" there. The two are not nearly the same thing.
I've literally never had this happen once during a planning meeting.
>Nope, showing the code is not enough to explain to other developers
It's always worked for me. I can read code, grasp the structure and spot code smells with a glance. If it's really bad I'll be able to tell.
Usually I will just trust the people I work with if they say "it's bad" though.
>And PM IS interested, good one that is.
Good PMs learn to stay out of technical issues and trust their developers just as good developers learn not to second guess their PMs.
>Have you even consider entry that PM can react to reasons why something take long
Uh, was that English?
>On your last point - given that developers with bad communication skills ask badly phrased questions or don't ask anything at all (just generically complain about bad analysis and insult pm - true story), yep it matters.
As I said before I've worked with several developers who rarely ask questions and just do the work (and do it well). All stellar developers and highly underrated.
>You jumped from "bad social skills" to "average" there.
We were always arguing about whether it was a priority for developers to have especially good (or even above average) soft skills, not whether it was ok to work with developers with cripplingly bad communication problems.
It's a Platonic ideal of specialization, and in no way an ideal environment for actual humans. IRL, I wouldn't want to always be told precisely which task I should be on at every moment.
No, unless they work very individually. Especially not I freaking agile situation - or any other situation where developers cooperate closely or have to communicate with customer. Thinking that soft skills don't matter in team tend to be entitled.
A developer without soft skills means that all the other developers need to use twice as much soft skills whenever dealing with him. It may mean everybody else having to defend against constant attempts for micromanagement and bullying.
It means longer meetings, because that person does not read situation despite being explained it already three times. It means feature being implemented badly, because that person can't understand how someone different might want it work differently then he would prefer. It means major temper tamtrum cause team did not agreed exactly on his coding style. It means days or hour long arguments about petty differences.
It means dude claims other people "produced bad code" and team members being accused of incompetence or mocked in front of managemnt instead of being asked why they did things certain way - all the why the dude act puzzled when they are pissed when they find out their solution is actually right (but management is not there already). It means juniors afraid to open mounth.
"This is a product manager's job and if you're pushing that job onto developers then it's almost guaranteed to interfere with their other work and to be done poorly."
Unless the product manager completely micromanages the team, which tend to be ressented and tend to push out more experienced people, you have a level of autonomy around tasks prioritisation. If you can't do it, pm will do that for you, but you will be considered higher maintenance and less capable.
Unless you're a developer that works by themself on code that will never be used directly by other people, soft skills are always vital. Soft skills include things like being able to empathize with others, which is quite important for building usable interfaces. And, soft skills are incredibly important for getting along with others, which, as a developer, you're going to have to do.
And, as with leaving product management to the professional product managers, it is usually better to leave the designing of UIs to the professional designers.
>And, soft skills are incredibly important for getting along with others
Not having good soft skills is not the same thing as having a toxic personality.
I've known many developers who rarely talked, rarely spoke up during meetings and just quietly got on with their job - building code to spec - and did it really well. They were, sadly, always highly underrated as developers and judging by what I've read in this thread, this is a prejudice that isn't likely to disappear any time soon.
If you're building the average CRUD-plus-workflow application, the last thing you want are superstars who are going to get bored with routine work. Then they'll go off over-engineering some minor feature or spending weeks at a time inventing some algorithm you don't need instead of building the product you do need - just to keep themselves from going stir crazy.
What you really want are people who are technically not outstanding but quite capable and have very strong soft skills. People who can work well as part of a team; people who mentor and learn well; people who follow through on their tasks; people who not only can, but want to understand your product and business so they can make small decisions independently and well as they work; people who are good at prioritizing their own work; people who are good at identifying risk and knowing when it's worth the time to address; people who are good at communicating with both teammates and management.
Although you might argue that people with several or all these qualities are rare enough to be superstars in their own way, they're not superstars in the sense often discussed in forums like HN.