
You Don’t Need Superstar Developers - ArturT
http://blog.lunarlogic.io/2017/effective-collaboration-superstar-developers/
======
twobyfour
It depends so much on what you're building. If you're doing _groundbreaking_
research in, say, AI or facial recognition or whatever, you may need people
who are technical superstars.

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.

~~~
corporateslave3
In other words, you want an office drone with minimal intellectual curiosity
who is docile, does what they are told, and works well with others.

~~~
aerovistae
Speaking as an office drone who is docile and does what he's told and has
minimum intellectual curiosity with regards to the software he's tasked with
building, I don't get much done compared to the superstars around here who can
put out 3000 lines of code a week, building out entire new features and
workflows from scratch with beautiful, clean, well-organized code. I disagree
with the suggestion that superstars (a.k.a. extremely productive and capable
coders) do poorly on ordinary work.

------
kozak
One of my most useful insights in software development is that no matter how
smart you are, if you write code that can't be understood by a junior
developer, it means that you didn't do a good job writing that code.

~~~
DamonHD
And the reason that "the code is self-documenting" is a bad smell is because
in 3 months even the 'rock star' who wrote it won't remember without
appropriate help (eg comments).

I've worked with some pretty smart developers in some pretty interesting
roles, and the people cock-sure of themselves are rarely anything other than a
poisonous danger to overall performance and deliverables typically.

I say this as a lone wolf by inclination, though also unexpectedly happy on a
trading floor with hundreds of people around not entirely managing their
emotional interactions!

~~~
athenot
Besides, code speaks to the compiler/runtime; comments speak to the human.

\- The machine need to know _HOW_ something should happen. That's code.

\- The human needs to understand _WHY_ that thing should happen that way.

These are two different objectives, and good quality code weaves the two in
the appropriate measure.

Having said that, I don't believe all code should be reduced to the subset
that a junior dev can understand. Keep it simple when possible, yes. But don't
limit yourself, otherwise it's just a shift to verbosity, eating into the
finite attention span within the brain. Rather, if the intent is properly
documented, then the junior devs can still work on the parts of the code they
understand, and reach out to a senior dev when they need to touch the part
they don't understand, because even if they don't quite grasp the "how", they
can follow the "why" in the code.

~~~
ithkuil
yeah. I've seen a lot of comments like:

    
    
        // Sleep for 10 minutes
        sleep(15*60)
    

Unfortunately, the compiler cannot check your comments. Don't put facts that
are better looked up in the actual code and that they only risk getting out of
sync with the code.

~~~
athenot
That's a useless comment. A better one would be:

    
    
        // Prevent the two tasks from running right after each other,
        // to reduce load when this is run frequently
        sleep(15*60)
    

Even the most junior dev can infer that a multiplication by 60 for a sleep
function probably means the unit is seconds and we want 15 minutes. No need to
spell that out. But why sleep for 15 minutes and not just carry on to the next
task? _THAT_ is what the comment is for.

~~~
Clubber
Exactly. Comments are for intent, not what the code does. If I want to know
what the code does, I can just read the code.

------
DavidWoof
I think most of this is, or should be, uncontroversial. While it's incredibly
important to avoid bad developers, once you hit a certain high level of
technical ability other traits become more important. Besides, this isn't a
fixed scale. Except for a few outliers, the concept of "more skilled" doesn't
really have a meaning once you pass a certain level.

At that point, what many shops do is hire people they enjoy being around,
which is usually a shorthand for hiring people just like them, and then create
all sorts of pseudo-psychological justification for it. The truth is that one
day isn't going to tell you much about a dev. Some people are really good when
first meeting strangers, some people are very uncomfortable for at least a
week. Everyone deals with that nervousness differently, and on the other side,
most people are incredibly unaware of their own prejudices that might be
affecting their one-day reaction to a new person.

At the end of the day, there's really no magic formulas for creating great
teams.

------
throwaway2016a
There is a third measurement. Experience. And the superstar developers tend to
have more of it, although not exclusively.

Specifically they have probably seen and done the problem you are trying to
solve already and don't need to spend as much time learning and researching.

Less seasoned developers take a lot of mentoring and not every company can do
that. In fact the words "mentor" and "train" are nowhere in this article.

