Last year in Programmers as Human Beings, I mentioned that I was reading Programmers At Work. It's a great collection of interviews with famous programmers circa 1986. All the interviews are worth reading, but the interview with Bill Gates has one particular answer that cuts to the bone:
Does accumulating experience through the years necessarily make programming easier?Bill Gates: No. I think after the first three or four years, it's pretty cast in concrete whether you're a good programmer or not. After a few more years, you may know more about managing large projects and personalities, but after three or four years, it's clear what you're going to be. There's no one at Microsoft who was just kind of mediocre for a couple of years, and then just out of the blue started optimizing everything in sight. I can talk to somebody about a program that he's written and know right away whether he's really a good programmer.
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 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. But if you accept that premise, it also presents us with a paradox: if experience doesn't make you a better programmer, what does? Are our skill levels written in stone? Is it impossible to become a better programmer?
To answer that question, you have to consider the obsessive nature of programming itself. Good developers are good at programming. Really good at programming. You might even say fanatically good. If they're anything like me, they've spent nearly every waking moment in front of a computer for most of their lives. And naturally, they get better at it over time. Competent software developers have already mastered the skill of programming, which puts them in a very select club. But if you're already in the 97th percentile for programming aptitude, what difference does a few more percentile points really make in the big scheme of things?
The older I get, the more I believe that the only way to become a better programmer is by not programming. You have to come up for air, put down the compiler for a moment, and take stock of what you're really doing. Code is important, but it's a small part of the overall process.
This piece in Design Observer offers a nice bit of related advice:
Over the years, I came to realize that my best work has always involved subjects that interested me, or -- even better -- subjects about which I've become interested, and even passionate about, through the very process of doing design work. I believe I'm still passionate about graphic design. But the great thing about graphic design is that it is almost always about something else. Corporate law. Professional football. Art. Politics. Robert Wilson. And if I can't get excited about whatever that something else is, I really have trouble doing a good work as a designer. To me, the conclusion is inexcapable: the more things you're interested in, the better your work will be.
Passion for coding is a wonderful thing. But it's all too easy to mindlessly, reflexively entrench yourself deeper and deeper into a skill that you've already proven yourself more than capable at many times over. To truly become a better programmer, you have to to cultivate passion for everything else that goes on around the programming.
Bill Gates, in a 2005 interview, follows up in spirit to his 1986 remarks:
The nature of these jobs is not just closing your door and doing coding, and it's easy to get that fact out. The greatest missing skill is somebody who's both good at understanding the engineering and who has good relationships with the hard-core engineers, and bridges that to working with the customers and the marketing and things like that. And so that sort of engineering management career track, even amongst all the people we have, we still fall short of finding people who want to do that, and so we often have to push people into it.I'd love to have people who come to these jobs wanting to think of it as an exercise in people management and people dynamics, as well as the basic engineering skills. That would be absolutely amazing.
And we can promise those people within two years of starting that career most of what they're doing won't be coding, because there are many career paths, say, within that Microsoft Office group where you're part of creating this amazing product, you get to see how people use it, you get to then spend two years, build another version, and really change the productivity in this very deep way, take some big bets on what you're doing and do some things that are just responsive to what that customer wants.
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.
The more things you are interested in, the better your work will be.
Will not running make you a better runner? Will not playing tennis make you a better tennis player?
I think the physical analogies break down. Programming is a purely mental activity. And as I've cited multiple times in the original post and in the comments, the distribution of skill in programming is extremely lopsided relative to other professions. There's no normal curve: it's a double hump of those who can, and those who can't.
So if you can do it *at all*, you can always do it. Your programming skills won't deteriorate to the point that you can't program. You won't slide back over from a Sheep to a Goat. It's impossible.
Will not thinking make you a better thinker?
Sometimes not thinking can, in fact, make you a better thinker. You don't stop thinking entirely. You stop thinking about the same topics and instead think about related (or completely unrelated) topics that can lead to breakthroughs in other areas. Richard Feynman didn't spend all his time thinking about physics:
http://en.wikipedia.org/wiki/Surely_You're_Joking,_Mr._Feynman!
Jeff Atwood on January 30, 2007 1:10 AMInteresting post, but utter BS. :)
You can be anything you want to be. Whatever you set out to achieve you can do if you really decide to and really work at it. You've heard this pep talk before, I know, but it happens to be true.
The guys who try to tell you that you can't cut it simply have their own ax to grind. Either they tried and failed, or they have some vested interest in your failure. Don't believe any of it.
andy on January 30, 2007 1:29 AMThinking is for fratboys
retardonerd on January 30, 2007 1:44 AMTypical boooschwaa sensibility crap. Bill "I got rich cuz mommy had a hook up" Gates is a great swindler. Anyone who tries to justify thier greatness by saying you have to not do something to be good at it is trying to justify their own fear being looked at for what they really are.
Attitudes like the ones portrayed by these "lifestyle" programmers have no clue what it really takes because they have been getting others to code for them since they got thier cushy new office with thier ultra-geek pong clocks...
Excuse me while I barf all over my keyboarasdfa;lkj;alkdja;sldadj
retardonerd on January 30, 2007 1:53 AMAnyone can be a good programmer. The difference is that most people are not driven to become good at anything. They reach a point that is comfortable for them and stop improving. You see this in all aspects of life.
I completely disagree that a good programmer is apparent or not within a few years. What you might discover is if someone cares enough to improve themselves.
It has often been said that it takes 10 years to develop a mastery of any skill. In my experience this is a reasonable statement. It's just a pity that in software development 10 years is just about a programmers expiry date.
mixing up a lot of notions here:
- that Gates is qualified to judge. may be not. IIRC, he's never provided evidence that he ever wrote anything other than a BASIC interpreter (and legend has it that Allen was the primary author). is there any? being a critic of X doesn't entail being good at X; usually, but not systems development. the quality of criticism here derives not from subjective preference (this picture pleases me more than that picture), but acknowledged superiority (i built a better mousetrap, and yours is crap because it doesn't trap mouses). which brings us to...
- that M$ is a demonstrable example of innovation, superior systems development, or creativity. if you go down the list; it was something they stole (DOS), something they built for hire then stole (Windows UI), something they built for hire then ported (Office), something they EEE (IE), something they lucked out on (DOS for IBM, who were clueless; and Lotus 1-2-3 which was made ONLY for DOS and thus made DOS mandatory), something they did that was illegal but didn't get really punished for (the anti-trust stuff, and the continuing punitive contracts with OEMs; do you really think Dell, et al wouldn't offer Linux if they could without penalty?). face it: M$ got where they are not by building better mousetraps, but by trapping folks into buying only M$ mousetraps.
- folks are confounding understanding syntax (can you write tight code in X language?) with semantics (do you understand O/S prinicples or database principles or Knuth's books?). the notion that what you know how to do changes in 4 years is the syntax trap. being able to absorb new syntax/languages in short order is a demonstrable skill. not the same as being a brilliant developer.
- that coders are the same as developers. developers are different from each other (coders, too). having a deep understanding of the logic and structure of an O/S is different from (and have less $$$$ value), than deep understanding of how to build a databased G/L. in fact, i'd bet on it.
- DaVinci wasn't born doing that stuff; he learned his trade first. the aura of creativity is self-aggrandizement. even Picasso had different periods and made different stuff.
Buggy Fun Bunny on January 30, 2007 2:33 AMtrue!
Juha on January 30, 2007 2:39 AM- "Programming is closer to art than any other engineering profession"
- "Your ability to think creatively is proportional to your programming talent."
- "I think great programming requires not only intelligence but also creativity. The best programmers I know are artists not engineers!"
Above posters would be interested in http://www.amazon.com/Software-Creativity-2-0-Robert-Glass/dp/0977213315/sr=1-1/qid=1170197290/ref=pd_bbs_sr_1/002-0838152-3645618?ie=UTF8s=books
- "Finding new minimal ways to represent patterns and mechanisms to verify the correctness of those patterns is more important to me than how it can be used in real life."
- "People with an CS background too often seem to get frustrated (or even angry) when their elegant solutions can't handle the real world"
Interesting that both ends of the spectrum read this blog. BTW, the first post relates much to the previous blog entry about how much code you've written that's actually in use. I assume the poster is an academe.
!false
Great post.
Maybe you could write some about how you organize your day? Because I want to learn how I get time to "not programming"? :)
Peter Palludan on January 30, 2007 2:57 AMi'm 30, and went back to school after having a diploma (gifted, etc. - just lazy as a 10 year cat) and have learned that practice does indeed make better... I used to have the worst code ever, but was the most computer-literate person otherwise. Stuff I'd do would include extensive hard-code, redundant vars and such, and some of the worst logic ever (after I re-read it a week later). Now after a few failed jobs and such, I've realized how much code I did know and have now 'grown' a sense programming that I didn't know I didn't have.
I see the same problems that used to take me twenty lines of code i now do in five. So, I disagree... Spending time with the code does help - but the article is true about one thing... If a person is not comfortable with abstracts and meaninglessness, the concept of code would be lost.
ceelow on January 30, 2007 2:59 AMi think that we should have a definition of what a 'good developer' is. let's assume that a 'good developer' is someone who develops code that doesn't hog the system's resources and who uses the minimum number of lines of code and in minimum time.
i firmly believe that having a good design phase can greatly improve your coding.once you have your plan,you can start programming instead of constantly going back and forth between designing and programming.a good programmer knows how to translate an idea into effective code and having a good design phase will save you a lot of time and allow you to concentrate on other aspects of the project.
so i totally agree with the article that you can become a better programmer by not programming.by becoming better at designing, you can become a better programmer.
ajmal on January 30, 2007 3:31 AMVery true indeed. I did not recognize the "do not program" fact this way of my own, but I recently wrote something similar categorizing "Different types of programmers" (http://goit-postal.blogspot.com/2006/10/different-types-of-programmers.html) even without having that in mind: "The Generalist" is pretty the kind of guy who does not program while programming.
Thumbs up! Georgi
Georgi on January 30, 2007 3:35 AMIsn't everything in this post related to basically any creative field? If you'd replaced the programming references by music, art, literary, or performance references, you'd have the same point and there'd be nothing fresh about it. (Except that making an emotional connection to your audience is perhaps done in a completely different way.)
Foxyshadis on January 30, 2007 3:37 AMSo I'm never going to be a good programmer then.
engtech on January 30, 2007 4:05 AM I think the physical analogies break down.
Programming is a purely mental activity.
As is Chess, which was featured prominently in the article I referenced. Chessmasters are made, not born. Why not good programmers?
Expanding your horizons is also a key. Being personally supposed to teach software engineering this year, I have been having the same kind of concerns. See "The unteachable parts of software engineering", http://blog.vermorel.com/?p=28
Also, being "good" involves many aspects. For example: is-it wise to implement (even if the execution is perfect) a product that either already exists or that does not reflect any business needs?
Joannes Vermorel on January 30, 2007 4:41 AMI disagree that you can't get better. While certainly like anything else there are those that are gurus or prodigies at it. But every programmer learns better way of doing things as time goes on. Whether it is coding something by hand and then moving to wiring in a COTS to save resources or programming with Web Services for the first time as opposed to limit oneselves to a Windows Form. Some things cannot be learned overnight. 4 years is a long time. Nothing looks the same as it did 4 years ago. So I think it all can be boiled down to how readily a programmer adapts to new technology instead of for example still doing VB6 for everything in 2007.
I often find this blog overgeneralizes. The trend you speak of is inherent in anything. Not just programming.
Josh on January 30, 2007 4:48 AMChessmasters are made, not born. Why not good programmers?
I'll answer your question with another question. If chess is analogous to programming, why can't computers write code as well as they play chess?
Human grandmasters are barely holding their own against chess programs these days. And depending on who you ask, human chess players have already lost the war.
http://www.codinghorror.com/blog/archives/000701.html
The answer, of course, is that programming has an infinity of choices compared to chess. As others have commented, it's so open ended that it's more analogous to art, or writing, or other purely creative activities.
Also, just to clarify, I never said that you can't improve as a programmer. Sure you can. But 90% of the improvements will be realized in the first four years of your professional career, and the rest will be incremental.
Jeff Atwood on January 30, 2007 4:49 AMI feel that this posting does hold some weight though because a persons IQ is said never to change. There's always some programmers code snippet that you find around the web that is just so clever it sometimes depresses me to think 'oh, i would've never thought of that!'.
does reading, absorbing then implementing tons of good code, and adding you're own little twist make you a good coder?, i don't think so. So maybe those really good programmers are just the ones that make the breaththroughs.. like david heinemeier hansson with rails for example.. and i'm just the average guy who is just good enough to use it.
oh, and about the idea that not coding can make you better only makes sense if the reason why you've stopped is because you became over critical of yourself (i've done it). When you come back without all the negativity and a clear head.. you're automatically better.
.. if i've repeated something, sorry, i didn't have the time to read all the comments.
crappy_coder :) on January 30, 2007 4:57 AMI think this post points in the wrong direction.
Programming, the art of abstraction, logic, reduction, and rewriting is independent of 'the real world'. A great programmer can look at a program and see it's beauty irrespective of it's real world significance. Finding new minimal ways to represent patterns and mechanisms to verify the correctness of those patterns is more important to me than how it can be used in real life.
I agree with the need to raise your head, but for a different reason. Other great programmers are exploring important ideas regarding syntax and semantics that can drastically improve your expressivity, correctness, and productivity. A significant amount of any programmer's time is well spent measuring him/herself and his/her productivity, and looking for ways to optimize that. The payback of exploring different architectures, computing paradigms, languages, and algorithms is enormous.
Ben
Jeff, nice post about needing some breadth to go with your programming depth. But, I was a littel disappointed with the content vs the title: I'd hoped that you'd be writing about the programmer's failure mode of approaching every problem with the solution "write more code" already in mind.
Really great programmers go to the heart of the problem, find what aspect of it adds most value to the user then write a very small amount of code to address that, and that alone. Programmers have a tendency to think that the thing that they do that adds value (and justifies their paycheck) above all else is write more code. And so they write code. What they don't take into account is that code is a liability for the customer, not an asset, so the less of it they produce (while adding value through solving the problem), the better.
Best of all, delete some. The very best programmers can take a new problem, find the essence of it, find the commonality with the essence of the problems already solved, incorporate the new solution and end up with less code than they started with. http://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt for example
Ivan Moore will even tell you that deleting code is a refactoring http://ivan.truemesh.com/archives/000393.html In fact, he sometimes says that even if that isn't your goal a good non-delete refactoring should allow you to delete some code, or else you are just pushing code around for the sake of it.
keithb on January 30, 2007 5:11 AM"But if you accept that premise, it also presents us with a paradox: if experience doesn't make you a better programmer, what does? Are our skill levels written in stone? Is it impossible to become a better programmer?"
Um, that's not what Bill said. He said you'll know within a couple years what type of programmer you are, not that experience can't make you a better programmer.
Dave on January 30, 2007 5:32 AMReally good programmers spend a lot of time THINKING.
Not madly typing in code. Typing should be the last
act, not the first.
This reminds me of the old and so true quote from Larry Wall
"The three chief virtues of a programmer are: Laziness, Impatience and Hubris"
Where I think that order also is important...
Edward on January 30, 2007 5:52 AMYour ability to think creatively is proportional to your programming talent. Great problem solvers make great programmers.
farmsworth on January 30, 2007 5:59 AMSome of the best code I've ever written was actually done on a legal pad with a pen. I've written code across the spectrum, from memory management on early Linux kernels up to massively parallel supercomputers over satellites. Code that I look back at and say "Damn! That was good." I did when I back away from the computer, say down with pen and paper, and write the algorithm/design out. Sometimes it was before coding and sometimes in the middle of slogging through digital sewage.
My point is that good code is developed in your head, not your compiler. You don't need a computer immediately to write good code.
Here you go again, Jeff, beating that poor dead horse again. We've already familiar with your opinion on this. But I would like to ask you a few things. Will not running make you a better runner? Will not playing tennis make you a better tennis player? Will not thinking make you a better thinker? You're preaching this approach because you, in the natural progression of your career, are programming less and managing more. I mean, come on, if you have this much time to blog then you're not pumping out a thousand lines a day.
You see, you are trying to convince yourself as much as you are trying to convince us that programming less is the way to go. It's ok, I'm not faulting you for that. We all evolve in our careers (we have no choice, eh?) It's just that I don't think you're main argument is valid. You might become a better manager, a better architect, etc. by programming less, but you won't become a better programmer that way.
Ken on January 30, 2007 6:20 AM@ken
I think you're completely missing the point.
Programming more will give you a better understanding of syntax, control structures and other techincal elements of programming, but there is more to being a good programmer than just writing code.
An example of the difference is the word verification on this page. A bad programmer who knows lots of syntax would probably write a bulky code base that randomly generates and scrambles a series of random characters. However, that's like hammering a finishing nail with a sledgehammer. The simple phrase 'ORANGE' is probably just as effective at blocking comment spam as some over complicated captcha system, but it required far less code and is much easier for users to deal with.
The point is that there are 2 ways to solve most programming problems. Either keeping writing code until it works or take time to address the goals and develop a concise elegant solution. Anybody can memorize syntax, it takes a good programmer/developer to really understand the bigger picture.
Ian Muir on January 30, 2007 6:42 AMYou may want to read Steve Yegge's counterpoint to this post:
http://steve.yegge.googlepages.com/practicing-programming
How do you know you are even a 'good' programmer?
Pedro on January 30, 2007 6:56 AMIf I thought 4 years ago "This is the best I'll ever be." then I would probably be a worse programmer today. Well-roundedness is an issue and being a good programmer is about solving the right problems.
Perhaps Bill meant your personality as a programmer is set in stone, but you'd never convince me that I haven't been increasing my skills and knowledge.
To be fair, I still approach problems the same way. I also still like writing good clean code and I still like to read books on all sorts of topics (dev and otherwise).
I would however hope the code I write now isn't as bad as what I wrote back then.
MintyFreshness on January 30, 2007 6:58 AMCouldn't agree with you more Jeff, programmers must keep their head above the water for other things beside coding. Computer programs will be useless without any users using it right? It's just like your previous post, coding is fun, but shipping is the real job.
Hendra Saputra on January 30, 2007 7:07 AMGood stuff. However, the term 'programming' perhaps needs to be better defined: Optimizing a routine (pointlessly) so it is impossible for someone else to read but is 1% faster? Writing code that can easily be extended and modified? Building an app that can (relatively) easily be changed due to the whims of the customer? Seeing the big design picture and organizing the development strategy?
Another curious thought is why are some people really, really productive in one language but not in another? Why does a certain language 'get in the way' of a person's mind as they try to turn a problem into a solution?
I read both articles (which includes the one in the comments above). They both approach programming from two different perspectives. Yes, you have to practice and study to become a better programmer. You also have to get away from it from time to time to gain the perspective of those who are going to use, sell, or market the code you're working with.
The way I see it, the articles are not opposing each other but complementing each other.
RT Cunningham on January 30, 2007 7:10 AMI agree to a point. I would strongly argue against the notion that we can't get any better ever. I've been coding professionally for about 7 years now and I think I'm MUCH better now than I was even 2 or 3 years ago.
That said, I do think that there are some people who hit that wall and can't proceed any further. People for whom this article is more true. I've seen it in school, in my work, etc.
So I think you can't generalize this to all programmers. I continually study and read to improve my skills. Not all my studying is on actual coding but a good portion of it is. And I feel like I've gained more skill in the past 2-3 years than I did in the 4-5 years before that.
Jeremy on January 30, 2007 7:20 AMBen wrote:
I think this post points in the wrong direction.
Programming, the art of abstraction, logic, reduction,
and rewriting is independent of 'the real world'.
A great programmer can look at a program and see it's
beauty irrespective of it's real world significance.
Ben, there's a hell of a difference between a skilled developer and a skilled programmer. That's the whole point of the story.
JensG
Well said, JensG. The point is that you must look beyond yourself to improve -- not simply sharpen what you already know.
If you know a programming language, it becomes a means - a tool - not an end in and of itself. It's just part of your skills that can't get much better.
bryan on January 30, 2007 8:03 AMOverrated blog post! Nothing intriguing. Actually its difficult to describe a good programmer and I know a few folks who have gotten much better at programming after years of programming. IMHO, good programming is a function of your intelligence and I think great programming requires not only intelligence but also creativity. The best programmers I know are artists not engineers!
Kashif Razzaqui on January 30, 2007 8:03 AMVery interesting post! IMO, the "da Vinci route" should be efficient to excel in just about anything: Study anything even remotely related to your field. You can get completely different insights from doing a bit of 3D modeling, OS tweaking, web accessibility, iPod hacking, gaming, system administration, etc.. Any of these can make you a better programmer, by giving you a view of how different types of systems behave - Or maybe more important, give you ideas of how they /should/ behave.
l0b0 on January 30, 2007 8:21 AMThe best programmers are not normal... they are either obsessive compulsive, bipolar, paranoid, or neurotic.
cyclo on January 30, 2007 8:58 AMWell, to give you an idea, I program perhaps once every few months. The few times I dive into code, I'm there for a reason. Nine times out of tend, I write the unoptimized version within the first 10% of the time I spend coding. The other 90% is a pretty even split between optimizing the code and tweaking its functionality. I think the reason I never became a hard-core programmer, even though I've been told time and time again that I have the chops, is that I simply don't want to make the compiler and debugger my two best friends (and worst enemies). I'm not a social butterfly by any stretch of the imagination, but I need more social interaction than that...
Jae on January 30, 2007 9:14 AMYou either have it or you don't...
Rabid Wolverine on January 30, 2007 9:20 AMI think there's a common arrogance among developers that "great programmer" == "thinks like me".
In one instance I was arguing for a significant abstraction layer between some incoming data and an (informal) datamart we were building on top of it. The incoming data was from several sources and a) was very inconsistent, b) the developers kept making mistakes when trying to glue all the data together so they could use it, and c) I didn't want to impact all of the downstream apps when the incoming files were modified.
My co-worker wanted very minimal abstraction, because a) more abstraction means more code to maintain and more opportunities for bugs and b) the incoming data only changed 2-3 times a year, and c) most of the people who used the data were familiar with the incoming feeds but wouldn't have access to the code base, and therefore if we put too much code in between it would be hard for them to differentiate bad incoming data (very common) from bugs in our code (also very common).
For 2-3 days each of us was convinced that the other was at best naive, more likely stupid, and most certainly SUCKED as a developer. But ultimately we were both right -- we were just optimizing different aspects of the problem based on our gut feel for where the pain would be in the future.
As a coda, I ended up winning the argument and (as I was debugging and modifying the abstraction layer over the next few years) developing what I call "The Law of Constant Pain". There is no optimal spot where pain is minimized -- all good solutions trade off pros and cons in equal measure, so all good solutions are equally bad and good. Making it better in one aspect makes it (at best) equally worse in another aspect. (And of course there are lots of solutions that are worse all around, but the people who come up with those are the *real* lousy developers.)
This may be tangential to the topic ...
"The main idea of our column is that “talent” is overrated; that practice really does make perfect; and that it’s a good idea to do what you truly love in life, because if you don’t, you probably won’t work hard enough at it to get really good."
http://www.freakonomics.com/blog/2007/01/08/practice-makes-perfect-revisited/
kloodge on January 30, 2007 9:29 AMOne more point. If I owned Microsoft I'd want cracker-jack programmers. But if I ran an IS department I'd rather have VB6 developers with business degrees than brilliant computer science grads. This is a bit bigoted, but real life is messy and inelegant. People with an CS background too often seem to get frustrated (or even angry) when their elegant solutions can't handle the real world. Obviously the real world is at fault in these situations, and therefore it just has to change. People with an IS background seem more willing to tolerate messy solutions if it means the business problem gets solved quickly and correctly.
I know there's a balance, but it should be tilted towards the activities that earn money for the company, not to some propeller-heads mathematically pure conceptual frameworky things.
JPLemme on January 30, 2007 9:42 AMGreat post, Jeff.
The problem with more of the "people" aspects of software development, is that I believe these skills are very hard to learn or practice.
If it doesn't come naturally to you, can you practice or learn enough about how to get people to like you and have decent human interactions with them?
With some things you can "fake it til you make it," but the real issue you're dealing with in personal dynamics is empathy. If you're just naturally nihilistic and have no empathy for others, and use them as objects or ends to your means, then no matter how hard you fake it -- that will still show through.
And it is a damn shame that more corporations don't recognize the value of the 99%'s out there. It's why anyone in that category should seriously consider starting up their own thing with a couple of buddies -- it's the only way you can extract that latent value.
Shanti Braford; On Web Apps on January 30, 2007 10:00 AMGates was only saying that programming experience won't turn one into a good programmer. He never said that programming experience will not make one a better programmer.
anonymous on January 30, 2007 10:07 AMi will say that it is not about coding but more about understanding the requirements. if you know the problem then you can solve it, but if you don't, how can you solve it? think about it. a better programmer is one who understands the problem faster then others.
thecancerus on January 30, 2007 10:19 AMI used to spend every waking moment in front of the computer also. Then I got tendinitis so bad I almost had to change careers. Now I spend no more then 4 or 5 hours a day at the computer, but I'm still a damn good programmer.
Be careful people.
MarketGarden on January 30, 2007 10:26 AMInterpretation: Compare "programmers" to singer-songwriters. A would-be songwriter can practice on an instrument all day and all night for years, but if they have nothing to say, then? "Passionate" people throw themselves into larger concerns, and out of their experience and personality will have plenty to say as a result. ... As one side-effect, programmers will say it through code.
Jerry Van Polen on January 30, 2007 10:35 AMGates was only saying that programming experience won't turn one into a good programmer. He never said that programming experience will not make one a better programmer.
That's right. And what I'm saying is that the skill differential between mediocre and great programmers is so wide and so vast, that *the tiny differences between great programmers are barely significant*.
Once you're a great programmer, you're worth 5, 10, 20 mediocre programmers. See the many data points cited here:
http://www.codinghorror.com/blog/archives/000072.html
Studies have proven time and time again that, statistically, there is *NO* correlation between years of experience and skill in software development. This isn't conjecture, this isn't my opinion, it's a scientific result supported by experiments and hard data.
Therefore, if you are *already* a great programmer, and you want to distinguish yourself even further, you should learn complementary disciplines, rather than going for the 99.5th percentile skill level of greatness. Nobody can tell a 99.5th percentile coder from a 98th percentile coder. But they can sure as heck tell the difference between a great coder and a great coder who *also* understands usability, the business, the customer, etcetera.
Jeff Atwood on January 30, 2007 10:41 AMIn my opinion this is disheartening for beginners,
Someone who does not know anything about programming and wants to learn
you say something like this to them and there goes there desire to learn out the window~~!!!!!
My comment on this is Not everyone is a great programmer to start They worked diligently at it and if there not so great it's because someone like you wrote a statement like this and discouraged there desire!
I am, as the original post describes, a "good" programmer, but *not* a great one.
My algorithms/modules/programs work. They do the job. But, they are neither elegant nor efficient. No matter how much I programmed, no matter how much I studied, my raw ability to problem-solve did not improve. My repertoire of languages improved. My documentation improved. Other things improved. But, not my ability to produce elegant code, nor efficient code.
I've recognized this, and thus, when required to produce code, explain to the requestor that the end result will work, but will likely be brute-force rather than elegant, and can always be edited for efficiency.
.
Bravo. Exactly what I've been telling fellow developers for years.
TJ on January 30, 2007 11:52 AM"...Competent software developers have already mastered the skill of programming"
Can some one define the programming skill? if there's such a thing.
Programming is closer to art than any other engineering profession. The range in the solution field is so great that solutions to any problem are as varied as the colors of the rainbow. In fact I'm willing to assert that the reason why there are great programmers and not so great is the same reason why there has been and will only be one Monalisa and one DaVinci.
cland on January 30, 2007 12:18 PMWell most programmers aren't in the 90th percentile, so there's still room for programming improvement. I'm not convinced by this "innate talent" argument. See my response: http://haacked.com/archive/2007/01/30/Better_Programming_By_Programming_Better.aspx
Although I do agree that the "tangential" skills are very important for *all* levels of developers and most likely will make a developer more valuable faster than improving programming skills.
Haacked on January 30, 2007 12:47 PMi wonder why programming is related to art? I taught programming is all about the logic. Good programmer can solve a problem by producing a good logic. from my perspective, coding is more like giving instructions for computer to do this and that.correct me if i'm wrong..
tokan on January 31, 2007 2:26 AMWhile I think there are "problems" with programmers (http://www.edmblog.com/weblog/2006/11/the_problem_wit.html), I do think that most people don't want to write code (http://www.edmblog.com/weblog/2007/01/does_everyone_e.html), and could not if they wanted to. The fundamental problem is that programmers and business users have a different perspective (http://www.edmblog.com/weblog/2005/08/different_persp.html)
JT
http://www.edmblog.com
ooops..grammar mistake.."taught" should be "thought"
tokan on January 31, 2007 3:57 AMWho is talking, and who is who? A good programmer doesn't have time for morals and bitching on the others. Also, what made a good programmer is subjective. It could happen that junior finds something that the others didn't see. Is probably the only substancial contribution that this person made but it may save the compagny from hell ... Remember Jobs, every buddy was looking at him as a looser. He 's making a tremendous comeback.
If your not the father of a great system or builder of a new program, your just a vulgar refurbisher of what you never build, because you dont have the guts to work on real things; but i'm sure you prove that you have fast mind but rabbits are better with estragon then a turtles.
N.B. dont see any discussion on real code... maibe you working on boring stuff...
Raphael on January 31, 2007 4:34 AMI little off topis but this is a message for all of the young guys out there that think programming is their life.
Go out, meet people, travel, get a girlfriend, get married, have kids, buy a house, shower, learn how to dress, DON'T WORK AT HOME, DON'T PLAY COMPUTER GAMES ALL NIGHT........
I'm sure I will get lots of responses about this and that and excuse after excuse.......
IT needs to get a life outside of IT and interact with REAL PEOPLE.
Thanks,
Trev
If chess is analogous to programming, why can't computers write
code as well as they play chess?
Well they can't *yet*. Just as computers couldn't play chess very well 20 years ago. Today, they still can't compete against humans at GO.
Give it time.
Haacked on January 31, 2007 8:50 AM1) If you're reading this blog-- and by this blog I mean any technical blog-- it's unlikely that you are a mediocre programmer.
2) Mediocre programmers don't even know that they are mediocre. So if you think you are, that level of self-awareness automatically disqualifies you from mediocrity.
3) Mediocre programmers don't read technical blogs, or Joel on Software, or Code Complete, or Don't Make Me Think, etcetera.
If you're reading this, I can assure you that you, yes you, ARE a good programmer. Trust me.
Jeff Atwood on January 31, 2007 10:32 AMTrue, totaly agree with you,
But what i think is just 2 years is not enough to predict the issues in the design, for that one need at least 4 years of coding experience.
What junk is this ?
Atreya on January 31, 2007 12:28 PM"To truly become a better programmer, you have to to cultivate passion for everything else that goes on around the programming." 100% agree. Now based on that premise, how can you become better programmer even without programming?
fade2blac on January 31, 2007 12:52 PMIf chess is analogous to programming, why can't computers write
code as well as they play chess?
Well they can't *yet*. Just as computers couldn't play chess very well 20 years ago. Today, they still can't compete against humans at GO.
Maybe if we could ensure that only "good programmers" are working on it, instead of a bunch of mediocre programmers, they could solve the Go problem as well have computers write code for the rest of us.
Just a mediocre programmer
Petey on February 1, 2007 2:58 AMReg Braithwaite pointed out an excellent discussion of this article at Reddit. It's well worth reading if you got this far.
http://programming.reddit.com/info/11vft/comments
My favorite comments?
edheil: reddit loves self-improvement.
schizobullet: Unfortunately, it doesn't love being told what it loves.
That HAS to be one of the funniest things I've read this year.
Jeff Atwood on February 1, 2007 3:55 AMBS.
I'm sorry, but I don't believe for a second that you can't change enough personally to make the leap from unable to be even a decent coder to becoming a great one. It's got nothing to do, however, with classical education. Much more to do with actual change.
I know I am an exponentially better coder than I was when I started coding fourteen or fifteen years ago. I can tell in my code, I can tell in the way I study others' code, I can tell in the way I approach the problems involved.
People change drastically over the course of their lives, they just generally do it for the worse mentally. It's an amazingly stupid assumption that people who started out as bad programmers will end up that way. I used to believe it. Then I saw people I originally had judged completely incapable of certain things accomplish them. And saw people I assumed I would hear from later disappear.
One thing I do know is that looking to a corporate manager for a judgment like this is not a great idea. You're looking in the completely wrong place. University profs who push coders from zero to 'usable newbie' are the people I would ask.
Dylan Brams on February 1, 2007 10:22 AMThe best advice I can give programmers is NOT to restrict your career path down one programming language / platform. Don't avoid C# if you have been a VB programmer for 5 years.
Why? Because in the end, it's all the SAME.
C++, C#, VB, ColdFusion, Pascal, PHP, whatever....
Sure, each language has it's quirks and idosyncrasies. Some languages take more care than others. In the end, you pick the right development tool for the job and go with it.
If you are a good programmer with a solid development methodology you can "code" in anything....
Shawn C on February 1, 2007 11:20 AMI think the reason there's so much a mixed response to this post is that the act of programming is defined differently by different people.
If you define "programming" as the time when you sit in front of a computer writing code, than the running or chess metaphors make sense and you might claim more practice will always make you better.
If, however, you include the process of figuring out what and how to code, and the way your code gets used and maintained after you finish, then it seems to me this article makes a pretty solid argument.
For me code is meaningless if it's not used by someone. If you want it to be used, you need to understand people, markets, business etc. There is no way to learn this things by just coding some more.
Nir on February 2, 2007 8:55 AMMoishe Lettvin of Google was also reading Programmers at Work, and offers his unique take on this topic:
http://moishelettvin.blogspot.com/2007/01/less-programming-more-skill.html
Love the Heinlein quote:
"A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."
Jeff Atwood on February 2, 2007 11:27 AMBullocks!
Bullocks! on February 2, 2007 11:51 AMAll you have to do is to validate this is look at who you work with and estimate if they are a good programmer (ie can get the job done) or a great programmer (can get the job done, but know why they're doing the job - ie the bigger picture).
A great programmer produces a better solution because they understand the problem better, due to the insight gained from non programming activities, and interests.
Understanding the business as an abstraction and as an instance, the specific way this company does business, will allow the programmer to become great.
Paul Broadfoot on February 4, 2007 12:35 PMIf "conscious mind" is a fraction (ex: 10%) of one's active brain power, the rest being "sub-conscious"...
How can we know what programs and designs are being written by our subconscious when we are and aren't programming?
Jeff Atwood on January 29, 2007:
To truly become a better programmer, you have to to cultivate passion for everything else that goes on around the programming.
I agree, and that is the same with any other creative work I did :-)
Shawn C on February 1, 2007 11:20 AM
The best advice I can give programmers is NOT to restrict your career path down one programming language / platform.
Don't avoid C# if you have been a VB programmer for 5 years.
Of course not. Platforms are everchanging, and that's good, because every single one of them sucked (because they were written for architectures which where slow, had almost no RAM and every design decision was made in favour of speed, smallness and cheapness, disadvantaging programmer convenience/expressiveness in the process).
Why? Because in the end, it's all the SAME.
From the programmer's standpoint, there's a HUGE scale on them. So no, they are not.
C++, C#, VB, ColdFusion, Pascal, PHP,
These are all the same, yeah.
whatever....
Look at Dylan, Haskell, Logo, Pliant, Prolog, Ruby, Python, Boo or a language of the LISP family and say that again.
Sure, each language has it's quirks and idosyncrasies. Some languages take more care than others. In the end, you pick the right development tool for the job and go with it.
Yeah. But if every tool was the same you could pick any of them for anything.
But none is the same. Members of the C family are mostly the same language-wise but completely different framework-wise.
All others are completely different from the C family.
If you are a good programmer with a solid development methodology you can "code" in anything....
... [anything] that you know
Keta Meme on February 5, 2007 12:56 PM:
If "conscious mind" is a fraction (ex: 10%) of one's active brain power, the rest being "sub-conscious"...
How can we know what programs and designs are being written by our subconscious when we are and aren't programming?
When something comes into your mind fully formed and you are making up some kind of reason for it, it came from the subconsciousness.
That is, the subconsciousness raised an interrupt on the consciousness once the subconsciousness was done processing whatever it wanted to process (passing a tiny amount of data with it).
Similar comments from Peter Varhol, editor of FTPOnline:
http://www.ftponline.com/weblogger/forum.aspx?ID=11DATE=01/17/2007blog=#717
--
Don't know where to put yourself in these situations? They are all around you, but they almost certainly have nothing to do with sitting at your desk and coding away for five days a week. There is a Toastmasters session in your cafeteria after hours, a standards committee meeting at your competitor down the street, and a study group in a conference room at lunchtime. Open source projects are begging for help, in testing and documentation writing, if not coding. You can be doing all of these things with an e-mail or two. Yes, work is demanding (I worked twelve hours last weekend, and Nancy Grace is on CNN as I write this), but just doing your job in tech is the surest way to a lengthy stay the unemployment line.
--
I was surfing the comments (still not finished yet) and ended up in a Wikipedia on Dijkstra, and one of his quote:
"Computer Science is no more about computers than astronomy is about telescopes."
Of course, he was talking about computer science, not programming :P
kwonghou on February 18, 2007 8:26 AMI was fascinated at reading the article published in new scientist on the subject of expertise. The conclusion of which was that expertise was a product of motivation.
It's all too easy to categorize people as having or not having some mysterious talent, and although I wouldn't say that there aren't people that are born with innate cognitive abilities, because after all thoughts are dependent on the brain that thinks them, which is itself a biological machine whose nature is subject to genetics. BUT!!!! What the science says is that even this so called 'talent' is merely a head-start, what makes the expert and expert is the motivation and / or inspiration to endure the pain involved with learning more and more new things.
Humans are built for survival and because of this it's normal for us to take the path of least resistance, this is why it you are more likely to hear an insightful response to philosophical questions from a youth than you do from a 40 year old, (well at least in my experience), the youth finds it easier to think out of the box and is motivated to learn new perspectives, whilst the adult has become comfortable with his box and has lost his ability to see why he might want to change it. I suspect most coders are mostly motivated to code in order to make themselves a living amongst other things, it's not that they are unable to be great, they just aren't motivated to be so.
Good programmers aren't people that see the bigger picture, people that see the bigger picture tend to become better programmers (because they are inspired and motivated to do so).
I think that the opinion expressed in this article tends to be born out of a frustration with the unfair reality whereby the motivated experts often go unrewarded for their works of genius whilst at the same time the mediocre's seem to be rewarded for creating bad code.
So, yes, there are definitely good coders, but they are not 'special' per se, they just happen to be an anomalous group of inspired and motivated individuals.
persistent ponderer on April 7, 2007 10:47 AMWhat makes anyone really good at what they do is how much they value what they do. If that value is greater than other values then skill will always increase, talent will develop and brilliance will emerge.
How much do you care about your job?
The Spaghettio on April 19, 2007 7:20 AMThere is the question of what is a better programmer, for example in the following who is the better programmer.
Three Programmers A, B and C go for a job interview. They are all required at the same time. The first part of interview process is to write a program. All three programmers are given the same problem and time to complete it.
When the time is up programmers A and B have completed the program and when the company running the interview tests the results they find both A and B have produced programs that produce the correct results although programmer A's programmer is three times faster that and uses half the memory of programmer B's program. Programmer C said he simply could not work out how to solve the problem.
The company had never emplyed a programmer and had the bright idea of asking programmer C to look at the programs of A and C and give them his comments.
After looking at Programmer A's program he said he could not follow the logic and still had no idea how the problem was solved.
After looking at Programmer B's program he said now he understands how the problem was solved and he could now write the program.
So clearly A and B are both good programmers but which is the better programmer?
In some enviroments programmer A would be prefered but my feeling is that most companies would be much better of with programmer B.
Although it can be very satisfying to write a peace of very clever code I feel it is better code if it is clear and easy to understand by other programmers and even yourself in 2 years time.
So the first question is not how to become a better programmer but what is a better programmer.
I don't think there are better or worse programmers, just more or less creative problem solvers. Programming languages are certainly more complex today with all of the different classes and methods available, but 99% of the time I still use the same commands I used in Microsoft BASIC 1.0. I still use GOSUB...RETURN, except that in today's code the subroutine is tied to an event or object in a GUI. I still use FOR NEXT loops and instead of PEEKS and POKES into memory, I wread and write from/to a relational database. I still use algerbra and calculus to manipulate my data. The only thing that really changes is the business needs and how you go from wher you're at to where you need to go. This is what Bill Gates was talking about. Are you a programmer or an architect?
Joshua Pery on April 19, 2007 8:52 AMTo me programming is about being in a mental zone, much like an artist, a guitarist, a writer, etc. It's about creating something useful and/or entertaining from nothing. One moment your editor screen is blank and the next moment it contains a function that transforms data into magic. Programming allows us to exercise the part of us that makes us superior to all other life forms.
I've been programming since 1980 (Z-80 assembler) but have been programming professionally for only 1.5 years. In college, I was continually tops in my computer courses--certainly not a result of my memory (it is poor) but rather because I "get it." Learning new programming languages comes easily for me because it makes sense to my logical brain. It could be assembler, c/c++/c#, VB (ugh), Java, etc—it’s not the syntax that matters. What matters is the problem-solving ability that generates into code. Great programmers have great problem-solving ability, at least when it comes to code. But ask me to replace front disc brakes or replace a ceiling fan and I'll struggle. Thus, I am great at programming (IMHO) but am challenged in other areas. No matter how much I practice, I'm never going to be a Liberace or Elton John on the piano. The piano is analog and my noggin doesn't process that communication medium very well.
I find the "average" programmer is pretty good at his/her craft but lacks a perfectionist attitude. I am big on writing code that is well structured, well documented, and well executed. As I told my boss early in my career, I don't know how to write crappy code quickly so if you want me to learn then you're going to have to teach me.
Average programmers rely on debuggers and code analyzers to identify flaws but great programmers can write great code inherently. Not to say they don't use debugger/analyzers (they ARE perfectionists) but those tools find much less to scream about in the latter case.
I also find that average programmers stop asking Why/How when they find a solution to a problem. I push further upstream to find answers to deeper questions. I want to know Why this works or How that black box is doing whatever it is doing.
Just as there are great leaders, great communicators, great poets, etc, there are great programmers. Not everyone agrees on what makes them great or what constitutes greatness but history will record their relative value.
troyS++;
“What is not documented is not done”
find the "average" programmer is pretty good at his/her craft but lacks a perfectionist attitude. I am big on writing code that is well structured, well documented, and well executed. As I told my boss early in my career, I don't know how to write crappy code quickly so if you want me to learn then you're going to have to teach me.
freeporn on June 1, 2007 10:50 AM"Learn about your users. Learn about the industry. Learn about your business."
Very wise.
rvdavid on November 28, 2007 4:56 AMyou scared the hell out of me with you introduction...
then talking about passion made my eyes shines ...
i can recall, every time i felt enjoying programming, was in a field that i loved and understood ( mainly local graphical modeling application )
thanks for this post !
fasteez on January 7, 2008 4:31 AMinteresting, a lot of it is simply true...
some few facts can be questioned,
anyway, a very instersting point of view.
a 'good developer' ... develops code that doesn't
hog the system's resources ... minimum number of
lines of code and in minimum time.
This is the worst definition possible. It's the exact opposite of the point Jeff was making. In order to be a good programmer, you have to *stop* obsessing soley about those programming-related metrics, and come up for air to observe what your users want, what your customers do, how your business works and how your customer's businesses work, where your industry niche is heading.
How about defining a good programmer as someone who can reliably produce programs which are useful enough to more than offset the costs of the time spent creating it?
Jonathan Hartley on February 8, 2008 5:34 AMI was recently explaining to some interviewers, who, after reviewing my resume, remarked upon all my computer related endeavors. They kept asking me about several trivial aspects of the position and whether I thought that 'with my background', I could accomplish the task. It may have seemed obvious to them that I was holding back a chortle or snicker because I realized that they were already pigeon-holing me like many people I know often do. They don't understand that I'm not interested in the actual computer but its versatility. The computer is a tool, that when well honed allows anyone in any field to become more productive. Being a programmer allows me to go through many different fields, sort of like an actor, for as long as the project is in development. Afterwards, I use the talent to explore some other interest. I have not been contacted as yet. :(
Ezrad Lionel on February 10, 2008 7:39 AMI think some very good points have been made. But lets be clear about one thing though. There is no such thing as a professional programmer/developer working in the industry; they're actually software engineers.
A software engineer working in the industry doesn't just spend his/her time coding all day: documentation must be written, creating test strategies for the code, communicating with colleages clients, understanding the client's actual issue/requirements, dealing with incompetent management, resolving disagreements etc. Improving all of these areas helps you become engineer.
Having said that though, I do believe that you can improve your coding skills. As others have pointed out the most important factor is dedication. I don't think it's a coincidence that the best programmers out there also tend to view programming as a hobby. No matter what field you work in you can't improve unless you are willing to learn and work hard. As as long as you keep finding challenges for yourself, you'll keep improving.
Keep learning new material that changes the way you think about programming. This will actually change the way you think about problems and the way you come up with solutions for them.
evil bob on February 14, 2008 5:52 AMBrett Collins on April 19, 2007 06:24 AM:
"In some enviroments programmer A would be prefered but my feeling is that most companies would be much better of with programmer B."
Right, and that's how we get platforms implementing Shellsort instead of Quicksort. Thank you for your insight, now I understand better why our industry really suffers.
Jeff Atwood on January 30, 2007 10:41 AM:
"Nobody can tell a 99.5th percentile coder from a 98th percentile coder."
Wrong. I can tell the difference, and so can they. But Brett Collins has kindly pointed out why they and I are both unemployable.
98 on February 15, 2008 12:52 PM but thing is that every time i felt enjoying programming, was in a field that i loved.
wat i suggest to new bees that Keep learning new material that changes the way you think about programming. This will actually change the way you think about problems and the way you come up with solutions for them.
I think being a good programmer is about writing good code, but being a great programmer is not, its mostly about the other aspects.
Neko on June 11, 2008 10:33 AM@Brett Collins - a better programmer is the one who can write both the readable solution and the hack-jack resource-efficient one - and will ask you which you want.
Neko on June 11, 2008 10:37 AMYes, but the world is changing. I agree, it only takes a couple of months to become a good programmer if you're fit for it. I mean, getting the grips of things like syntax, OOP, pointers/references, reflection etc. But that's the easy part!
I just started to work as a consultant and what's really important nowadays is to be able to see the whole perspective and understand things like interoperability, design patterns and architecture. You need to master several languages, frameworks, and technologies to be able to choose the right one for the application (like ORM, MVC, AoP, IoC/DI, etc. etc). Programming is the easy part! It's an continuing process because the world is always changing. Today, you need to be more than just a good programmer, you need to be able to adapt to change and contribute. IMHO, also excuse my bad engrish =)
The concept of a 'versatilist' which sounds similar to the kind of developer you've described in this post.
http://www.gartner.com/press_releases/asset_139314_11.html
Adam Kahtava on November 13, 2008 9:20 AMI got the impression from reading this blog entry that if you are a mediocre programmer who tries hard, then you will always be mediocre regardless of any incresed effort to improve your performance. I've also read other blogs where people rant about mediocre programmers ruining the profession. Usually I find those complainers are know-it-all programming snobs who think they are God's gift to humanity. Performance is subjective - we are evaluated by other humans - and some of the best programmers also happen to make the worst managers.
There are lots of actors out there in the world, yet a very small percentage will win an Oscar. Many actors may never have the opportunity to appear in a feature film or Broadway play. Yet they are dedicated to their craft and have passion for what they do. They may not be famous, and critics may pan their peformance if they do get a worthy gig. Does that make them mediocre?
I've worked in the software and I.T. business for over 20 years and held many programming jobs. Some bosses thought I was incompentent (not worthy of Senior Level Developer title said one) while other bosses thought I was a godsend. How can the same programmer be both? What I've learned over the years is:
1) Don't take manager appraisals too seriously because they are subjective. I worked at one company where my first manager liked me but her successor - who was a pompus know it all - hated me and had me fired after three months using poor performance as an excuse.
2) If you love what you are doing, you will do it well. I had one job where I did nothing but fix bugs in other people's code (no comments in code) for four years, and I grew to hate that job. That's like the actor playing bit parts over and over and never getting to shine in the lead role. How can you win an Oscar doing that? If you get mediocre assignments that you hate, you will do mediocre work - even when you TRY HARDER. The jobs where I did well had assignments where I could learn and grow. If the passion isn't there, time to move on (change jobs or even change careers).
3) Believe in yourself. If others think you are a mediocre programmer, their opinion means nothing. If they convince you that you're a mediocre programmer, then you will become a mediocre programmer. And don't compare yourself with others. These things will destroy your confidence. Just do the best you can, and if you feel you are doing a good job, that is all that matters. Everyone's career path is different. As Shakespeare wrote:
Some are born great, some achieve greatness, and some have greatness thrust upon ’em. Twelfth Night Quote, Act ii. Scene 5.
Tom on March 13, 2009 5:02 AMTo sum it up: the article implies that one should THINK out of the box.
Don't stay stuck in programming. Rather, you should try to look outside the programming realm and try to understand the things/factors that shapes how you program.
this is rubbish...
KECE on May 8, 2009 7:07 AMThe comments to this entry are closed.
|
|
Traffic Stats |