From what I've seen, there's just no crossing the skill chasm as a software developer. You've either got it, or you don't. No amount of putting your nose to the grindstone will change that.
What a scary thought. Good thing it's not true.
One of the many reasons I became a programmer was that the sky was the limit. Still is. Want to learn something new? Learn it. Want to build something cool? Build it. The only real limitations are your belief that you can do it and your willingness to perservere until you do.
We are not like basketball players or musicians or chess masters where only the extremely gifted (who also work hard) can rise to the top of their craft. With few exceptions, we all can.
I didn't always think this way. I had a college math professor who once said, "Many of my students are simply not suited for the sciences." And I was stupid enough to believe him! In retrospect, his comment said more about his weakness as a teacher than anything about his students.
How do I know this? Because I learned the hard way. When working with my first mentor, I was always too quick to blame someone else for their limitations slowing progress. Until he said, "So teach them!" He believed that almost anyone can learn and get good at almost anything. This seemed counterintuitive but after a while, I was able to adopt this belief system, and it has made all the difference.
There are many reasons why so many programmers suck, but "not being able to cross the chasm" isn't one of them. Just a few of the real reasons:
- They never learned right in the first place.
- They never built anything of real substance.
- They were a tiny cog in a machine and never saw the big picture.
- They got pigeon-holed into a small area for a long time.
- Other things in their life took over.
- They had shitty teachers.
- They had to build on top of pre-existing shit and couldn't do it right.
- They were stuck in environments where excellence never mattered.
- They went into management too soon.
- They got trapped into old technologies and methodologies.
- They made too much money to make a career u-turn.
- They just didn't care enough.
- <add your own>
My programming has always gotten better every year. Sometimes I read my old code and can't believe I wrote it. And I still have tons of room for improvement.
I'm firmly convinced that almost any of us can get better, much better. And even become "elite", whatever that means. Please don't listen to anyone else who tells you otherwise.
We are not like basketball players or musicians or chess masters where only the extremely gifted (who also work hard) can rise to the top of their craft. With few exceptions, we all can.
I have no idea why, in the same breath as you disclaim the necessity of inborn talent for computer programming, you reaffirm that necessity for some arbitrary skills that you plucked out of nowhere. You have exactly the same amount of evidence supporting your claim that anyone can become a great programmer that I do to support the claim that anyone can be a chess master.
OK, but the reference to athletics is valid. There are outliers -- Muggsy Bogues or Dustin Pedroia -- but there's a reason that most professional pitchers are 6'2''. You can't get taller, no matter how hard you try.
It is from Outliers by Malcolm Gladwell. In this book he suggests that this happens because at a young age these kids born in January have an age advantage over their peers.
During adolescence physical development can be a substantial advantage and one born in January compared to another born in August will be physically different in terms of development.
Therefore, they are better from the start due to physical advantage. This results in more coaching and more attention, therefore they are encouraged to progress further in baseball.
The highest ranked player in the world is twenty years old. Any local chess club is full of people who have studied the game for years but failed to break 1400. I've taught people who were just incapable of the most rudimentary strategic thinking and people who just naturally saw things that it took me years to learn.
The evidence is clear that there are people in the world who just can't solve FizzBuzz, many of them people with degrees in CS. Some people just seem unable to grok the basic abstraction of programming. What if that isn't a binary state, but just one extreme of a spectrum?
I can run 10k in 40 minutes any day of the week, but I sprint like an asthmatic Samoan. I just have distance genes, nothing I can do to change it. No amount of training would ever make me a competitive sprinter. I've got too little fast twitch fibre, I'm too short, too lean, my heart and lungs are too small. Is it completely implausible to suggest that there are cognitive equivalents that would pertain to programming?
Why couldn't mental stamina be as genetically ingrained as physical stamina? There are obviously natural geniuses in our field, why not natural dunces?
"Why isn't writing software like chess or sport?" ... "There are obviously natural geniuses in our field, why not natural dunces?"
Precisely because 5-standard-deviation-above-average natural talent isn't required for success in our field. There's only one chess champion in the world and a handful of grandmasters, by definition, and those are gonna be the ones with talent and hard work. But to succeed as a programmer requires more work than genetic luck. An average person can probably do it with enough work.
(But I would point out there is, by necessity, a floor of base talent required somewhere. But it isn't necessarily as high as commonly supposed.)
"There's only one chess champion in the world and a handful of grandmasters, by definition, and those are gonna be the ones with talent and hard work."
There are in fact over 1000 grandmasters.[1]
Originally there were just 5, but as you can see, over time the ranks of grandmasters have swelled.
Many in the chess world lament that it's too easy to attain (or even buy) a grandmaster title these days, and that it doesn't mean nearly as much these days as it used to.
In a world of 6 billion people, 1000 is metaphorically a handful, as far as I'm concerned. In the context that we're talking about, there's certainly more than 1000 "good programmers".
Because it is a multidimensional profession rather than rather fixed task?
Programming is hard, harder than anything else you could possibly do. But because it is so hard, an important task for any programmer is to know their limitations and work around their limitations - master the skill of software engineering.
Just consider, the things that "only a few people can do", like playing 2800 chess, are turning out to be what a computer can more easily accomplish. Whereas the things "any idiot can do", like speaking English, are turning out to the things that computers have a really hard time doing.
In this sense, if programming is a "humanistic" field, it seems like many people and kinds of people can achieve excellence in it. But naturally this depends on what an organization cultivates.
"Why couldn't mental stamina be as genetically ingrained as physical stamina? There are obviously natural geniuses in our field, why not natural dunces?"
Are there really natural geniuses? To me a natural genius is someone who from the start performs at a high level, and I don't know of any such programmers. Maybe it's just that some people can move faster on the growth curve than others, but everyone can reach the same high echelons with perseverance?
But isn't 'moving faster on the growth curve' exactly what it means to be a natural genius? Mozart didn't pick up the violin and instantly compose symphonies, but his talent helped him pick it up at an early age.
And aren't you assuming that everyone's rate of improvement is necessarily going to be fast enough, in the long term, for them to reach 'high echelons' (or even a reasonable level of competence) before they die of old age?
I have. Some people were nearly incapable of grasping the matter. Others could do it as easily as buttering a sandwich. I do not believe it is always a question of circumstance, but a question of an innate, inbuilt ability. Some people can and did rise above their personal weakness, through hard work and study.
Required classes to finish a bachelor's in CS or IT, I'm guessing. I've taught programming to a couple hundred college students (or more) and I agree that the aptitude seems to either be there, or not.
I can relate this to a game of Table Tennis. A guy I know played lousy for two decades, his technique never improved. Then one day he got hold of a masterful neighbor who taught him how to play, hit top spins, do spin serves, hit chops. He participates in amateur tournaments now and does fairly well.
It's funny how someone like Bill Gates or your college math professor can make the observation that many people just aren't as good at some thing as others and you decide they're simply idiots, but you, who have accomplished so much and acquired so much wisdom, know differently.
When I was a kid, I played soccer every day, as often as I could. I loved it. And I never got particularly good. But when I started programming I was soon better than my peers, my teachers, and anyone I knew or could find to talk to.
It's hard for you to be wrong. If someone with zero programming talent does become really good, you could just say that they did have talent after all.
Let's make a baseball analogy. Do you think a person with no hand-eye coordination can become a great hitter?
I have no doubt there are people who are math averse who have plenty of untapped math ability (e.g. most women with math ability have been taught to think they can't do math). There are plenty of psychological reasons why a person who is capable of doing something might think they have "zero talent", and it's perfectly plausible for a good mentor to help them unlock their ability. But that's a far cry from the argument that "anyone can be a great programmer".
It’s a project in transformation. An experiment in potential and possibilities. Through 10,000 hours of “deliberate practice,” Dan, who currently has minimal golf experience, plans on becoming a professional golfer. But the plan isn’t really about golf: through this process, Dan hopes to prove to himself and others that it’s never too late to start a new pursuit in life.
I've been experiencing such a crisis of confidence recently around the idea that I lack talent, so much so that I've felt like there was no point in trying to improve things beyond where they are, or to even risk being criticised that it's totally frozen me up.
Please don't make the mistake of assuming this discussion applies to you. The subject has nothing to do with honing one's programming skills. [Edit: oops, I confused this thread with another. Never mind, the real point follows.]
As for crises of confidence, what makes them tough is that they opportunistically seize on every item that floats through consciousness and turn it into some new weapon to batter you with. One thing I found helped is to give up on the idea of "talent" altogether and just focus on things that interest you and give you pleasure (edit: and best of all, have value to others) whether or not you have any talent at all.
Actually, someone who really lacked talent probably wouldn't feel the way you describe. They'd just drop out of the game and rationalize it as "that stuff sucks anyway". So you probably do have talent, but the state you're describing is not one that can accurately assess anything remotely related to the idea. In such a state, it can actually be creatively liberating to just redefine yourself as a fool and get on with it. It's like when you're sitting by a swimming pool enjoying the sun and someone starts splashing you with water. If you can't get them to stop, a good defense is to just jump in the pool.
"The subject has nothing to do with honing one's programming skills. It has to do with a large segment of the population (one of the "humps" in "double hump") who can't grasp even the very first, simplest things about programming, like defining a function."
In this blogpost Jeff Atwood is specifically NOT talking about people who can't grasp the first thing about programming:
"We already know there's a vast divide between those who can program and those who cannot.
But the dirty little secret of the software development industry is that this is also true even for people who can program: there's a vast divide between good developers and mediocre developers. A mediocre developer can program his or her heart out for four years, but that won't magically transform them into a good developer. And the good developers always seem to have a natural knack for the stuff from the very beginning."
I'm firmly convinced that almost any of us can get better, much better.
I'm totally in agreement with you about that. However, for professional success in many fields (not just sports), the game is relative ability. While I'm convinced everyone can get better, what really matters in the context of finding jobs is whether you are catching up with everyone else or sliding further behind.
I'd like to believe this, but it's not my experience. There are people for who it comes effortlessly, while it's a real uphill battle for others.
Most of your listed problems are part of 'not being able to cross the chasm'.
The whole idea that we try so hard to believe in "Everybody is born equal and we are the masters of our destiny" maybe be evolutionary in nature .I was reading a book introducing evolution (and I forget the name but can dig it up if somebody wants the source) that individuals of a species sometimes start working together in such cohesion that they no longer are really individuals but are combined into one "social organism" if you will.
For example Bees ,though they are made up of individual bees they don't cross compete but actually work together to protect the whole group and it makes sense to look at the group as one entity instead of a bunch of individual bees.
The author of the book argued that human beings also have crossed that line from being individual members of a species to being a "social organism" that functions as one and in this scenario it really hurts to have a few select individuals born "better" than the rest.This is because we no longer are cross competing but are trying to optimize as a whole and it doesn't makes sense when you are doing that to have some people have better chances of survival etc as it will ruin the cohesion
Now I highly doubt if we are really born equal but that is just my opinion, from what I have seen around some people clearly were better than the rest in certain things even with other factors being more or less alike
Your notion about bees cooperating isn't the accepted view in modern biology. The Selfish Gene does a good job of explaining why this isn't the case, there's a lot of competition going on within a bee hive.
I got the opposite idea from that book. I remember it explaining that ants (or perhaps it was something else) would cooperate because often they all had the same DNA, and so were working to propagate the same genes.
I'd like to agree but do you honestly believe someone like, say, Paris Hilton could become a good programmer? Because unless I'm mistaken, it seems you are arguing for that.
I believe sometimes, some people, just aren't suited for a particular craft. And there's nothing wrong with that. It's a good thing that everyone has skills and interests in different areas.
To be a good programmer, there are a lot of pre-requisites one needs to learn first - skills such as a passion for self-learning, ability to think logically, ability to receive feedback and improve on that, etc. If someone begins as a programmer without these pre-reqs they will have a very difficult time getting to the stage where they can be a good developer.
I recently worked with a junior programmer that just wouldn't listen. I would try to advise him but he would completely ignore it and just go back to copying and pasting code and hoping it would work. Even walking through code line-by-line it was clear he had trouble understanding simple assignments.
Now, maybe that is my fault as a mentor but, IMO, he needed to first learn how to listen and receive feedback before he could move on to the next step. Unfortunately, some people are just too stubborn and will not change. For those people, I don't see how they could become great programmers.
"IMO, he needed to first learn how to listen and receive feedback before he could move on to the next step. Unfortunately, some people are just too stubborn and will not change."
That comment is largely true regardless of what the subject is, not just for programming. Inability to admit error is a huge hurdle for learning in general, because it prevents you from learning from your mistakes and may also prevent you from challenging yourself.
I agree completely and it is not your fsult. Personally I have come across people who do not want to put any effort. So when you ask then questions they become either defensive or arrogant.
Basically they have zero interest in technology or programming. They are in it because it pays well.
> One of the many reasons I became a programmer was that the sky was the limit. Still is. Want to learn something new? Learn it. Want to build something cool? Build it. The only real limitations are your belief that you can do it and your willingness to perservere until you do.
That's not what he's saying.
He's divided the world into two peoples: those with the capacity to program and those who cannot regardless of effort.
These groups are often confused because people can program, but only may do so badly. Yet even being a poor programmer puts you in group A, and effort will make you a better programmer.
On the other hand, there are those who cannot program: cannot write a loop, cannot use variables, cannot create a working algorithm even with copy and paste.
The may perhaps be able to do simple math, but when it comes to composing equations or functions together into an interdependent process...they are simply unable.
They may try if they're so inclined to learn programming, but they'd die of old age before they can even begin to reach a standard that we'd call mediocre.
That is what he is say. Agree or disagree with it, but misunderstanding it skews the discussion.
True. And not. Continuing with the sports analogy I think the comparison of sprinters and marathon runners is an apt one. It's been found (http://sportsmedicine.about.com/od/anatomyandphysiology/a/Mu...) that sprinters have a muscle metabolism that is much more anaerobic than normal from birth (you never exhale during a 100m dash), so good sprinters are pretty much born rather than made. On the other hand, although good genes do help (why are marathon winners generally from Africa?) you can train your muscles to have more efficient aerobic metabolism and be a top-notch marathoner.
So Gates is right in that top talent is probably born, there's nothing you can do to attain that level (which is true for most things, btw). But you can become a damn good programmer by practice.
I agree with everything you said. It is scary that somebody believes something like what Jeff Atwood said. It is actually very toxic thinking. Don't know what more to say other than experience and observation of a lot of people has taught me that what Jeff Atwood says is false. On the other hand, if you believe it is true, then it will just become a self fullfiling prophecy.
It's not that hard. There are lots of objective criteria you can apply to show that one piece of code is better than an alternative: it's more efficient, it's more extensible, it's more reusable, it's less lines of code, it's less prone to error X when programmer Y tries to use it.
The hard part is actually convincing a human that something they did is sub-standard based on a set of objective criteria.
They're objective in that people agree on them. All programmers would say that a more efficient or shorter or more reusable piece of code is better, notwithstanding other tradeoffs that it makes.
My use of "objective" is to distinguish from subjective criteria that people often don't agree on, like "it's more idiomatic" or "it's simpler."
Whilst the measures may be objective, the ordering of them is not. That's quite subjective.
Personally, a shorter piece of code is only better if it maintains the clarity of the longer that it is replacing - assuming all things being equal. Code is always a trade-off.
Many of these reasons are the same: inability to pivot and adapt to adverse circumstances. For example, you cited "they had to build on top of pre-existing shit and couldn't do it right" as a creator of bad programmers. You sound like a college student on this one, because this is the norm in the software industry. Every programmer (good and bad) has faced this one several times. The difference between bad and good programmers is that good programmers make the extra effort to learn the lessons that no one will explicitly teach them (i.e. figure out why the "pre-existing shit" got all fucked up in the first place) whereas bad programmers just accept it as-is or, worse yet, learn the wrong lessons and conclude that the pre-existing shit is how it should be (i.e. people who believe that C++ or Common Lisp, warts and all, are infallible languages, immune to reproach or change).
Having mentors, supportive management, and interesting work is great. But these are not the norm anywhere and they're certainly uncommon in the first few years in the software industry. A career average of 25% on these, for one's first 10 years, is probably about par. The good programmers are those who figured out how to get better in spite of these setbacks.
If I were going to put it into simple terms, the problem with the worst of the bad programmers (the deserving underclass) is that they don't expect much of themselves. They're happy to chug along at 100 lines/month on uninspiring work, and they do just enough not to get fired, but they don't achieve enough to offset the complexity load they create by modifying code while not knowing what they're doing, and by imposing resistance-to-change on the organization they inhabit. That's Class #1 of bad programmers, the ones who've been powerless for too long and are now just passing through. It probably comprises 65% of bad programmers out there.
Class #2 is the do-the-wrong-thing-well type. These are the ones who are generally very intelligent but narrow-minded. For example, they optimize for runtime performance at the expense of code readability, or who use the wrong languages, or who eschew databases because "SQL is a mess; let's just use the filesystem". They tend to be really, really good at some small subset of programming and tend to want to use that set of tools and skills even when not appropriate. These are the people who annotate an O(n^2) sorting algorithm as "WRONG!!" even when it's sorting a collection of 20 elements, because to them, not optimized == wrong. Their learning rates were too high, and now they're stuck at suboptimal local maxima. That's 15% of bad programmers.
Class #3 of bad programmer (15%) is the rock star, the kind who writes lots of code quickly, uses fancy "metaprogramming" features, but no one can understand the code (much less the rock star) a week after it's written. They tend to be parasitic, appearing highly productive but actually generating lots of unpleasant work (externalized costs) for the rest of the team. The call sign of the rockstar is the tendency to change interfaces willy-nilly and expect everyone else to adapt to his changes.
Those numbers add up to 95%. I'm going to leave 5% open to acknowledge that there are species of bad programmers I haven't met yet.
Did you mean to write '100 lines/month' up there, or is that an exaggeration for comic effect? I have little experience with bad programmers--but you seem to know enough (or think you do) to throw percentages out there.
Perhaps a slight exaggeration, but not much of one. 200-300 lines per developer per month is the norm in large companies. Most of the time is spent reading crappy code, debugging crappy code, and dealing with crappy workarounds for crappy code. It sucks.
Even very good programmers fall below 500/month if they get mired in legacy bullshit.
So many sentences in bold, yet so little substance. What he seems to be saying is that to be a better interface between development and customers/management/etc requires more than pure programming ability. Yeah, ok. And maybe this is beneficial for business or, if there really is a lack of this talent, for career prospects. But it's not being a better programmer. The pithy title is not very relevant to the content.
As regards the pithy title though, and the earlier part of the article, I disagree. Programmers can and do develop. There is a large difference in ability between people who stick with the craft for a large number of years (and actively develop their abilities), and those who are new to it. When I was younger I would have probably agreed, yeah, programmers are just good or bad (and I'm good). But I wasn't good. I've become better since. And there's still a lot to learn and pursue. It takes time.
Having said that, it's definitely possible not to progress as a developer despite programming every day. It requires some amount of contemplation.
This article just confirms my notion that in the debate about "what makes a great programmer" there is a fundamental disconnect between the concepts of being "a programmer" and being "a maker of software".
Making software consists of way more than just programming, and in that respect I agree with Atwood. However, that ignores two other things I consider to be proven truths:
1. You don't have to be a great programmer to make great software. Some of the best products are build from horrible code, not just by people who deliberately rushed things, but by people who simply didn't know any better.
2. You can definitely become a better programmer by simply practicing the craft a lot, even after many years. It doesn't however make you a better "maker of software", just a better coder.
This is such a good point. I've noticed that the personality style of "algorithm obsessed, Knuth worshiping, all about optimization, hardcore coder" doesn't have a lot in common with "creative, new software, good UI, unique application builder" personality. While its important to have some of the former under your belt, its the latter that gets shit done and makes things. I consider myself a maker, not a coder or a computer scientist. I'm getting a little sick of the attitude that you need to be this hotshot coder to be into software. Its just this geek macho poseur mentality that's harmful. A mediocre coder with a few good ideas is all it takes. I'd rather see a slow python app or a simple web app that's unique than some super-fast C or low-level me-too implementation.
I feel this dichotomy is typical of geeks. My poor metaphor is we learn the notes, scales, and do our practices, but at the end of the day we're supposed to be writing songs, not waxing philosophic on music theory or who makes the best pianos. Geeks are just too prone to being "technically correct, the best kind of correct!" and those of us who want to create unique things really need to think more like artists than engineers half the time. Oh well, back to our typical barrage of "Why PHP sucks" and "real coders walk like this..." articles
I like your point. It reminds me of how facebook was initially cobbled together with some (likely) hodgepodge php and mysql code. It was a great user experience and took off. After it becoming a hit, they optimized it and improved it.
It's the difference between a musician and a composer. They overlap often and both are absolutely essential to the performance. But practicing one doesn't necessarily carry over to the other.
But he's not talking about becoming a better programmer. He's talking about becoming great.
Not all software can afford to be made out of crappy code either. There are many fields in which being a good programmer is the same thing as being able to write good software.
The web might be the exception here.
The phrase "crappy code" is subjective and not easily measured.
What you consider "crap" may be pure art to the people that produced it. Perhaps you just lack their perspective? Perhaps you've never had to write code in that language or at that scale? Perhaps they are just learning to code?
The world is bigger than individuals. Some code may be "crap" to you, but let me assure you that your code is "crap" to someone else.
Linux kernel code is often called "crap" by the OpenBSD developers. In their mind it is. I'm sure Linux kernel devs feel otherwise and in places where they aren't proud of it, they slowly improve it to make it better. Oh, and BTW, the "crap" that is the Linux kernel supports far more hardware than OpenBSD will ever support.
So in my mind, it's all a matter of perspective and goals. Nothing is "crap". And calling it "crap" is wrong and may cause others to feel bad about themselves and their project. It's juvenile and unnecessary.
If you are interested in the project and think it's "crap" do something constructive, submit your glorious code to make it better and to enlighten us all.
I was referring to what the parent called 'horrible code'. There's definitely a little of both: some of it cannot be measured, some of it can. Code performance is easily measurable for instance. Code size and simplicity can also be roughly measured.
"I agree with Bill. From what I've seen, there's just no crossing the skill chasm as a software developer. You've either got it, or you don't. No amount of putting your nose to the grindstone will change that."
This is a very condescending look on humanity and I did not know that Jeff had said such things.
To anyone thinking the same, let me introduce you to the concept of deliberate practice (how to really improve a skill) and please, even if it wasn't published then, read "Talent Is Overrated" by Geoff Colvin. This will probably change your perception on things like excellence, creativity, so-called "talent" and whether it's true that you must be born a genius to become one.
And by the way, that does not mean that everything is an american dream and that anyone can become a self-made person. Geoff shows through many examples and studies in his book that superstars in music, sports, and science had an exceptional learning environment in their childhood. They did not suffer from hunger and extreme poverty. He also talk about a study that demonstrated that ordinary people could increase their short term memory (remembering up to 100 items if I recall correctly, no pun intended) by doing deliberate practice.
When I was first starting as a programmer, I would have agreed with you. But over the years I've learned that it is 100% accurate that some people can program while others simply cannot.
But it's not a matter of stupid/smart. It's actually the same reason why Paul Graham's 'Hackers and Painters' analogy is so apt. The reality is that some people can think in abstract terms, while others cannot.
Someone who can think in abstract terms can be a graphic artist or a programmer. Consider that even in mathematics, the most concrete things are numbers, which are completely abstract. If you understand that, then guess what? You can think in abstract terms.
I completely agree with you that some people, right now, cannot think in abstract terms. My point though, is that they could learn it through deliberate practice, unless they have a severe medical condition that affect the way they think.
Maybe they don't know they can learn it (possibly because others have told them that they would never get it), maybe they try hard but fail to do deliberate practice (which is different than programming every day), maybe they aren't interested and still want to have a programming job (that's a problem and they should be redirected to a more appropriate position).
Another book I really like to recommend for people who hate maths or don't understand them is Innumeracy by John Allen Paulos. It really helps you get a more positive view on maths. The sequel, Beyond Numeracy, is less groundbreaking though.
> The reality is that some people can think in abstract terms, while others cannot.
This is true, although there's also a gray area of spectrum in between. I've worked with a few programmers who could write imperative-style code just fine, commented and clean, looping over arrays and FizzBuzz and such; but who never grokked first-class functions or SQL set-based operations. (I've replaced many a complex cursor-looping SQL procedure with a set-based query running ten or more times faster.) I think a more nuanced description of the question here is whether and how one can successfully drive oneself to think in progressively higher abstractions. It's not all black and white, abstract or concrete.
The author of that also uses a great deal of selective evidence, flat out ignoring genetic research in relationship to music, for example. Specific genetic sequences have been linked both to perfect pitch and to success in classical music. If you can't find it via a quick google search, I'll be happy to provide citations.
Evidence for the role of genetics in running, swimming and a variety of other sports is equally overwhelming. In short, he (and others like him such as gladwell) sell a fantasy that millions, possibly billions would like to believe. It's an excellent strategy for selling books and developing a base of hard-core fans, but it's just not true.
You are right: genetics can certainly give you an edge and this is briefly mentioned in the book.
But do you mean that someone without the right genetic sequence can't play music? Or do you mean that someone with the right genetic sequence but who never does deliberate practice will be better than someone who has practiced 6 hours per day for the past 20 years under the best masters?
I think you don't mean that and the book did not mean that everyone can be star.
I'm sure some programmers are advantaged by their genes, but saying that all the bad programmers don't have the right genes and should look elsewhere is another thing. I would prefer to look at their learning practices and motivations before studying their genes. I'm sure I would have a lot more success than a geneticist in this case.
"When, in the late sixties, it became abundantly clear that we did not know how to program well enough, people concerned with Programming Methodology tried to figure out what a competent programmer's education should encompass. As a result of that effort programming emerged as a tough engineering discipline with a strong mathematical flavour. This conclusion has never been refuted, many, however, have refused to draw it for the unattractiveness of its implications, such as
1. good programming is probably beyond the intellectual abilities of today's "average programmer"
2. to do, hic et nunc, the job well with today's army of practitioners, many of whom have been lured into a profession beyond their intellectual abilities, is an insoluble problem
3. our only hope is that, by revealing the intellectual contents of programming, we will make the subject attracting the type of students it deserves, so that a next generation of better qualified programmers may gradually replace the current one.
The above implications are certainly unattractive: their social implications are severe, and the absence of a quick solution is disappointing to the impatient. Opposition to and rejection of the findings of programming methodology are therefore only too understandable. We should remember that the conclusion about the intrinsically mathematical nature of the programming task has been made on technical grounds, and that its rejection is always for political or emotional reasons."
Some of the most productive programmers I've known toss code together in a horrifying slapdash fashion but somehow get great things done. And sometimes people with far more precise and mathematical minds just get mired in their beautiful architectures. The common trait I've seen in all exceptional programmers is an ability to keep a tremendous number of details in memory at one time. Most real world code is not lambda calculus but a barely controlled mess.
Humanizing technology is a bigger win than technologizing humans, IMO.
The common trait I've seen in all exceptional programmers is an ability to
keep a tremendous number of details in memory at one time
Would you care to elaborate on this? I'm a programmer with 'precise and mathematical mind' and I'd say that my one big weakness is exactly that: I struggle to large numbers of disconnected facts in my head at one time.
Most programming tasks involve reconciling a bunch of competing constraints. Abstraction techniques make it easier to deal with subsets of those constraints but abstractions leak and even well abstracted software still involves the interactions of many small pieces. This is why it takes 20-30 minutes to get your head into a programming problem - you have to pull enough of that problem space into your head to start manipulating it.
The best programmers can get into that space faster and pull a bigger chunk of a system into their heads at one time. This is why they don't necessarily write clean code because they don't have to. The less gifted of us need strong abstractions and code discipline or we just can't keep up. This is why somebody like Linus Torvalds can afford to be disdainful of a lot of common practices in software - he doesn't need the extra help those practices provide.
And all this happens well above the level of a strong mathematical formalism.
Same here - the best could just read APIs and start using them, while I was always referring back to them.
I've started meditation again; dual n-backed games are next to try and improve my working memory and concentration. Also, just regularly re-reading the core APIs I'm working with.
I'm not sure if that's quantifiable, or if it's a common trait. I'd say you either need that, or be really good at coming up with thought-efficient abstractions. The other way to put it is: you need to have great focus/concentration.
You may have a certain aptitude or talent for software development. However talent without discipline fizzles out or produces wildly varying results. Talent is like that.
What makes a good programmer, mathematician, sports player, etc is discipline. The love of the craft/sport/etc that pushes a person to believe that all the discipline and hard work is worth it. People are naturally lazy. However if they really believe in something they will work on it and become better.
I think you can become a great programmer without any natural talent for it at all. I just don't think you'll find it that interesting... so staying disciplined will probably be very masochistic.
Why people are so focused on the top x% of something? I really don't see the point. Sometimes what you need is a person with great ideas, not a top x% that believes to be some sort of god.
I make the distinction between "Programming" and "Development" in my own head. In fact, I try to avoid using the phase programming, I call it coding. i.e. putting the code on the screen with a keyboard.
I see Jeff talking more about "development" here - coders get better at coding by writing and reading more code. But there's no point being good at putting code on the screen if it doesn't do the thing your end users need to do.
I agree with Bill. From what I've seen, there's just no crossing the skill chasm as a software developer. You've either got it, or you don't. No amount of putting your nose to the grindstone will change that.
Not true with the current neuroscience. Well, in reality, that's what is happening. But do you know why? I'll tell you: Because I'm obsessed with programming. The typical programmer that is not obsessed will just make use of the skills he got while programming and learning. These skills are limited to the time he spent learning/coding.
I'm obsessed; I learn and code even when I'm not in front of the computer.The time of my experience expand. Add to that, the fact that I'm obsessed. I'll brainstorm code/ideas/tricks/google... to get that thing working. I'll make any opportunity in life to learn more about programming. This gives me advantage over that typical programmer that disconnects when he quits his job.
What bill is talking about programmers at MS or any big company like facebook, google etc just like super start sports person or musician, but in general there are lots of requirement of programmers who don't need to those kind of super programming skill but programming with business value.
Comparing programming with sports is not a good idea because you are comparing super start sport person with avg programmers.
Even in sports or other fields there are people who were avg or above avg sport person but latter they become great coach .
So it is quite subjective.
If your heart say you can become programmer and you are doing enough for the same and you are improving day by day then you are on right track.
In my view just writing code is defiantly not going to make good programmer. Code, understanding end user and domain is going to make you better software maker.
I think this article says more about the corporate culture where programmers work than about their capacity. What happens in Microsoft, as in most other companies, is that they make a decision about what a person can do in about 1 to 3 years. After that period, they will no longer give exciting assignments to the programmer and he will be forever viewed by management as doing the same old job. Many times this happens because of lack of determination from the part of the employee, but frequently because he didn't have the right opportunities and didn't know how to look for them.
Usually when this happens, either the employee will leave the company in a short period, looking for better opportunities, or resign itself to do the same thing until retirement (or until he gets lucky).
Part of the controversy with this article is that it is combining two separate ideas into one concept, blurring the differences.
Implementing software is something you can absolutely get better at with experience, discipline, and practice. You only need to look at your old code for evidence of this.
Designing software takes imagination and creativity. Experience and practice may give you a tool chest of preconceived ideas to use when designing your own software, but it isn't going to help you conceive completely new ideas yourself. That requires thinking outside of the box, and it's not something you learn by studying the nuances of implementation. It's not even something you learn by studying programming. IMO this is what Atwood is talking about.
Well, I may not be a great programmer, but after programming for 30 years, I'm a hell of a lot better than I was after programming for three or four years. The story of my evolution as a programmer is at http://lists.canonical.org/pipermail/kragen-tol/2007-March/0....
Even after 25 years, I was doing things that I didn't have the knowledge or skill to do five years before. (On the other hand, sometimes I look at kragen-hacks posts from ten years ago and say, "Whoever did that must be a lot smarter than I am ---" before remembering it was me.)
Maybe 4 years at Microsoft is enough to tell if you have what it takes, but I doubt it. If you work elsewhere you can find yourself moving backwards if you're surrounded by poor practises, particularly early on in your career.
My programming wasn't much cop to begin with and declined in the first 4 years of my career. After 8 years it leaped forward when I read Code Complete (by Steve McConnell). Only later on, when I was maintaining other peoples code rather than writing from scratch, did I realise the pain I had been inflicting on others earlier on.
Another leap occurred when I found myself as the most senior programmer in a (small) company - when the buck stops with you, you're forced to stretch. My every day programming has also been improved by my attempts at architecture.
Its taken me about 15 years to feel reasonably confident and I can't be the only slow learner out there. So although I disagree with Jeff Atwood that you either have it or you don't, I suppose he does have a point - it was largely non-programming tasks that were the break-throughs.
It can be tempting to write-off a junior programmer as having no hope but I was that guy once and I came right eventually - there is hope for everybody.
There's definitely a confusion between "product designer" and "programmer". Sometimes they are the same thing, other times not. So I don't think it's a useful metric. There are truly great programmers... Andrew Appel, SPJ, McCarthy etc who have no need or interest in making "products", yet that doesn't disqualify them from being great. Sure, communication skills are important, especially writing, but I wouldn't push the idea much further.
I'll just keep the "You won't-- you cannot-- become a better programmer through sheer force of programming alone. You can only complement and enhance your existing programming skills by branching out. Learn about your users. Learn about the industry. Learn about your business." quote. I think that's the main point of the article. Also, the article is more than four years old, I'd like to read what he thinks now or five more years from now.
The fact that programmers tend to not get better has little to do with programmers' inherent worth or talent. It has everything to do with how programmers are trained. Employers are doing less and less to train their technical staffs, which has fostered a generation of programmers who believe that the right way to learn something is by Googling it or experimenting randomly on their own. Of course you're not going to get better this way.
Maybe true, but "knowing how to learn" doesn't completely cover it.
It's absolutely possible to make middle-of-the-road developers into good developers through training and mentorship. It's just that many (possibly most) developers don't get opportunities for good training. They're expected to use their "talent" to figure things out on their own, which in most cases means Googling or trial-and-error experimentation. These are among the poorest, least efficient ways to learn.
I think it comes down to drive. If you want it bad enough you'll figure it out. Don't understand the difference between the stack and the heap? Read about it for 4 hours after work, etc. etc. etc.
You can only complement and enhance your existing programming skills by branching out.
A big part of that branching out in my opinion is expanding vistas in areas unrelated to engineering, like reading good literature, creating or appreciating art, and travel.
I've not found this to be true. I'd like it to be true, but I don't think it is.
When I try new programming methodologies, ideas, etc, I often notice a distinct change in how I program and how I think about programming.
When I try new life choices (emmigrating to the third world, reading good literature, etc) I grow as a person, but I really can't think of how it's affected my programming.
Maybe the point is that, programming isn't all coding, but also talking, connecting, and relating with other people you're working with, working for, and those that you're building a product for.
Growing as a person I think does help in those aspects.
I've wondered if engineering/CS undergrads should be forced to take a Design 101 class to learn:
* design is everywhere
* having a sense of taste is vital to anyone who makes things
* end users are severely affected by every design decision you make
I run into too many engineers that try to disregard the subjective aspects of development (architecture/UX/etc) because they believe the only worthwhile things are the logical ones.
I don't think the engineers disregarded everything that is not based on logic, but any good engineer will disregard everything that somebody believes, feels or thinks is the right solution unless they can give a good, well reasoned argument.
Most design people aren't happy about that level of scrutiny, but that is something they should do, as it will improve their craft.
This is missing what I will quote from another post above "If they really believe in something they will work on it and become better." If you peak at something this makes you good. If you work ard at something this makes you good. If you peak at something and work on it and become better, this makes you great. Evolving gradually but steadily might increase one's belief that hard work is rewarded, however you will never become great, merely good.
Programming is about representing the world with structures that are adaptable to how the world really changes, so it pays off to read books about human psychology (normal and abnormal), statistics, game theory, and war.
When you get a intuitive feeling for how the world morphs and changes around you according to stimuli, then better code structures strike you, and those superior code structures will have much longer lifespans and will be more adaptable to the needs that the users don't know they have yet. It's all about predicting the future, and in order to predict the future of a complex worldly system, you have to KNOW it inside and out.
I hate that Bill Gates quote, why would you cite the opinion of a guy who isn't known for his programming ability nor has any history of hiring good programmers?
Well, the thing is, Gates was an expert programmer. His coding on BASIC was impressive. He transitioned to management pretty quickly, but that doesn't mean much.
What a scary thought. Good thing it's not true.
One of the many reasons I became a programmer was that the sky was the limit. Still is. Want to learn something new? Learn it. Want to build something cool? Build it. The only real limitations are your belief that you can do it and your willingness to perservere until you do.
We are not like basketball players or musicians or chess masters where only the extremely gifted (who also work hard) can rise to the top of their craft. With few exceptions, we all can.
I didn't always think this way. I had a college math professor who once said, "Many of my students are simply not suited for the sciences." And I was stupid enough to believe him! In retrospect, his comment said more about his weakness as a teacher than anything about his students.
How do I know this? Because I learned the hard way. When working with my first mentor, I was always too quick to blame someone else for their limitations slowing progress. Until he said, "So teach them!" He believed that almost anyone can learn and get good at almost anything. This seemed counterintuitive but after a while, I was able to adopt this belief system, and it has made all the difference.
There are many reasons why so many programmers suck, but "not being able to cross the chasm" isn't one of them. Just a few of the real reasons:
My programming has always gotten better every year. Sometimes I read my old code and can't believe I wrote it. And I still have tons of room for improvement.I'm firmly convinced that almost any of us can get better, much better. And even become "elite", whatever that means. Please don't listen to anyone else who tells you otherwise.