You Don’t Need Superstar Developers(blog.lunarlogic.io)
blog.lunarlogic.io
You Don’t Need Superstar Developers
http://blog.lunarlogic.io/2017/effective-collaboration-superstar-developers/
85 comments
> 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.
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.
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.
>A LOT of companies think what they're doing meets that definition when it really doesn't.
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.
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.
I'm saying most companies that think they're doing something groundbreaking that requires one-of-a-kind talent are wrong. These are the companies that put out silly job ads about how they're looking for ninjas/rockstars/geniuses and they only hire the best of the best in the field. Then they want candidates to jump through their ridiculous interview hoops.
Honestly I think this is just a symptom of over optimism on any company's part. This is sort of like how everyone thinks they're better than average at driving. All companies want to believe they are better than average at hiring. They also "choose the best" when, really they're just choosing the best from their limited talent pool.
They think their NoSQL datastore with 10 million records and a single page frontend is the like putting someone on the moon.
And that they need to interview you, accordingly.
And that they need to interview you, accordingly.
Ah, but if you are doing groundbreaking AI research, you need AI experts. You will also need developers, but those developers may not actually need to be superstars.
Yes, the AI example was not very good.
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 ...
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 ...
I think 'groundbreaking AI' was used as an example of something which is (1) new and (2) requires efficient use of hardware. Of course you will need domain experts. But if the new idea requires infrastructure which has not been built and places high demands on the machine, then the project will require above average developers.
It sure helps if they are though.
I would rephrase it to: you need people great in tasks that you actually needs them to do.
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).
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).
> If you're doing _groundbreaking_ research in, say, AI or facial recognition or whatever, you may need people who are technical superstars.
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.
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.
> If you're doing _groundbreaking_ research
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).
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).
> If you are developing fundamentally new ML techniques (like the folks at Google)
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.
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.
[deleted]
"That sounds less like research and more like applying established tools (Tensor Flow or Keras or whatever). "
This is what most AI, ML and data science people do from my experience. It's really not that groundbreaking.
This is what most AI, ML and data science people do from my experience. It's really not that groundbreaking.
>...rinse-test-repeat kind of job... 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.
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.
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.
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.
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.
That doesn't seem to be what they are saying.
> minimal intellectual curiosity
I didn't see that specified.
> docile
Yes.
> does what they are told
Yes.
> works well with others
Yes.
I didn't see that specified.
> docile
Yes.
> does what they are told
Yes.
> works well with others
Yes.
The rest of your point aside, no matter what you're doing, "Works well with others" should always be high on the list. No one wants to work with an asshole.
>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.
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.
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.
You're describing an idealized theoretical team organization model with strict separation between the engineering manager, product manager, and developer roles. In the real world with highly productive teams those roles tend to blur together. In order to produce actual business value — not just churn out code to spec — developers absolutely need to be able to communicate clearly, empathize with customers, and collaborate with colleagues.
It's a sad state of affairs if you consider it "idealized" to be able to focus on your job and rely on others to do theirs.
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.
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.
A developer may also fail in communicating how much time will something take, explaining clearly to pm why is feature harder to implement or not feasible due to existing architecture. A developer may fail at asking questions clearly - so the pm don't even know what info is missing. He may be unable to explain why more time for refactoring is needed or why change of technology is needed.
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.
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.
>A developer may also fail in communicating how much time will something take
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.
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.
People with bad communication skills often think they are communicating big estimate, while no one else in the room got it from what they said. It happens. Or they refuse to hear when someone suggests easier solution or change of requirements so that it can be done faster.
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.
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.
>People with bad communication skills often think they are communicating big estimate, while no one else in the room got it from what they said.
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.
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 sad state of affairs if you consider it "idealized" to be able to focus on your job and rely on others to do theirs.
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.
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.
"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."
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.
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.
"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."
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.
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.
>Soft skills include things like being able to empathize with others, which is quite important for building usable interfaces
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.
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.
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.
I think you should rephrase this as "code that can't be explained to a junior developer". There certainly is legitimate code that is not easy to understand without knowing some background.
Really depends how bright is your "junior developer".
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.
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.
Not sure all rules are absolute. If you can write for the lowest common dominator you may not be writing anything overcomplex.
>if you write code that can't be understood by a junior developer
Only true for simple apps (i.e., CRUD, etc.)
Only true for simple apps (i.e., CRUD, etc.)
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!
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!
In my mind "the code is self-documenting" doesn't mean that you should have no comments anywhere in the code. It rather says that instead of lazily adding a comment for some complex piece of code, try to refactor the code so it better explains what is happening there.
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.
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.
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.
- 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.
Wrong. Machine code is for the computer. Human readable high-level languages were designed specifically for people.
Different newspapers write to different education levels. In your local paper you may find writing that a grade 8 student could understand. In your industry specific journal the writing may be at a grade 12 level.
Not all code should or can be human readable by all.
Not all code should or can be human readable by all.
Right, and some people will work in C, while others will work in Python. That doesn't quite line up with a "grade level", but I agree that different writing styles (or languages) suit different purposes best.
But I assure you, our computers would "think" that we are all idiots for using just about any high level language feature. We write things in loops (computer unrolls it), we give variables readable names so we can think about them (computer assigns it a memory address instead), and we build meaningful abstractions (computer sighs and turns it into meaningless 1s and 0s). So literally all high level languages are written for us feeble-minded HUMANS! Not for computers.
But I assure you, our computers would "think" that we are all idiots for using just about any high level language feature. We write things in loops (computer unrolls it), we give variables readable names so we can think about them (computer assigns it a memory address instead), and we build meaningful abstractions (computer sighs and turns it into meaningless 1s and 0s). So literally all high level languages are written for us feeble-minded HUMANS! Not for computers.
yeah. I've seen a lot of comments like:
// Sleep for 10 minutes
sleep(15*60)
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)
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.
I've found a better approach to comments is not to put them in at all.
Then, you raise a PR, have a code review, and whatever the other developer is confused about that you had to explain to them - that's where you needed a comment and what you explained to them is what the comment should be.
Developers who have their "head in the code" will almost always (unless they are very smart and very empathetic) fail to realize what is hard for other developers to understand because they will fail to accurately model to context which the other developer has.
Then, you raise a PR, have a code review, and whatever the other developer is confused about that you had to explain to them - that's where you needed a comment and what you explained to them is what the comment should be.
Developers who have their "head in the code" will almost always (unless they are very smart and very empathetic) fail to realize what is hard for other developers to understand because they will fail to accurately model to context which the other developer has.
And to keep with the theme of self-documenting, the self-documenting version of that would be:
NAP_LENGTH_MINUTES = 15;
...
sleep(NAP_LENGTH_MINUTES*60);Still not good enough. Why is this nap function in there? If I want to make it faster and didn't know, I would just remove all references to it. What did I break? Can't tell by that variable name.
a) Self documenting doesn't mean no comments
b) I didn't give enough context for your specific commentary to really make sense. I mean, when did I even say this is a function? It's a snippet of pseudo-code not a code sample.
c) Are you really running around programs ripping out references because you don't know what they do? I'd advise working on your definition of optimization before worrying about whether your code documents itself.
b) I didn't give enough context for your specific commentary to really make sense. I mean, when did I even say this is a function? It's a snippet of pseudo-code not a code sample.
c) Are you really running around programs ripping out references because you don't know what they do? I'd advise working on your definition of optimization before worrying about whether your code documents itself.
>Self documenting doesn't mean no comments
Agree. I assumed you were giving an example of self documenting code that doesn't require comments.
>I didn't give enough context for your specific commentary to really make sense. I mean, when did I even say this is a function? It's a snippet of pseudo-code not a code sample.
Yes, sorry. I've just spend the last month digging into shitty code, so I'm in dealing with shitty code mode. My point was the name you gave it didn't give any intent as to why the application would be napping, which is probably the most important information. Of course, as you said, the owner function could be named properly in that way.
>Are you really running around programs ripping out references because you don't know what they do? I'd advise working on your definition of optimization before worrying about whether your code documents itself.
It's pretty common for developers to try to figure out why an application is running slow. If I saw that (sleep function), it would be an obvious sign of why it's slow. If I saw that I would immediately see it as a potential target of improvement. Unfortunately with just the label you provided and a poorly named owning function, I wouldn't have enough information to determine if it was removable because, again, I don't know why it is napping. I would then have to spend several minutes/hours/days ($$$) determine what the hell that nap was for. This could all be solved by a comment providing intent.
I would suggest instead of NAP_LENGTH_MINUTES, it would be NAP_TO_AVOID_PROCESS_COLLISION_LENGTH_MINUTES or something. Of course, naming things properly is one of the hardest things in computer science. :)
There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton
Agree. I assumed you were giving an example of self documenting code that doesn't require comments.
>I didn't give enough context for your specific commentary to really make sense. I mean, when did I even say this is a function? It's a snippet of pseudo-code not a code sample.
Yes, sorry. I've just spend the last month digging into shitty code, so I'm in dealing with shitty code mode. My point was the name you gave it didn't give any intent as to why the application would be napping, which is probably the most important information. Of course, as you said, the owner function could be named properly in that way.
>Are you really running around programs ripping out references because you don't know what they do? I'd advise working on your definition of optimization before worrying about whether your code documents itself.
It's pretty common for developers to try to figure out why an application is running slow. If I saw that (sleep function), it would be an obvious sign of why it's slow. If I saw that I would immediately see it as a potential target of improvement. Unfortunately with just the label you provided and a poorly named owning function, I wouldn't have enough information to determine if it was removable because, again, I don't know why it is napping. I would then have to spend several minutes/hours/days ($$$) determine what the hell that nap was for. This could all be solved by a comment providing intent.
I would suggest instead of NAP_LENGTH_MINUTES, it would be NAP_TO_AVOID_PROCESS_COLLISION_LENGTH_MINUTES or something. Of course, naming things properly is one of the hardest things in computer science. :)
There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton
> 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.
While valuable, some people argue that they should be the same (granted, I mostly deal with high-abstraction language). For example most (all?) lisps have homoiconicity which means the computer and you see the code the same.
While valuable, some people argue that they should be the same (granted, I mostly deal with high-abstraction language). For example most (all?) lisps have homoiconicity which means the computer and you see the code the same.
Homoiconicity is irrelevant - comment text has no meaning to the computer but can do for the human. Computers have a hard time with "why".
A self-documenting code means we can (relatively) easily see what is being done by the program just by reading the program.
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.
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.
And the other side of the coin is that being too focused on documenting all of your code usually ends up with lots of out of date and confusing documentation over time.
>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
That simply means you're working with poor developers.
That simply means you're working with poor developers.
So you've never written code and come back to it 6 months later said said to yourself, "why did I do this?"
Many years ago yes, but not recently.
If you're a supposed "rock star" senior developer doing this it means you're just a bad developer. If you're a junior doing it just means you have some maturing to do.
If you're a supposed "rock star" senior developer doing this it means you're just a bad developer. If you're a junior doing it just means you have some maturing to do.
There are two kinds of that.
One is "wtf was I thinking", which comments won't help with.
The other is "where did the requirement come from", and that's (1) not a "cock-sure of themselves" sort of thing; and (2) best solved by putting a tracking number on the commit message, rather than traditional code comments.
One is "wtf was I thinking", which comments won't help with.
The other is "where did the requirement come from", and that's (1) not a "cock-sure of themselves" sort of thing; and (2) best solved by putting a tracking number on the commit message, rather than traditional code comments.
It's easy to lose yourself as a developer in problem-solving mode instead of looking at the big picture of a project. It's great to have people around you that reminds you the code is just a part of the more complex story - how to help your client solve a business problem.
It's better to lose yourself, IMO. I've been most productive when working with product managers who delivered crystal clear user stories and precisely ordered priorities and took pressure off me having to deal with "that side" of the business.
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.
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.
That is a hard lesson to learn; I'm still working on it decades in!
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.
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.
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.
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.
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 ahole because without them we'd be really screwed".
> 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.
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.
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.
If your business model is based on your employees being geniuses, then you probably have a wrong model.
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.
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.
I believe Spolsky summarized it as:
1. Smart.
2. Gets things done.Well that's a broad statement. We don't all need the same thing.
Tomorrow from Gamesutra: "Developers are dead. Good developers don't have to be your audience!"
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.
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.
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.
in my work experience, there are almost always one or two leads who dominate the conversation.
Why wouldn't you try to get the best developer you can pay for?
See "We only hire the best means we only hire the trendiest":
https://danluu.com/programmer-moneyball/
https://danluu.com/programmer-moneyball/
Because this industry keeps going on and on about a shortage of competent developers?
the real question is, can you afford Superstar Developers?
Yes because there's no real agreed upon definition of "super star" developer. So we're all super stars?
True, mostly. You might steel need few of them to lead by example.
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.