How To Become A Better Programmer By Not Programming
codinghorror.com
codinghorror.com
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>
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.
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.
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.
Thank you.
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.
Sorry but I think you're mistaken, possibly due to the other link on the front page right now (http://news.ycombinator.com/item?id=2902903).
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."
-They are trying too hard.
On a daily basis, this hurts me more than anything else.
WHAT IS THE DAN PLAN?
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.
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.
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.
Very good book for those not familiar.
I agree with this statement. But haven't accepted it as the fact yet.
You managed to learn "new things" quickly has not always meant "they" (as you said) 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
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.
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.
Basically they have zero interest in technology or programming. They are in it because it pays well.
This article applies to these people.
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.
Chess and programming are cousins in thought.
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.
But I guess my soccer coach was just an idiot.
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".
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.
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?
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 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.
[1] https://secure.wikimedia.org/wikipedia/en/wiki/Grandmaster_(...
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?
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?
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.
Good grief. You haven't done much.
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.
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.
Even very good programmers fall below 500/month if they get mired in legacy bullshit.
- Explaining why code is "sub standard" is hard.The hard part is actually convincing a human that something they did is sub-standard based on a set of objective criteria.
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."
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.
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.
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.
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.
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.
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 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
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.
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.
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.
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.
I tend to think that it'soften good rhetoric skills. A great ability with the three different types of rhetorical proof: ethos, logos, pathos.
I can see how rhetoric (and religion!) can come into play in design meetings :-)
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.
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.
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."
EWD611 (http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EW...)
Humanizing technology is a bigger win than technologizing humans, IMO.
Beautifully put.
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
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.
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.
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 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.
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.
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.
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).
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.
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.)
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.
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.
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.
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.
Growing as a person I think does help in those aspects.
* 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
Most design people aren't happy about that level of scrutiny, but that is something they should do, as it will improve their craft.
-a c# programmer learning python -a sql expert learning cassandra
etc?
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.