Scientists who study memory, cognition, and language acquisition would be the first to tell us that there is a huge difference between receptive (listening/reading) and productive (saying) use of a language. People can produce language without being able to understand it (sometimes a side effect of brain trauma or hearing/reading problems). People can understand language without being able to speak it.
As anyone who has thought hard about their experience learning language will realize, we are most skilled in the languages where we have both read and produced the language. To write well in English, one has to read a lot of English. But one also has to write a lot of English. And if we had a good English teacher, we were positively encouraged to reinvent the wheel and try to write our own sonnets or haiku about spring, love, puppies, or anything else that interested us. In fact, the starting point of all good authors is their passion.
We also learned from our best English teachers that good authors also let others read their work - first their teachers and a close circle of friends they trust (or sometimes a remote publisher, because anonymity hurts less). They take in the feedback and improve their writing style, think more about plot lines, listen (finally) to the person that says "don't write a historical novel without research", and so on.
Some of us learned this way to appreciate the passion of others and decided that writing was not our thing. Some of us found writing hard work, but still persisted. But one way or another, we all benefited from the experience, whether as more appreciative readers or as people that grew up into successful professional writers.
Though I haven't seen any studies on this (I admit I haven't looked), my hands-on annectdotal experiences leads me to believe that the best programmers and designers are not that different from the best poets and novelists. To write good code one has to both read and write it. We need to understand a problem in such depth that we get past naive understandings (the equivalent of stereotypes and cliches in novels and poems). We have to love something enough that we are willing to take the time to research the RFC's, learn about file systems and their quirks, and still want to try our hand at it.
It is very hard to understand the complexities of a problem until we have gotten down into the dirt and tried to design and then code a solution. Until we do that, we are viewing fields and mountains from a mile high and see nothing but large patches of green and brown. Eventually, we must take the risk and show that code to others so they can critique our style and plot lines and character development (a.k.a. design).
So long as the would be author (programmer) is willing to both write and read, research and create, I see no problem with "reinventing the wheel".
Your post and the various responses have really made me wonder if we shouldn't refocus our efforts. Instead of slapping people on the hand when they reinvent the wheel, maybe we should focus on teaching them when and how to do so? chromatic makes very good points, but wouldn't they be better taught by encouraging students to write a file system searcher (or other wheel of their choice), and then requiring them to couple the code with a research paper comparing their code with appropriate standards and background reading plus a critique of at least one other program trying to do the same thing? This would, I think, do a lot to more to teach people the skills and judgment to create well designed programs than would all the lectures in the world on "don't".
Best, beth
In reply to Re: Reinvent the wheel!
by ELISHEVA
in thread Reinvent the wheel!
by telemachus
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |