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.
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).
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.
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.
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!
And then sometimes, you just have some compiler-hack or otherwise complex piece of interaction that you can't refactor into something better, and then it's of course better to add a comment rather than just leaving it there.
- 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.
What is one question; why is another. When we work with the existing code (debugging, maintenance) we need to know answers to both questions. So, in addition to a well written (self-documenting) code base we need a document explaining the rationale for the choices that were made and, more generally, the context in which the code was created.
That simply means you're working with poor developers.
If I have to deal with ambiguous specifications, vague priorities and to fill in the gaps I need to start modeling the business's needs, operational structure and priorities in order to make appropriate decisions then that means I have fewer cognitive resources to deal with the actual coding.
i.e. it's not just code that needs to be loosely coupled, it's businesses.
Obviously you cannot expect complex code to be well understood without background and programming capability.
Having well-documented code is one thing, and ability to work on this code without breaking things is another.
Only true for simple apps (i.e., CRUD, etc.)
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.
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.
I heard about startup that changed team three times, and had to rewrite codebase likewise.
Unless you think the average is "superstar".
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.
If your business model is based on your employees being geniuses, then you probably have a wrong model.
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.
1. Smart.
2. Gets things done.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.
in my work experience, there are almost always one or two leads who dominate the conversation.