Steve Jobs on Average vs Best Software Developers(benlakey.com)
benlakey.com
Steve Jobs on Average vs Best Software Developers
http://benlakey.com/2012/07/04/why-you-need-to-hire-great-developers-part-2/
26 comments
I believe that the top trait in A players is the same as in the top founders, which is determination [1]. That determination often manifests itself as the desire to understand how something really works, rather than glossing over the details, the drive to learn a new language well enough to use it to implement ideas, to take on the learning curve for a new tool or system, to automate something, or to test their code before releasing it into the wild.
I've seen less-than-enthusiastic programmers who release shoddy work, expend more effort moving work onto other's plates that they'd expend just doing it themselves, let bad ideas stand without a fight, and never bother to keep up with changes in technology.
I've also seen very smart developers who've constantly been taken in by the latest shiny new thing to cross their path, think that testing is for the weak, and have no real determination to get something up and running completely.
If I have to be honest, I would describe very few of the developers I've worked with as "dumb". But many of them are either too passive [2], or lack the determination or desire to really compete a project.
One thing I've done to grow is to not try very hard to gloss over the details. Software is supposed to abstract away details, but it's too easy to think "I'll never learn that." or "Who cares what's under the covers? It just works." Understanding the subtleties isn't just an intellectual pursuit. Knowing the internals of a system allows a developer to know the limitations and strengths of a system, so it can be built upon or even repaired and improved.
1. http://paulgraham.com/determination.html 2. Sadly, in some situations, these are people who've simply been overwhelmed by the bureaucracy of their workplace. Fortunately, we are currently in a job seeker's market, and determined people can find better work conditions.
I've seen less-than-enthusiastic programmers who release shoddy work, expend more effort moving work onto other's plates that they'd expend just doing it themselves, let bad ideas stand without a fight, and never bother to keep up with changes in technology.
I've also seen very smart developers who've constantly been taken in by the latest shiny new thing to cross their path, think that testing is for the weak, and have no real determination to get something up and running completely.
If I have to be honest, I would describe very few of the developers I've worked with as "dumb". But many of them are either too passive [2], or lack the determination or desire to really compete a project.
One thing I've done to grow is to not try very hard to gloss over the details. Software is supposed to abstract away details, but it's too easy to think "I'll never learn that." or "Who cares what's under the covers? It just works." Understanding the subtleties isn't just an intellectual pursuit. Knowing the internals of a system allows a developer to know the limitations and strengths of a system, so it can be built upon or even repaired and improved.
1. http://paulgraham.com/determination.html 2. Sadly, in some situations, these are people who've simply been overwhelmed by the bureaucracy of their workplace. Fortunately, we are currently in a job seeker's market, and determined people can find better work conditions.
Good stuff, dabent. I agree; Abstractions are valuable tools, but it's important to know whats underneath the abstraction, for when the abstraction leaks, or when it's the wrong tool for the job.
> I believe that the top trait in A players is the same as in the top founders, which is determination [1].
Another important trait in the A players is that they are good procrastinators. Or as pg says it, they procrastinate to do "something more important."
Another important trait in the A players is that they are good procrastinators. Or as pg says it, they procrastinate to do "something more important."
That's not developers, that's life. Determination is the top predictor of success in... anything. It would even be a tautological statement if we couldn't look at others and predict determination levels before the success happens.
I don't really think determination is the magic ingredient. Personally I think the process of writing software is very similar to writing a song. (is anybody here also a songwriter)? Because if you try to write a song before you're ready, it just doesn't work no matter how hard you try, but once the idea has fully formed inside your head, it's as if the song writes itself, i think software is the same way. i remember hearing jobs talk about how a lot of the A players would also write poetry.
when i think of A players i always think of the musician who is able to improvise with another A musician instinctively, without needed time to rehearse. A players are able to communicate faster with each other than with B or C players. a so-called "A" player who has a big ego and can't play with others isn't actually an A player, but has managed to convince others (and himself) that he is.
seriously, if you want to become a better hacker, learn how to write a song, it's pure creation (or try painting, but songwriting is more creative imo)
when i think of A players i always think of the musician who is able to improvise with another A musician instinctively, without needed time to rehearse. A players are able to communicate faster with each other than with B or C players. a so-called "A" player who has a big ego and can't play with others isn't actually an A player, but has managed to convince others (and himself) that he is.
seriously, if you want to become a better hacker, learn how to write a song, it's pure creation (or try painting, but songwriting is more creative imo)
That's a pretty romantic way of putting it, but I agree mostly. You're dead on about so-called 'A' players who have big egos and can't communicate or play well with others; They might even be 'A' in terms of technical expertise but that's not the whole picture.
Fake it 'til you make it. Throw yourself at problems that you think are over your head. If you care and you want to do good work you'll figure out a way to get something done. Especially if you have a good mentor or someone that can guide you to answers to hard questions or take you under their wing.
Learn to effectively communicate and then communicate with your peers. You'll never know what you don't know unless you discover it (and there are only so many hours in a day), or you learn from other people. And you'll have an easier time trying to articulate your visions when you can communicate them effectively.
Don't worry about how good other people are. In fact, it's good to surround yourself with people that are more talented than you are, because it's easier to learn from them. Try to surround yourself with people smarter than you are. This is a lot easier if you contribute heavily to OSS or work in a product-focused group or company. It's pretty easy to let your skill set stagnate if your primary responsibilities are writing internal-use-only software.
Learn to effectively communicate and then communicate with your peers. You'll never know what you don't know unless you discover it (and there are only so many hours in a day), or you learn from other people. And you'll have an easier time trying to articulate your visions when you can communicate them effectively.
Don't worry about how good other people are. In fact, it's good to surround yourself with people that are more talented than you are, because it's easier to learn from them. Try to surround yourself with people smarter than you are. This is a lot easier if you contribute heavily to OSS or work in a product-focused group or company. It's pretty easy to let your skill set stagnate if your primary responsibilities are writing internal-use-only software.
Fake it 'till you make is time and time again proven itself to work, especially when you surround yourself with people smarter than yourself.
Are you sure "fake it til you make it" is the correct term for this idea? I'm familiar with the term, but usually in a different context.
Regardless, you're spot on.
My silly anecdote: Back in university I used to play pick-up two's volleyball a couple nights a week. At the other end of that same gym, the school team would practice, occasionally overlapping with the pick-up folks.
One day, their practice broke up around the same time as a game of sixes ended, so me & my partner wandered down and challenged a couple of the Team guys to a game of twos. It was quite memorable. 15-1, if I recall, and really not even that close. Pretty humbling, since we could certainly hang against anybody else we'd played up to that point.
But we stuck at it. Over the next couple months, we'd ask for games off those guys from time to time. 15-4. 15-8. 15-7. Then one day we lost 15-12. Fifteen to Twelve. Against a guy with a four foot vertical leap and a guy with one of those crazy olympic jump serves. Guys who were having their tuition paid for playing this sport. Wow.
And it's not like we went back and proceeded to dominate from there on out. Sure, we were better, but not that much better. We were better when we were playing better players. We were only playing that well because we were playing up to their level. It was quite a thing to see.
I've seen this same thing again and again over the years, particularly with Rock Climbing, where a group of people can attack a boulder problem that's way over any one of their abilities, and eventually get not just one guy over the top, but everybody, because of the group energy.
I can't see why it wouldn't be the same with programming.
Regardless, you're spot on.
My silly anecdote: Back in university I used to play pick-up two's volleyball a couple nights a week. At the other end of that same gym, the school team would practice, occasionally overlapping with the pick-up folks.
One day, their practice broke up around the same time as a game of sixes ended, so me & my partner wandered down and challenged a couple of the Team guys to a game of twos. It was quite memorable. 15-1, if I recall, and really not even that close. Pretty humbling, since we could certainly hang against anybody else we'd played up to that point.
But we stuck at it. Over the next couple months, we'd ask for games off those guys from time to time. 15-4. 15-8. 15-7. Then one day we lost 15-12. Fifteen to Twelve. Against a guy with a four foot vertical leap and a guy with one of those crazy olympic jump serves. Guys who were having their tuition paid for playing this sport. Wow.
And it's not like we went back and proceeded to dominate from there on out. Sure, we were better, but not that much better. We were better when we were playing better players. We were only playing that well because we were playing up to their level. It was quite a thing to see.
I've seen this same thing again and again over the years, particularly with Rock Climbing, where a group of people can attack a boulder problem that's way over any one of their abilities, and eventually get not just one guy over the top, but everybody, because of the group energy.
I can't see why it wouldn't be the same with programming.
Playing up to your opponent's level can happen in tennis too. One of the factors I think might be coming into play, especially in a sport like volleyball or tennis, is that your opponent is directly across from you and their play provides a mental model for you during the game. You can subconsciously mimic what they do, and their actions during the game act as a constant reminder for how to play well.
I noticed this snow skiing too. I had learned to ski when I was four and went multiple times a year every year, but I lived in Texas so it wasn't an everyday event. Then one mogul run I followed directly behind a more advanced skier, mimicking his moves and rhythm, and all of a sudden on that run it clicked -- my skill level shot up several folds.
I noticed this snow skiing too. I had learned to ski when I was four and went multiple times a year every year, but I lived in Texas so it wasn't an everyday event. Then one mogul run I followed directly behind a more advanced skier, mimicking his moves and rhythm, and all of a sudden on that run it clicked -- my skill level shot up several folds.
If you're interested in anecdotes about this, consider reading http://thedanplan.com/blog/ - Dan quit his job to learn to play golf, something he'd never done before. Currently he's at 3000 hours of practice...
That's a great story Jason. Thanks for sharing. I think this is precisely what happens in software development.
Believe in the you who believes in yourself. That's the accurate way of phrasing it.
That last bit is crucial - surround yourself with people smarter than you - otherwise you'll spend most of your time solving complex problems in inefficient ways, which could very much work against you.
My experience is somewhat limited to places that probably don't have the best developers in the world, but I think one of the major things I've noticed in people that I would consider to be mediocre programmers is a lack of desire to understand how something works. They just want to get the thing they need to work, and often times this lack of desire to understand how something works extends to their own code. If you strive to understand how your own code works, you will be much more likely to notice the bugs as you think through the flow.
Early on when I was learning to program, I had a very strong curiosity that made me want to understand how everything works. I think if you have that natural curiosity, it is the easiest way to become a better programmer. As I've gotten older, though, that has waned. In response, I've tried to build habits of investigating things and trying to learn about them when I don't understand them. It is tempting to just use google to find the answer, or "shotgun" it by trying all kinds of random things before you get it to work, but learning how it works is always the best, and it will pay off later.
So, I guess my main point here is to just keep tinkering and reading and getting your head wrapped around all these things so that you understand them well. Then things will eventually become "easy" and intuitive.
Early on when I was learning to program, I had a very strong curiosity that made me want to understand how everything works. I think if you have that natural curiosity, it is the easiest way to become a better programmer. As I've gotten older, though, that has waned. In response, I've tried to build habits of investigating things and trying to learn about them when I don't understand them. It is tempting to just use google to find the answer, or "shotgun" it by trying all kinds of random things before you get it to work, but learning how it works is always the best, and it will pay off later.
So, I guess my main point here is to just keep tinkering and reading and getting your head wrapped around all these things so that you understand them well. Then things will eventually become "easy" and intuitive.
I feel hopeless at times that I'll never approach being 'A' status especially knowing that I have many peers my age that are already far and away better than me.
There are many people who learned to code starting age 4 or 5 who are having rings run round them by people who learned to code in their 20s or even 30s. Age and experience are only components in a much larger, more complex equation.
While I can't provide much advice on becoming an "A" player, in terms of your outlook, stay eager, stay positive, and stay curious. People quit or fall into ruts all of the time (let's see where many of the dot com era folks ended up..) and still being "in the game" counts for a lot over the years. Everyone has doubts or moments where they feel out of their depth.. you just gotta keep plugging on.
There are many people who learned to code starting age 4 or 5 who are having rings run round them by people who learned to code in their 20s or even 30s. Age and experience are only components in a much larger, more complex equation.
While I can't provide much advice on becoming an "A" player, in terms of your outlook, stay eager, stay positive, and stay curious. People quit or fall into ruts all of the time (let's see where many of the dot com era folks ended up..) and still being "in the game" counts for a lot over the years. Everyone has doubts or moments where they feel out of their depth.. you just gotta keep plugging on.
Or they think they are running rings around them. Circle shaped rings, in an elliptical world. B/C players won't understand that... heh.
Questioning yourself is the first instinct of an A player. They don't believe they have all the answers, they believe that they are frauds in a lot of ways because they see the large picture and realize that they cannot hope to know all that is required to be an expert in all areas. Instead they become proficient in understanding the thought-processes that lead to expertise in multiple "specialized" fields and apply it to all areas of endeavor.
Anyone who thinks they are an A player quite frankly isn't.
Anyone who thinks they are an A player quite frankly isn't.
Agreed. The moment you consider yourself at the top, you no longer are curious/hungry to learn more.
Focus on building understanding.
In Coders At Work (http://www.codersatwork.com), Ken Thompson says, "When I was 30, 35 years old, I knew, in a deep sense, every line of code I ever wrote. I’d write a program during the day, and at night I’d sit there and walk through it line by line and find bugs. I’d go back the next day and, sure enough, it would be wrong."
Building things without deep understanding may produce a program, but it won't get you to A. Building understanding gets you to A. This is a deliberate process that takes time and work. You may not get all the way to A, but it will put you on the right path.
In Coders At Work (http://www.codersatwork.com), Ken Thompson says, "When I was 30, 35 years old, I knew, in a deep sense, every line of code I ever wrote. I’d write a program during the day, and at night I’d sit there and walk through it line by line and find bugs. I’d go back the next day and, sure enough, it would be wrong."
Building things without deep understanding may produce a program, but it won't get you to A. Building understanding gets you to A. This is a deliberate process that takes time and work. You may not get all the way to A, but it will put you on the right path.
You could almost argue that those who put the time and work in, are by definition the 'A' players. Even if you're not top dog in terms of technical expertise; If you've got the hunger and passion to know more you'll almost certainly succeed over time.
Look for a book called Topgrading, it's a methodology and defines A,B and C players.
Roughly from memory: A's are smart, get things done. The important thing is: An A player in one role may not be an A player in another role. If you put your best programmer at your retail store, you're probably going to have a bad time.
How do you overcome it? Find your passion, make sure you work with others that are A players (one trademark of A players is that they gravitate together), work on your skills and study peripheral ideas that could be implemented. If you're doing the above then youre probably an A player, if youre on Facebook half the day or complaining that someone didnt refill the coffee pot then you're probably not an A player in the role that you are in and you need to decide to train up or move somewhere where you can be an A player.
Roughly from memory: A's are smart, get things done. The important thing is: An A player in one role may not be an A player in another role. If you put your best programmer at your retail store, you're probably going to have a bad time.
How do you overcome it? Find your passion, make sure you work with others that are A players (one trademark of A players is that they gravitate together), work on your skills and study peripheral ideas that could be implemented. If you're doing the above then youre probably an A player, if youre on Facebook half the day or complaining that someone didnt refill the coffee pot then you're probably not an A player in the role that you are in and you need to decide to train up or move somewhere where you can be an A player.
Key question: Are your peers better than you due to experience or talent? In other words have they also been doing this for a year or several years? If they've been doing it for several years even though they're the same age as you they aren't your peers. By the way I suggest you check out the 10,000 hour rule: http://www.gladwell.com/outliers/outliers_excerpt1.html
I'm where oacgnol is at too. Just as an addendum to what he said, are there any pro programmers here who went from C to A? How much time did this take you? I feel like I struggled way too much to much to get basic computing concepts - netmasks, bitshifts, c pointers... Don't even get me started on how much javascript confounds me! :-D
There will always be people better than you, no matter how good you are. Realize this, and try to learn from them. While I can't tell you if you have the raw talent, constantly trying to improve is important.
In a way, a bit of neuroticism about your skill will help you. Complacency is a killer.
In a way, a bit of neuroticism about your skill will help you. Complacency is a killer.
The best way of becoming an 'A' player it to work closely with some of them. Accept a lower salary to be able to do that if necessary.
If you feel like some of your peers are ahead of you, you can try diversifying your skills. Most other 'A' developers suck at things like UX, design or even basic human interaction. Surpass them on those areas. By being a B as a developer + B as a UX person + getting things done, you will be welcome in an all A's team.
If you feel like some of your peers are ahead of you, you can try diversifying your skills. Most other 'A' developers suck at things like UX, design or even basic human interaction. Surpass them on those areas. By being a B as a developer + B as a UX person + getting things done, you will be welcome in an all A's team.
Try not worry about how you stack up in absolute terms, and think more in terms of relative accomplishments. It helps me when I have these thoughts too.
Hmm, "fake it till you make it" is not quite right - you can never "make it". You need to always learn AND learn how to learn as you go.
I agree that you need to let others know that you're an A (even if you think you're a B or C), but if internally you believe you "made it", you're already falling down, IMO...
Talk about stuff as you learn it (at your local user group or whatever). That way it forces you to consolidate what you are learning - plus you become viewed as an expert by the people who are learning from you (which of course you are, as you are a step ahead of them).
It's experience and a drive to self-improvement. I look at code I wrote even one year ago and wretch at it, itch to clean it up.
> it used to be the case in hardware
Jobs isn't saying A players are as common as straight-A students (it comes across that they are extraordinarily rare; it takes "incredible work" to find them), it's just that (as he plainly states), unlike in most other fields, instead of performing 30% better or twice as well, they can do x50 or x100 times as well.
Perhaps better examples are fields where output scales easily: e.g. one novelist can sell many more books than another. This performance is not related to not how quickly they type, but what they type. It reflects the old idea of "I'm sorry to write you such a long letter, I didn't have time to write a shorter one". The hard bit is in asking the right question, seeing the problem in the right way, redefining the problem - then, solving it is (comparatively) easy. It's about understanding what the problem actually is. Then, things can become radically simpler. Any sufficiently advanced understanding, if implemented as a technology, is indistinguishable from magic.
Programming dramatically rewards such understanding, because understanding can be realized so easily implemented in a working technology (i.e. a program).
IMO truly great developers are not just developers. They are also software architects, UX and UI designers, network engineers, etc. "A" developers knock down learning curves and assimilate everything about software creation innately.
This is absolutely the right answer. I would add that the BEST developers are those that have some business or project management background.
That way they can put what they are doing in the greater context of the organisation. As well as add a lot more weighting to maintainability and future flexibility over the "latest cool thing".
That way they can put what they are doing in the greater context of the organisation. As well as add a lot more weighting to maintainability and future flexibility over the "latest cool thing".
At this point you're getting a little overgeneral, I think. One of Steve Jobs' A players was undoubtedly Bill Atkinson, but what he lacked in business knowledge, he more than made up for in technical skills. If you're an A player working in one of Intel or Microsoft's compilers teams, you win based on deep technical knowledge, not understanding the "greater context of the organisation".
I think there is a lot of talk about hiring an "A" developer, but almost nothing on what makes an A developer an A developer. More likely than not, it a continuum, and that a lot of engineers have the potential to be an A, but don't end up getting there due to one reason or another. It would be great to see some discussion on what environment could one provide that would enable A players to thrive and reach their potential.
It would be great to see some discussion on what environment could one provide that would enable A players to thrive and reach their potential.
Pay them enough, give them an interesting problem, and lock them in a room with a bunch of other A players
Pay them enough, give them an interesting problem, and lock them in a room with a bunch of other A players
Most important don't drown them in office politics or unnecessary paperwork.
Pay is actually quite low on the list of things that a great developer will value when choosing where to work. And I think it's dangerous to just lock the A players in a room amongst themselves; they need to communicate closely with others in the organization, otherwise the value they try and add might be missing the target.
That's why I said "enough", not "a lot". Everybody has to eat food, have a place to sleep, etc.
I know, I was being somewhat facetious. More what I mean is, put them in a tight-knit group, and you are right- it is very important they interact with the rest of the organization too.
I know, I was being somewhat facetious. More what I mean is, put them in a tight-knit group, and you are right- it is very important they interact with the rest of the organization too.
it is someone who is working nights and weekends unbeknownst to whoever is grading developers. It's easy to create the rockstar illusion over a short time.
Other times it is money bias. If a dev makes a lot of money for someone they are considered an A developer without regard to ability.
Other times it is money bias. If a dev makes a lot of money for someone they are considered an A developer without regard to ability.
Plus A players have a tendency to care a lot more about their own knowledge that it allowed Steve Jobs to yell at them to improve their efficiency.
If Jobs yelled at a typical B player or corporate drone, they would just take it and go on and maybe sit at the bar wallowing in their sorrows.
With A players, Jobs would tap into their insecurity that they might not be smart enough causing them to want to learn more to close that insecurity which then allows then to produce a better product. Their fear that they may not be smart enough would cause them to become even smarter.
Jobs needed A players otherwise his "motivational techniques" would fall flat.
If Jobs yelled at a typical B player or corporate drone, they would just take it and go on and maybe sit at the bar wallowing in their sorrows.
With A players, Jobs would tap into their insecurity that they might not be smart enough causing them to want to learn more to close that insecurity which then allows then to produce a better product. Their fear that they may not be smart enough would cause them to become even smarter.
Jobs needed A players otherwise his "motivational techniques" would fall flat.
We hear this a lot and somehow feel it's true but there are no reliable metrics and little verifiable data so ultimately it's just talk.
Agreed, I'm getting kind of sick of these articles. It's like if the developer community here started posting fluff pieces about how you need to use the best programming languages and the most optimized frameworks.
Maybe I'm out of step with the recruiting community but are there people who are sitting around going "let's round up some really mediocre candidates?"
Maybe I'm out of step with the recruiting community but are there people who are sitting around going "let's round up some really mediocre candidates?"
[Maybe I'm out of step with the recruiting community but are there people who are sitting around going "let's round up some really mediocre candidates?"]
There are a lot of people going "let's round up the cheapest candidates we can find".
Said cheap developers will eventually wind up costing the company more than they make back.
There are a lot of people going "let's round up the cheapest candidates we can find".
Said cheap developers will eventually wind up costing the company more than they make back.
When you just need some CRUD stuff made in various spots of your big company, mediocre will be just fine. Yes, there are people who are sitting around doing this.
I agree. The more that this sentiment gets institutionalized the less value it has. Statements without a clear counterargument are always bothersome. Would someone like to make the argument for hiring B developers to build a great product? Jobs is great, but this is exactly the kind of quoting that I find really boring and annoying.
As a side note, it looks like that video is also available on YouTube:
http://www.youtube.com/watch?v=2nMD6sjAe8I
As a side note, it looks like that video is also available on YouTube:
http://www.youtube.com/watch?v=2nMD6sjAe8I
That's not the same video. It's a different interview entirely, from many many many years prior to the one referenced.
Would someone like to make the argument for hiring B developers to build a great product?
Are you offering that as a poor example of a counterargument? Because I think it's countering the wrong argument here. His point is not to hire A players because A players make great products.
His point is that A players in software development are unexpectedly significantly better than average players, when comparing to A players and average players in other industries. As such, anyone who is able to attract and work with A players in software development get an inordinate advantage over the competition.
I think the key word that defines his intentions is inordinate. If you can't work with A players, you may have already lost.
Are you offering that as a poor example of a counterargument? Because I think it's countering the wrong argument here. His point is not to hire A players because A players make great products.
His point is that A players in software development are unexpectedly significantly better than average players, when comparing to A players and average players in other industries. As such, anyone who is able to attract and work with A players in software development get an inordinate advantage over the competition.
I think the key word that defines his intentions is inordinate. If you can't work with A players, you may have already lost.
I would love to see some objective evidence on the distribution of productivity among programmers. Is the distribution really so skewed?
Further, if the distribution really is very skewed and A players are rare, then I would put forth that the A players are vastly underpaid.
Putting aside the productivity arguments, talking about the immense value you place on your employees while (possibly) conspiring with your competitors to keep salaries low is awfully unethical. [1]
[1] http://articles.businessinsider.com/2012-01-20/tech/30645933...
Further, if the distribution really is very skewed and A players are rare, then I would put forth that the A players are vastly underpaid.
Putting aside the productivity arguments, talking about the immense value you place on your employees while (possibly) conspiring with your competitors to keep salaries low is awfully unethical. [1]
[1] http://articles.businessinsider.com/2012-01-20/tech/30645933...
Thank you.
The first rule of Rockstar Developer Club is that you always talk about Rockstar Developer Club.
It certainly seems like there is an element of truth to the numbers, but I think they tend to be both drastically overstated (there are fewer cases where there is a drastic difference and/or the difference doesn't matter) and drastically understated (there are cases where one developer can accomplish something that another simply can't, making the difference infinite).
So much time is spent trying to point out and quantify this difference, often in an implicitly self-congratulatory manner, and I think it would be better off spending that energy on:
1) Figuring out how to quantify developer skill, or at least come up with roughly accurate ways to determine whether or not a developer is appropriate for a given task. We, as an industry, are pretty bad at this.
2) Figure out ways to move more developers from the B & C camps into the A camp, insofar as we can actually identify those distinct camps.
It certainly seems like there is an element of truth to the numbers, but I think they tend to be both drastically overstated (there are fewer cases where there is a drastic difference and/or the difference doesn't matter) and drastically understated (there are cases where one developer can accomplish something that another simply can't, making the difference infinite).
So much time is spent trying to point out and quantify this difference, often in an implicitly self-congratulatory manner, and I think it would be better off spending that energy on:
1) Figuring out how to quantify developer skill, or at least come up with roughly accurate ways to determine whether or not a developer is appropriate for a given task. We, as an industry, are pretty bad at this.
2) Figure out ways to move more developers from the B & C camps into the A camp, insofar as we can actually identify those distinct camps.
One of my mentors(Who also happens to be my Uncle) is a great guy. He is great Start upper, who has done some amazing things in Embedded electronics space. While making tons of money.
A while back, I saw him fixing some bugs in the code. I saw he had an editor open(Notepad basically). And I was like 'You still code?'. And he replied yeah, I like to do this work sometimes, sometimes not always. He told me he was not a very great programmer, but he had the quality 'To convert time into something which is useful and sell-able'. You will need to be good at programming to do that, but you don't have to be too great.
I think his advice and what I could take from him was, Never go fancy and too much into the tool religion. Begin with the end in mind, and execute. Do what it takes to achieve something. Be productive, plan and work on focused goals. Track and review your course. Getting a time table helps.
Provided you are productive you can learn and do anything. Focus on the big picture and try to solve problems that matter.
What will it take to be a great programmers. Its just the same thing that would take to be with any other profession. You have to just execute like crazy until you win.
Shipping and problems solved count. Everything else(Blogs, tweets, whining etc noise) is pointless.
A while back, I saw him fixing some bugs in the code. I saw he had an editor open(Notepad basically). And I was like 'You still code?'. And he replied yeah, I like to do this work sometimes, sometimes not always. He told me he was not a very great programmer, but he had the quality 'To convert time into something which is useful and sell-able'. You will need to be good at programming to do that, but you don't have to be too great.
I think his advice and what I could take from him was, Never go fancy and too much into the tool religion. Begin with the end in mind, and execute. Do what it takes to achieve something. Be productive, plan and work on focused goals. Track and review your course. Getting a time table helps.
Provided you are productive you can learn and do anything. Focus on the big picture and try to solve problems that matter.
What will it take to be a great programmers. Its just the same thing that would take to be with any other profession. You have to just execute like crazy until you win.
Shipping and problems solved count. Everything else(Blogs, tweets, whining etc noise) is pointless.
I've been a developer for more than five years now, and I met a lot of brillant people that are more than a 100 times better than me. I also saw code and people that are so bad that I would qualify as a A player... Compared to them. I'm probably more than a 100 times better than them. So in my opinion, in software development, there is a much wider range than 100:1, and if you feel like you're an 'A' player, you're probably overestimating yourself. Likewise, if you feel you're a 'C' player and are worried about it, don't worry too much, go on StackOverflow, answer question, learn to get better, and be confident that maybe you're not an 'A' player, but you're pretty good and will be a 100 times better by next year.
I normally don't participate in these threads, but I watched the interview yesterday and I think Steve Jobs did a masterful job of explaining this phenomenon and it is getting lost in this conversation.
Fundamentally, and he talks about this, computer programming is a way of encapsulating _your thinking_ in code. You are transferring your thought processes into computer code. A computer program is, quite logically, an encapsulated and packaged thought process.
I don't think anyone can or should try to argue that everyone thinks the same. Hence, not everyone's code is the same. And it follows that some people's thought processes are more efficient or better structured than others. These are the 50x'ers and 100x'ers. The A players. And I feel that just understanding that what you are doing is packaging your thought processes helps immensely in becoming more efficient, just because of the way you approach the problem.
People who are the 50x'ers, or 100x'ers, just solve problems very efficiently and are very good at packaging that problem solving logic in code. They are probably not as good as the 1x'ers in other areas of life--perhaps they are not as good at loving people, or raising children, or writing, whatever. They can be (and in my experience often are) not as good at a million other areas of life, many of which are far more important than programming. But they are very good at problem solving and transferring that problem solving logic into computer code.
I agree with Steve.
Fundamentally, and he talks about this, computer programming is a way of encapsulating _your thinking_ in code. You are transferring your thought processes into computer code. A computer program is, quite logically, an encapsulated and packaged thought process.
I don't think anyone can or should try to argue that everyone thinks the same. Hence, not everyone's code is the same. And it follows that some people's thought processes are more efficient or better structured than others. These are the 50x'ers and 100x'ers. The A players. And I feel that just understanding that what you are doing is packaging your thought processes helps immensely in becoming more efficient, just because of the way you approach the problem.
People who are the 50x'ers, or 100x'ers, just solve problems very efficiently and are very good at packaging that problem solving logic in code. They are probably not as good as the 1x'ers in other areas of life--perhaps they are not as good at loving people, or raising children, or writing, whatever. They can be (and in my experience often are) not as good at a million other areas of life, many of which are far more important than programming. But they are very good at problem solving and transferring that problem solving logic into computer code.
I agree with Steve.
The hard problems in software are not adding features or coming up with crafty efficient solutions. That is actually quite easy and I am constantly surprised how mediocre to poor developers can consistently come up with workable solutions.
The hard problem in software is writing code others can use. Everyone can write a solution that makes sense to themselves. Few can write one that makes sense to other developers. People who write code professionally will know what I mean. When you get someone else's work and realize it is better than anything you could have come up with. Not because it is extremely complex, but because it is perfectly simple.
I completely agree that people do not think the same. Where you went wrong is in believing an individuals thought process takes precedence over a teams. That is exactly the opposite of what is required and what software development spends a lot of time battling against.
The hard problem in software is writing code others can use. Everyone can write a solution that makes sense to themselves. Few can write one that makes sense to other developers. People who write code professionally will know what I mean. When you get someone else's work and realize it is better than anything you could have come up with. Not because it is extremely complex, but because it is perfectly simple.
I completely agree that people do not think the same. Where you went wrong is in believing an individuals thought process takes precedence over a teams. That is exactly the opposite of what is required and what software development spends a lot of time battling against.
I disagree... the highest-value problems are often VERY hard.
Think of things like natural language recognition, predictive analytics, statistical analysis, and so on. Things that seem like magic to the end user, that they've never seen before, are very hard before they're abstracted into something that B/C players can re-use. Woz, for example, worked some magic and packaged a computer circuit board into something that tons of less-talented people could build on. I would not even want to attempt what he did.
Yes, creating a feature like adding a Like button does not take complex thinking, but moving the needle forward significantly often does. I believe this is what Jobs was alluding to.
Think of things like natural language recognition, predictive analytics, statistical analysis, and so on. Things that seem like magic to the end user, that they've never seen before, are very hard before they're abstracted into something that B/C players can re-use. Woz, for example, worked some magic and packaged a computer circuit board into something that tons of less-talented people could build on. I would not even want to attempt what he did.
Yes, creating a feature like adding a Like button does not take complex thinking, but moving the needle forward significantly often does. I believe this is what Jobs was alluding to.
I feel like we are discussing this from very different perspectives. You raise hard computer science problems and a Woz example that is hardware related. The article was about software, not people who push the envelope of what is possible with computers.
If you are tackling problems like natural language recognition you don't need a superstar programmer. You need someone with a background in Computational linguistics.
Assuming we are discussing software. Hard computer science problems are, unfortunately, very infrequently brought up in a business setting. The biggest challenge in software is building the right thing. Change is inevitable and solutions are often large. This means you need to have teams of people working together building solutions that are very malleable.
Here is another way to consider it from my perspective. The article is about teams of 'A' players. I am guessing Linus meets your criteria, but you don't hire Linus. You don't have teams of Linus'. Linus is something else...
If you are tackling problems like natural language recognition you don't need a superstar programmer. You need someone with a background in Computational linguistics.
Assuming we are discussing software. Hard computer science problems are, unfortunately, very infrequently brought up in a business setting. The biggest challenge in software is building the right thing. Change is inevitable and solutions are often large. This means you need to have teams of people working together building solutions that are very malleable.
Here is another way to consider it from my perspective. The article is about teams of 'A' players. I am guessing Linus meets your criteria, but you don't hire Linus. You don't have teams of Linus'. Linus is something else...
Absolutely, but also bear in mind Next and Apple worked on some of the hardest problems in the industry. OS kernel design, languages and compilers, development frameworks. Now you can be an ace developer, absolutely A-grade, and be working on a web app in PHP but maybe in that case your leverage over an average dev might be say 10x. Whereas if the problem domain you're working on is something really critical like kernel scheduler design then an A-player might come up with a solution an average dev might never come up with. Not in 100x as long or even 1000x as long.
I don't think he (or steve) is wrong at all: a large part of the 50x comes from the fact that a smart individual can avoid the need for team work.
Although writing software in a way such that others can use it is certainly important, the network effect is the prevalent mechanism at work here (3 programmers need 3 times as much communication as 2 programmers; 4 programmers need 6 times as much communication; etc)
Although writing software in a way such that others can use it is certainly important, the network effect is the prevalent mechanism at work here (3 programmers need 3 times as much communication as 2 programmers; 4 programmers need 6 times as much communication; etc)
That's a good point that I missed. He even talks in the interview about small teams of A players.
The ultimate sophistication is simplicity.
Individuals, or small groups of them, do take precedence because they directly or indirectly make the major decisions. Teams of mostly C's usually don't know where they're going. Whether the team succeeds or not is dependent on if those few thinkers were really A's or just Type A.
Individuals, or small groups of them, do take precedence because they directly or indirectly make the major decisions. Teams of mostly C's usually don't know where they're going. Whether the team succeeds or not is dependent on if those few thinkers were really A's or just Type A.
I want to agree with you and with Steve.
But when Steve says things like this "if you go to New York City and get an average taxi cab driver versus the best taxi cab driver, you’ll probably get to your destination with the best taxi driver 30% faster. And an automobile; What’s the difference between the average car and the best? Maybe 20% ? The best CD player versus the average CD player? Maybe 20%"
I mean where is that coming from? The numbers are totally arbitrary. Where's the backup for that? That's not even the same as even saying "we had a trade show booth in the front at MacWorld and consistently did 30% better in leads then when our booth was in the back and anecdotally our friends reported the same rough advantage".
I'm not arguing that there aren't obviously programmers who blow the socks off of "average" programmers (or that this can't be proven). Or that an experience taxi driver will get you to where you are going faster. What I object to is the use of numbers as Steve did to prove his point when there is in fact no backup for those numbers. (Is there? If so I haven't seen it).
But when Steve says things like this "if you go to New York City and get an average taxi cab driver versus the best taxi cab driver, you’ll probably get to your destination with the best taxi driver 30% faster. And an automobile; What’s the difference between the average car and the best? Maybe 20% ? The best CD player versus the average CD player? Maybe 20%"
I mean where is that coming from? The numbers are totally arbitrary. Where's the backup for that? That's not even the same as even saying "we had a trade show booth in the front at MacWorld and consistently did 30% better in leads then when our booth was in the back and anecdotally our friends reported the same rough advantage".
I'm not arguing that there aren't obviously programmers who blow the socks off of "average" programmers (or that this can't be proven). Or that an experience taxi driver will get you to where you are going faster. What I object to is the use of numbers as Steve did to prove his point when there is in fact no backup for those numbers. (Is there? If so I haven't seen it).
I think he's trying to use numbers to illustrate his point, but he's not declaring anything empirical. When asking “Maybe 20%?” the implication is it is at most 20% better, but certainly not 50% and never 100% better.
This isn't quantifiable empirical evidence he's presenting. It's just what he's witnessed, and it's up to you to find out the same.
This. You've nailed it.
So what do B and C developers do? Not everyone can be in the A tier.
Wouldn't a better strategy for society be to focus on extracting maximum value and output from people of all capabilities? Just pay less capable people less, and give them smaller responsibilities.
Wouldn't a better strategy for society be to focus on extracting maximum value and output from people of all capabilities? Just pay less capable people less, and give them smaller responsibilities.
> "So what do B and C developers do?"
Strive to be A developers.
Sorry if it sounds too harsh, I personally classify myself as a B developer.
Strive to be A developers.
Sorry if it sounds too harsh, I personally classify myself as a B developer.
Sure but the reality is that there will always be B and C people, and sorry if it sounds harsh, but some people will never achieve A status. Someone's going to have to give them something productive to do.
I think it depends on what you're trying to achieve. For example if you're trying to pull off the iPhone in one year with 5 guys, it makes sense to spend time finding the best guys.
You can also try to find 15-20 decent guys, but there are benefits to smaller teams — lower communication cost, a potential compounding effect when smart people work together, etc…
You can also try to find 15-20 decent guys, but there are benefits to smaller teams — lower communication cost, a potential compounding effect when smart people work together, etc…
You're implying that what's being discussed is a zero sum problem. We're simply saying that 'A' players work best with 'A' players, and if you fight for that in your organization then you'll do great things. 'B' and 'C' players will still exist, absolutely, but you'd do well to avoid them when possible.
I think theoretically we cannot achieve a state where all players are A. If that happens, our standards would be raised so that there will be a new class of B and C players that used to be A players. The only way for everyone to be A is for everyone to be the same, and in that scenario the classifiers would be meaningless.
This all of course assumes that all humans are created with the same innate potentials, which is definitely not true.
We can encourage everyone to do their best, but you'll get problems if you push people beyond their natural abilities for example by giving a C player the responsibilities and expectations of an A player, which is what I think you're suggesting.
A "B" or "C" player can still be a hard worker, even if she's less capable. I'm not sure why it's necessary to avoid them. Apple still needs janitors, sales people, and other lower salary jobs. I think it applies to their engineering staff as well. Obviously down to a certain level of "C"-ness they probably shouldn't even be an engineer.
This all of course assumes that all humans are created with the same innate potentials, which is definitely not true.
We can encourage everyone to do their best, but you'll get problems if you push people beyond their natural abilities for example by giving a C player the responsibilities and expectations of an A player, which is what I think you're suggesting.
A "B" or "C" player can still be a hard worker, even if she's less capable. I'm not sure why it's necessary to avoid them. Apple still needs janitors, sales people, and other lower salary jobs. I think it applies to their engineering staff as well. Obviously down to a certain level of "C"-ness they probably shouldn't even be an engineer.
That's not what I'm suggesting at all actually. Again, you're implying this is a zero sum game, in which the world has nothing but 'A' players. Thats not what I've said.
Being a 'hard worker' is completely and totally irrelevant in software development. More input does not equal better output, which in software is the key.
Being a 'hard worker' is completely and totally irrelevant in software development. More input does not equal better output, which in software is the key.
I'm suggesting to each his own type of input. So the A players can work on the new iPhone, while the B and C players can do something less important.
most companies are based on B and C players, its one of the reasons that a lot of big companies have so many management layers.
I think that was one of the design goals of Java. (seriously)
that's true for any task that is mostly bound by intellect rather than something else. The cab driver can only drive so much faster / better than everyone else because he is constrained by the traffic and the car. In the case of pure intellectual pursuits like writing a novel, or painting, there is a vast difference between the masters and the average person. Same thing for programming, it's part art, part science, mostly constrained by intellect.
I'd say it applies even more to great developers. Good programming greatly multiplies a single person's work. When great developers get together and all understand a set of best practices along with bringing in unique individual talents, then their creative output will be exponentially better than a group of lesser programmers.
wouldn't that be the case with any sort of group project? i.e. hard sciences
The bureaucracy in the institutions doing hard sciences eventually wears down even the sharpest mind.
I'd say programming is most constrained by politics, management & technical debt.
His response reminds me a lot of what I have read in Valve's employee handbook (http://newcdn.flamehaus.com/Valve_Handbook_LowRes.pdf) in regards to their developer culture. By what I understand, Valve has established a self policing system in which every employee has complete autonomy over what they decide to work on or contribute to. Gabe Newell is emphatic about the flat hierarchy of Valve and its peer-review system that replaces the need for managers. I've struggled to understand why this has been successful for them as an influential video game company, but it appears Jobs' insight underlines a similar truth. Good developers are not only great problem solvers, but managers in themselves that comprehend the work needed to be done and are willing to work with those smarter than themselves to see it done.
Look at the story that was kicked around recently about the fired apple developer who snuck back in to complete his work. That's the way the best developers are. They are intensely passionate about their work, and very self-driven. You can't get them to stop working on projects they care about.
This is also how GitHub operates, but it's only viable if you have 100% 'A' players.
Is the meta-leaning here that you should not hire programmers in the Bay Area, until you can pay $120-200K + stock for experienced guys, and 80-90K for top college grads?
Maybe that sets a hard target when you know to grow your start-up to the third developer, when bootstrapping. Can you pay someone 100-200k per year? Time to grow.
Maybe that sets a hard target when you know to grow your start-up to the third developer, when bootstrapping. Can you pay someone 100-200k per year? Time to grow.
No. For one, that was said 10 or 15 years ago and things change. Second, talented engineers (like everyone) value a variety of things other than money. Finally, other competencies are becoming as important or more so than raw engineering for a lot of companies.
Agree. Financial compensation is actually often much lower on the list of things software developers value at a company, particularly when they are 'A' players. Solving problems, working with other 'A' players, and stretching ones abilities become more important. You do have to pay competitively though.
I think "you have to pay competitively" is true and pretty much negates the claim that financial compensation is low priority.
Video Game artists are 50 to 1, best to average. I've worked with 4-5 of best and 50-100 of the average. The best are prolific, get stuff done on or ahead of time and follow every technical detail required. They are technical enough to know what's needed to accomplish a given goal without needing to be hand held. Whether it's thinking through all the tiles need for a tile based 3/4 perspective game for making something beautiful with a limited polygon and/or texture budget.
They really do get way more done than the average artist. Unfortunately there just aren't enough of them so we do the best we can to help the average ones be as productive as possible and keep hoping to find more of the amazing ones.
They really do get way more done than the average artist. Unfortunately there just aren't enough of them so we do the best we can to help the average ones be as productive as possible and keep hoping to find more of the amazing ones.
As much as I enjoy the hilarity of psuedoscience and anecdotal evidence - this oft-repeated plug has become tiring.
Will someone (other than Steve McConnell) who parrots these numbers ad nauseum please provide some evidence for your claims? Really, the best car is only 20% better than the average car? In what way? Define the best? Please, go on, explain your methodology.
Do the people who continue to spew forth this gibberish actually claim to have education and credentials of a scientific persuasion? Do they actually consider themselves professionals in a field that requires logical and critical thinking skills? Barf!
Will someone (other than Steve McConnell) who parrots these numbers ad nauseum please provide some evidence for your claims? Really, the best car is only 20% better than the average car? In what way? Define the best? Please, go on, explain your methodology.
Do the people who continue to spew forth this gibberish actually claim to have education and credentials of a scientific persuasion? Do they actually consider themselves professionals in a field that requires logical and critical thinking skills? Barf!
You can see the Lost Interviews on Youku:
http://v.youku.com/v_show/id_XMzU4OTExMjY0.html
http://v.youku.com/v_show/id_XMzU4OTExNjEy.html
http://v.youku.com/v_show/id_XMzU4OTExMzk2.html
http://v.youku.com/v_show/id_XMzU4OTExMjIw.html
http://v.youku.com/v_show/id_XMzU4OTEwOTcy.html
...
http://v.youku.com/v_show/id_XMzU4OTExMjY0.html
http://v.youku.com/v_show/id_XMzU4OTExNjEy.html
http://v.youku.com/v_show/id_XMzU4OTExMzk2.html
http://v.youku.com/v_show/id_XMzU4OTExMjIw.html
http://v.youku.com/v_show/id_XMzU4OTEwOTcy.html
...
You can also see them here:
http://www.amazon.com/gp/product/B008GJVAW4/ref=as_li_ss_tl?...
What amazed in those kind of post, is that people who actually work in the industry are not bother by the actual lack of evidence in those kind of claim.
I respect the opinion of Ben Lakey and Steve Jobs but they are opinions not laws.
I mean seriously, regardless of the job or the level of awesomness of someone, who likes to work with incompetent collegues ?????
They are thousands of bad developpers out there ? Seriously ? How do you judge ?? How do you know ??
Personally I know tons of developpers who works on awesome things at home but do shit at work 365 days a year. Simply because that is what is required of them. Careful here, I am not saying that, this is the case for everyone and that I have explained everything. I'm just saying that it will be nice if in our industry we stopped putting so much ego in everything we are doing. If you are a A, A+, A++, S++X37 developper good for you, truly.
From my little experience ( ~= 5 years ) there is not much state of the art project going on in the industry. Most project sucks from a technical point of view.
Also from my little experience, recruitment is fucking hard. Ask Google.
I mean seriously, regardless of the job or the level of awesomness of someone, who likes to work with incompetent collegues ?????
They are thousands of bad developpers out there ? Seriously ? How do you judge ?? How do you know ??
Personally I know tons of developpers who works on awesome things at home but do shit at work 365 days a year. Simply because that is what is required of them. Careful here, I am not saying that, this is the case for everyone and that I have explained everything. I'm just saying that it will be nice if in our industry we stopped putting so much ego in everything we are doing. If you are a A, A+, A++, S++X37 developper good for you, truly.
From my little experience ( ~= 5 years ) there is not much state of the art project going on in the industry. Most project sucks from a technical point of view.
Also from my little experience, recruitment is fucking hard. Ask Google.
You'll notice that I didn't talk about managment and the value that companies put (or don't put) in IT ...
I believe there are many A players who perform on B or C level because they are managed by B or C players. Steve Jobs was an A-level CEO, who knew how to inspire his employees and ignite their potential to be 50 or 100 better. Not many CEOs are like that.
If an A-level developer can perform 50x or 100x better than average, I'd guess that an A-level CEO can perform 500x or 1000x better.
If an A-level developer can perform 50x or 100x better than average, I'd guess that an A-level CEO can perform 500x or 1000x better.
The most important thing when trying to become an 'A' player in anything is to always ensure you're engaging in deliberate practice. The simple truth is that a very large majority of people switch to auto-pilot or stay within their comfort zone as soon as they become proficient at something. It's easy to think that the existing 'A' players were just born that way, when in fact they probably spent thousands of hours in deliberate practice. It's very hard to find an exception to this.
So if you do want to become an 'A' player:
- Figure out a way to always be deliberately practicing.
- Always be aware of whether you're doing something because you've always done it, or whether because it actually is the best way.
- Be around other 'A' players and learn from them.
- Continually stretch beyond your comfort/"knowledge" zone.
- Continually learn new things.
-----
Some reading material on the topic:
Bounce by Matthew Syed
Talent is Overrated by Geoff Colvin
So if you do want to become an 'A' player:
- Figure out a way to always be deliberately practicing.
- Always be aware of whether you're doing something because you've always done it, or whether because it actually is the best way.
- Be around other 'A' players and learn from them.
- Continually stretch beyond your comfort/"knowledge" zone.
- Continually learn new things.
-----
Some reading material on the topic:
Bounce by Matthew Syed
Talent is Overrated by Geoff Colvin
I think it's not the right metaphor. In class, the difference between an A and a B is 10%. In, say, Chess, the difference between a master and a grandmaster is that a grandmaster will win almost every time. I think that's a better scale.
Off-topic, this is one of the most readable sites I've ever visited. What is it, exactly, that makes that typesetting so pleasing to the eye?
Five reasons:
1. Proper line height
2. #404040 for text color instead of #000
3. webkit-font-smoothing: antialiased;
4. text-rendering: optimizeLegibility;
5. Steve Jobs quote
Wow is this guy a designer?
1. Proper line height
2. #404040 for text color instead of #000
3. webkit-font-smoothing: antialiased;
4. text-rendering: optimizeLegibility;
5. Steve Jobs quote
Wow is this guy a designer?
A designer would probably be a bit more consistent with the vertical grid. For instance, the margins are inconsistent with the line height etc.
I kid, a baseline grid is the least of his worries.
I'm most definitely not a designer. :-) If you're interested, it's just the 'Responsive' wordpress theme. http://wordpress.org/extend/themes/responsive
It's a standard open source wordpress theme, one of the popular ones: https://wordpress.org/extend/themes/responsive
My guess is that the color: is set to #404040, not black. Most people aren't aware that pure black is hard on the eyes; a slightly grey black is much more readable.
Can you or Alex expand on this? I'd especially want to know if this was true on non-white backgrounds.
Yes its especially true for non-white backgrounds. It all has to do with contrast. With black on white we have 100% contrast, if we use dark gray on light gray the contrast becomes say 70%. The lighter the contrast the easier it is on the eyes. Here's a quick example of what it looks like.
http://cl.ly/1p103C2z1N220L1W213l
http://cl.ly/1p103C2z1N220L1W213l
> The lighter the contrast the easier it is on the eyes.
Or not: http://contrastrebellion.com/
Or not: http://contrastrebellion.com/
Interesting link, but you're missing the point. The website even misses on their points. Most of the bad examples fit under an acceptable contrast ratio, by the standards given in their research, and even their good examples are not pure #000 or #fff. The w3c states that a minimum level of 3:1 works for people with 20/20 vision and 7:1 achieves the Triple-A standard. To show you what it looks like.
http://cl.ly/0J3Q210X142x1h2m1G2v
for reference http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contr...
and contrast tool http://www.snook.ca/technical/colour_contrast/colour.html
http://cl.ly/0J3Q210X142x1h2m1G2v
for reference http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contr...
and contrast tool http://www.snook.ca/technical/colour_contrast/colour.html
I think this 100x rule is not unique to software. Consider athletes for example. The best athletes are much much better than the merely very good. For example, the top tennis player would defeat the 500th best every single time barely losing a single game. And the world no. 500 would defeat a good amateur 6-0 6-0 (as David Foster Wallace found out).
I think you're right about the disparity applying elsewhere, but I disagree with your example of athletes. Beating an opponent consistently is not the same as beating an opponent by a factor of 50. For example: I'm no sprinter, but Usain Bolt runs less than 2x faster than me. And there are thousands of athletes who are a few percent slower than the best. They don't even get to the Olympic qualifiers.
On the other hand, I've seen productivity vary drastically among knowledge workers. It would be interesting to see studies involving actual numbers, since I think 10x between average and best is an exaggeration. Worst and best, maybe. But a lot of that is because the worst programmers can cause more problems than they solve.
On the other hand, I've seen productivity vary drastically among knowledge workers. It would be interesting to see studies involving actual numbers, since I think 10x between average and best is an exaggeration. Worst and best, maybe. But a lot of that is because the worst programmers can cause more problems than they solve.
I'd argue that in the case of something like sprinting, looking at it in a linear way isn't going to get you much. I don't know much about it, but it seems to me that every time you cut X seconds off your time, it's that much harder to get down to X2. If you looked at it from some sort of a logarithmic basis, I find it really unlikely that Usain Bolt is just* 2x faster than you.
(I'm not really sure why I felt the need to write this rant. It was an itch I had to scratch.)
It may surprise you, but healthy adults don't differ much in terms of physical ability. If you measure watts output or steps per second or anything quantifiable, it's going to be less than an order of magnitude difference, never mind a 100x difference.
I can run 100 meters in 15 seconds. That's 6.7 meters per second. Usain Bolt can run 100 meters in 9 seconds. That's 11 meters per second. 11.11/6.67 = 1.67 times faster. If Usain could somehow cut 5 seconds off his time and do a 4-second 100 meter dash, he'd be moving along at 25 meters per second. That isn't quite 4x faster than me. Such a feat would certainly be much more than 4 times as impressive as me running, but it wouldn't be more than 4 times as fast.
If you used some other yardstick, you could come up with some other number. Usain Bolt is the fastest sprinter alive. That makes him one in 7 billion. There are likely millions of faster runners than me. I'm maybe one in 100. 7 billion divided by 100 is 70 million, therefore Usain Bolt is 70 million times better at sprinting than me.
Sound silly? I think so too.
When measuring programming ability, we don't grade on a curve. It doesn't matter how much (or little) effort you had to expend. All that matters is the result and how long it took.
It may surprise you, but healthy adults don't differ much in terms of physical ability. If you measure watts output or steps per second or anything quantifiable, it's going to be less than an order of magnitude difference, never mind a 100x difference.
I can run 100 meters in 15 seconds. That's 6.7 meters per second. Usain Bolt can run 100 meters in 9 seconds. That's 11 meters per second. 11.11/6.67 = 1.67 times faster. If Usain could somehow cut 5 seconds off his time and do a 4-second 100 meter dash, he'd be moving along at 25 meters per second. That isn't quite 4x faster than me. Such a feat would certainly be much more than 4 times as impressive as me running, but it wouldn't be more than 4 times as fast.
If you used some other yardstick, you could come up with some other number. Usain Bolt is the fastest sprinter alive. That makes him one in 7 billion. There are likely millions of faster runners than me. I'm maybe one in 100. 7 billion divided by 100 is 70 million, therefore Usain Bolt is 70 million times better at sprinting than me.
Sound silly? I think so too.
When measuring programming ability, we don't grade on a curve. It doesn't matter how much (or little) effort you had to expend. All that matters is the result and how long it took.
Anyone who aspires to do their job better, wants to learn, hangs out in places like Hacker News and Stack Exchange, takes an interest in at least reading about new ideas, loves what they do, and has an upbeat attitude...
...anyone who ticks all these boxes is at least a B+ player in my book.
...anyone who ticks all these boxes is at least a B+ player in my book.
Considering this is a man who's built one of the world's most successful computer software and hardware companies, I think it's safe to say he knows whereof he speaks. And we can put this question to rest.
And I think the exact number or ratio is not important, and probably not measureable. But I bet anyone who's been around long enough, exposed to wide enough variety of programmers, will agree that there is a wide range of skill & talent. But of course when it comes to pay, salary-wise, working for somebody else, there really isn't. And that's a shame. Or at least an inefficiency.
And I think the exact number or ratio is not important, and probably not measureable. But I bet anyone who's been around long enough, exposed to wide enough variety of programmers, will agree that there is a wide range of skill & talent. But of course when it comes to pay, salary-wise, working for somebody else, there really isn't. And that's a shame. Or at least an inefficiency.
I admire and respect Steve Jobs as a businessman. I don't admire and respect him as an engineer, and certainly don't admire and respect him as a scientist. The differences are subtle and staggering all at once.
I disagree that the question can be put to rest. Your logic follows from a fallacy known as 'Argument from Authority' or 'argumentum ad verecundiam'.
I understand that the comments on this board are derived from a wide variety of individuals, where there is a wide range of skill and talent. I completely agree with your 2nd paragraph.
I disagree that the question can be put to rest. Your logic follows from a fallacy known as 'Argument from Authority' or 'argumentum ad verecundiam'.
I understand that the comments on this board are derived from a wide variety of individuals, where there is a wide range of skill and talent. I completely agree with your 2nd paragraph.
Don't think in terms of "the rules of debate". Think in terms of evidence, experience and analysis. What I'm saying, and I think the place that Steve Jobs was speaking from, and I think others are speaking from, is from actual direct experience with lots of folks in the real world. Forget proper "data". Forget authority, personally. What I was saying was, look, for the folks that do need an appeal to authority (because they have no experience themselves, or can't do the analysis themselves) the Jobs quote should be money for them. And it doesn't matter whether Jobs was an engineer or not. He worked closely with and led, and hired/fired hundreds of engineers over the years, starting with the Woz himself, and so he's seen firsthand the variety out there in terms of talent, knowledge, skill, attitude, work ethic, etc. It's irrelevant whether he's an engineer or scientist. By being an entrepreneurial business guy in the computer field over the course of 30+ years, at the helm of a company that "kicked ass and took names" in at least two distinct periods under his watch, there's a reasonable case to be made that he knows whereof he speaks. Could he be wrong? Could he be stupid? That's not the smart way to bet.
Also, related: one doesn't need to cite data or academic papers or construct airtight debate-worthy logical arguments to reach conclusions like, gosh, pizza comes in a wide variety of topping mixes, flavors and quality levels. Just experience a bunch of different pizza over the years! Done. :)
Also, related: one doesn't need to cite data or academic papers or construct airtight debate-worthy logical arguments to reach conclusions like, gosh, pizza comes in a wide variety of topping mixes, flavors and quality levels. Just experience a bunch of different pizza over the years! Done. :)
[deleted]
Even though I know I'm still a junior developer (~1 yr exp), I feel hopeless at times that I'll never approach being 'A' status especially knowing that I have many peers my age that are already far and away better than me. How would I overcome that?