Steve Jobs on Average vs Best Software Developers
benlakey.com
benlakey.com
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?
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.
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.
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.
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."
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)
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.
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.
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.
In a way, a bit of neuroticism about your skill will help you. Complacency is a killer.
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.
Anyone who thinks they are an A player quite frankly isn't.
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.
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.
> 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).
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".
Pay them enough, give them an interesting problem, and lock them in a room with a bunch of other A players
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.
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.
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.
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.
As a side note, it looks like that video is also available on YouTube:
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.
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...
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.
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.
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 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.
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)
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.
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...
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).
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.
Strive to be A developers.
Sorry if it sounds too harsh, I personally classify myself as a B developer.
I suspect the ones at Apple develop iTunes for Windows
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…
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.
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.
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.
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.
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!
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.
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.
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
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?
Or not: http://contrastrebellion.com/
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
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.
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 ticks all these boxes is at least a B+ player in my book.
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 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.
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. :)