A bit of a meta question: As someone who feels like a 'B' or even 'C' at times, what would it take to become an 'A' player? Is it predicated on pure talent alone, hard work, or experience?
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?
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.
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.
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.
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 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.
Yes. A thousands times, yes! Some people find themselves to be the smartest person in the room and think, "I've made it!" Others, in the same situation think, "Time to move on..."
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 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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
I think it's fair to say that Woz was a 50:1 or 100:1 guy.
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".
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.
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.
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.
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.
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.
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?"]
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 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]
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:
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.
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.
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.
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.
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.
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...
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)
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.
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.
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.
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.
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.
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…
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.
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.
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.
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.
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.
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.
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!
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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. :)
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?