|
The value of formal training is that the programmer has a wider variety of tools to use in attacking a problem. The self-taught programmer tends to have a favorite 'wrench' for every problem.
Self-taught programmers have something that the other programmers don't: the ability and motivation to learn on their own. They're the ones to dive in and try things. The best ones are often early adopters.
If a self-taught programmer isn't flexible and willing to adapt, they tend to stagnate at one level of skill. If the formally-trained programmer stops learning when the training is over, the same thing happens. The key is to continue learning, regardless of how you got your start.
Software Zen: delete this;
|
|
|
|
|
I agree with the sentiment that continual learning is the key to success in the world of programming.
I am a self-taught programmer, that has had a lot of exposure to "formal" concepts via interaction with formally trained people, and a lot of reading.
I have to say, that without that exposure, I would not have been able to advance beyond a certain level of skill, but I disagree with the idea that where or how you learn these ideas is relevant to your ability to use them.
The biggest difference that I see between self-taught and school-trained people (in any field) is that self-taught people tend to be bigger risk-takers, take action earlier, and thus yield results earlier. They also tend to be the innovators in the technology field.
I disagree with the "favourite wrench" example. In fact, I think the opposite. A school-trained programmer is likely to view their education as a static collection of different "right ways" of doing things, and then look at the problem, and choose what they think is the "right tool for the job". Often, they tend to be biased toward a methodology that they find more interesting than some other methodology, and apply it where it doesn't belong. In more abstract terms, they are living in the solution domain, not the problem domain. They are more likely to change the nature of a problem to suit a particular solution than to change the solution to fit the problem.
The self-taught programmer, coming from an attitude of "find a way to make it work", lives more in the problem domain, rather than the solution domain. They look at the problem, and follow this process until success:
1) Use a solution they have used before that worked for a similar problem
2) Do some research by asking others, reading websites, books, etc, until they find a solution for this type of problem
3) Invent a totally new solution that suits the unique problem.
I find that school-taught programmers *rarely* make it to step three. They have greater success at step one, because they have more solutions under their belt to work from.
Impatient self-taught programmers will often never make it past step one, since they are always able to find some way to twist their limited abilities to "make it work" (though not in a "good" way). They tend to have a harder time during step two than school taught programmers, because they have to get over their own egos, and admit they don't know something. A lot of self-taught programmers are very proud of being self-taught, and dislike admitting that there is something they don't know already.
This has an interesting effect, in that a self-taught programmer will often skip step two completely, or just do a minimal job of it, and assume "there is no existing solution to this problem", and move on to mode three.. They will work hard to invent something, and then afterward talk about it as if they did something really amazing that other people can benefit from. To thier surprise, they find out that if they had spent more time during step two, that the solution already existed, and in fact is more formalized and mature than their "invented" version of it. It's only then that the self-taught programmer realizes that they shoudl have done better research, and then they will go and learn the formal version of the idea, while munching unhappily on the foot in thier mouth.
In rare cases though, the self-taught programmer will be very good at step two, and still find themselves in situations where they need to progress to step three... and that's how a lot of advances in software technology happen.
Without that do-it-yourself spirit, and without the ability to focus on the problem-domain, it's extremely hard to advance past the second step.
Anyhow, these are just general observations. I personally fall into the self-taught category, and I find I spend most of my time in "step two". In fact, these days I start there. With technology changing so quickly, the solution I used last year, may no longer make sense to use... So the first thing I do, (even for things I think I already have a solid solution for) is go out and see how other people are solving the problem with the latest technology. If there is no new method, I use my known method. If there is a new method, I implement it both ways, test the results, and try to figure out which is a better way to go.
I almost never have gone to the third step, and the few times I have, I end up with my foot in my mouth... Someday I might actually need to invent something new, but I doubt it.
Thanks,
Troy
-----
"Be liberal in what you accept, and conservative in what you send." - Jon Postel, First Law of Internet Communications
"It's 5:50 a.m., Do you know where your stack pointer is?"
"If at first you don't succeed, you must be a programmer."
http://vanguard-against-confusion.blogspot.com
|
|
|
|
|
I voted "Self taught programmers generally make better developers" but that depends in what area you end up programming. I know some jobs where I'd prefer a systematic, formal programmer to a genius cowboy (and vice versa.)
regards,
Paul Watson
Ireland & South Africa
Fernando A. Gomez F. wrote: At least he achieved immortality for a few years.
|
|
|
|
|
I've worked with both. The systematic programmer works best in a group on large projects, whereas the cowboy is best on his own with smaller work. Cowboys don't seem to get the 'big picture', and will make sweeping changes without regard for the global implications of what they're doing. The formal programmers are good at coloring within the lines, but they're not always innovative in the crunch.
Software Zen: delete this;
|
|
|
|
|
I'd have to disagree with this conclusion.
I think of myself as a cowboy. I work on a team, but often work on projects that are a solo effort. I'm fortunate that I can turn out excellent solutions that are well received by the customer. Some of my projects are quite big both in functionality and reach throughout the organization, and one of my biggest strengths is understanding business processes and the "big picture."
Not to be all about me, either. I know of a few other people that I think fit this category as well. Not many - but a few.
|
|
|
|
|
I was generalizing based on my experience.
I've seen cowboys that could work well in a large effort with a team, and I've seen more formal types that were good self-starters. My feeling is that programmers like this are simply good at adapting to the work environment, which strikes me as the ideal.
Software Zen: delete this;
|
|
|
|
|
Self taught doesn't mean that you don't use formal techniques, it just means that you didn't attend an offical programming coarse
|
|
|
|
|
|
It is asking more about how you got the "formal" techniques. Through formal training or through trial and-error/self-taught. And which of those results in the fundamentally better programmer.
regards,
Paul Watson
Ireland & South Africa
Fernando A. Gomez F. wrote: At least he achieved immortality for a few years.
|
|
|
|
|
I would say the contrary. I am a high school student and I consider myself self-taught. I started programming before I took a programming course, here is quick chronological order of my education: (I still consider myself self-taught).
- Self-taught programming begins 8th grade
- Intro/Intermediate Programming HS Sophomore year - C++ Programming; I knew more than the instructor
- AP Computer Programming HS Junior year - Java Programming; Same instructor as Intro/Intermediate, towards the end of the class I was teaching the rest of the students
- 2008 - Intro to VB dual-enrollment college class in HS senior year - I knew everything taught by the instructor; some information was knew and my programming adapted
- 2008 - Adv. VB dual-enrollment college class in HS senior year - I still knew most information; easily catches on to new concepts
I guess for the most part, I consider myself self-taught. This is not because I use formal techniques, it is just that all of the formal programming classes I have been in I already knew all the information for.
Regards,
Thomas Stockwell
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Visit my homepage Oracle Studios[ ^]
|
|
|
|
|
I've found that formal training gives a good foundation, but learning does not stop when university is over. With software development learning happens constantly and the person needs the personal motivation to continue to learn on their own.
While there are good developers without formal training, I would recommend it. But what I recommend mostly is that a good developer will want, hunger after, new information all the time.
|
|
|
|
|
At one point, i worked for a very small company and for awhile we had a problem with getting less than competent developers. The formula we found that worked was high test scores and low grades. What you are really looking for is intelligent individuals who aren't necessarily locked into one framework.
|
|
|
|
|
I'm a self-taught programmer who has enjoyed a successful 30-plus year career writing code. The key for me, and this has been mentioned by others, is constant learning. I began in high school, reading all the computer architecture reference manuals I could get my hands on, programming in assembly language, and reading/modifying operating system code. I later worked in C, C++, Cold Fusion, and now .Net. Assembly language will always make me feel warm and fuzzy but one must keep in touch with industry trends, and also be interested in industry developments in general.
In all honesty, though, there have been a few occasions when I became aware of my lack of formal training. Specifically, knowledge of algorithms. But then again, that involves math which I've always hated with a passion. Formal methods, frameworks, etc. can easily be learned outside the classroom.
Edward...
modified on Tuesday, April 1, 2008 12:28 PM
|
|
|
|
|
To be a good developer requires experience.
You need to write a lot of code and you need to work with (and learn from) a lot of other peoples code.
|
|
|
|
|
MRLacey wrote: To be a good developer requires experience.
To be a great artist, one studies the previous masters of art.
Why don't software developers study previous masters? Instead, we learn the same mistakes over again. 
Gary
|
|
|
|
|
I found this to be a very big weakness with the formal education that I got. There was very little dissection of previous well written works.
John
|
|
|
|
|
I agree. The 500K+ lines of MFC code I have written since I have started working in 1997 are what I consider my biggest asset as a programmer.
John
|
|
|
|
|
I bet, common sense make you better developer!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You/codeProject$$>
|
|
|
|
|
Alas, there's no such thing as common sense. - It just isn't common!
|
|
|
|
|
in my experience common sense in this field is, more often than not, dead wrong.
|
|
|
|
|
mean! ?
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You/codeProject$$>
|
|
|
|
|
Common sense is pre-optimisation. A normalised database is common sense. Post-optimisation you rarely have a normalised database.
regards,
Paul Watson
Ireland & South Africa
Fernando A. Gomez F. wrote: At least he achieved immortality for a few years.
|
|
|
|
|
|
Yes, mean and meaning:
Common sense is a naughty term - one is supposed to 'naturally have it' - and to assume one does.
As such it invites unthinking consent in stead of critical analysis. it is designed to attract voters:
"common sense solutions" based on 'obvious' but often very shaky arguments.
cheers,
koos
|
|
|
|
|
koos4ever wrote: ommon sense is a naughty term - one is supposed to 'naturally have it' - and to assume one does.
thats the reason one become great programmer after that 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
). But back to your message: Maybe you use the formal techniques, but you are more encouraged to develope your own ideas and you create your own algorithms that you usually don't forget, thus often you can adapt them to other problems. Formaly taught programmers often have to develope algorithms rootedly under pressure of time. I think this leads to not so perfect algorithms 