Granted you don't have to be a superstar to have experience. And also, on some
projects (like CRUD as someone else mentioned) less experienced developers
have plenty enough experience to do the job.

There is also the added benefit of experienced developers being able to see
when something is being done the hard way. I've seen many cases in my career
where a less experienced developer didn't know a tool or technique and would
have (or did) go down the more expensive and time consuming path.

What this article should be (and i think might be getting at slightly) is "you
don't need superstar developers if you have superstar mentors." If you have
neither you're in for longer development time and higher cost over time.

The flip side of the coin is that superstars also have a tendency to favor
projects that are mentally / academically challenging which leads to over-
engineering or boredom and attrition.

------
cbsmith
Team dynamics are of course critical, but part of that dynamic is "game
recognizes game". Having highly skilled developers makes it easier to have an
overall highly skilled team... and ironically that makes it easier to be
selective for factors like "team dynamics". It's when you have weaker
developers that you have conversations like, "we are just going to have to put
up with the a __hole because without them we 'd be really screwed".

------
miga
Yeah, hire below-average developers instead and never end the job of cleaning
up.

I heard about startup that changed team three times, and had to rewrite
codebase likewise.

~~~
s73ver_
I fail to see where they said "below average developers".

Unless you think the average is "superstar".

------
klagermkii
> In our case, we want a new hire to be able to act as an independent
> contributor, i.e. their work doesn’t have to be double-checked. We also
> focus a lot on craftsmanship since it means that we all are getting better
> at what we do and at a good pace.

Maybe this varies between cities and job markets but when I read that baseline
description he gives in an off-hand manner for the programmers he hires, I
think I would probably be calling them "superstars". I don't know if the
availability of skilled employees is great in Krakow, but when FizzBuzz type
tests are still filtering a large percentage of applicants, it makes it sound
like it's from another world.

That's my concern when reading these kinds of hiring articles, it feels very
different to how hiring looks when you aren't privileged to have an abundance
of skilled candidates available.

------
js8
It's always interesting to work with geniuses, but I think..

If your business model is based on your employees being geniuses, then you
probably have a wrong model.

------
chasedehan
I would add a second element to the title "You Don't need Superstar
Developers: You Need High-Acheivers"

The challenge is really having a mixed team of high talent and minimal talent.
While yes, those who are of lower talent will learn more from the super
talented, the inverse is not always true.

I have found many lazy (or at least not super motivated) devs who have the
required minimum competence level, but are not super driven to crank out high
quality work. This then makes me not want to work as hard.

This is a little different in that in general companies should go after high-
achievers, rather than a minimum technical competence.

~~~
Clubber
I believe Spolsky summarized it as:

    
    
      1. Smart.
      2. Gets things done.

------
jasonmaydie
Well that's a broad statement. We don't all need the same thing.

~~~
katastic
Tomorrow from Gamesutra: "Developers are dead. Good developers don't have to
be your audience!"

------
eksemplar
Team working skills, business understanding, the ability to communicate from a
social constructive point and an openness to working with prototyping in
consumer focused project groups are much more important abilities than
technical skills in a lot of modern development.

Superstars and best practice masters can be important, but all those
enterprise applications we build on all the right practices are being replaced
by web-apps, microservices and a range of other things, effectively rendering
all the brilliant work useless because no one ever revisited shit.

I get why you'd want a technical superstar for certain things, like developing
your long term libraries, but for most tasks a shitty programmer who is
business savvy and actually capable of talking to non-it people will deliver a
better end project.

Of course a lot of superstar developers do the other things really well, as
well.

------
HillaryBriss
_Evenness of communication is about giving everyone roughly equal chance to
speak up, not having some parties dominate the conversation._

in my work experience, there are almost always one or two leads who dominate
the conversation.

------
nickthemagicman
Why wouldn't you try to get the best developer you can pay for?

~~~
ubernostrum
See "We only hire the best means we only hire the trendiest":

[https://danluu.com/programmer-moneyball/](https://danluu.com/programmer-
moneyball/)

------
hathym
the real question is, can you afford Superstar Developers?

~~~
chrisco255
Yes because there's no real agreed upon definition of "super star" developer.
So we're all super stars?

------
leowoo91
True, mostly. You might steel need few of them to lead by example.

