On becoming an expert C programmer
|[chongo's home] [Astronomy] [Mathematics] [Prime Numbers] [Programming] [Technology] [contacting Landon]
The following is from an EMail message that I sent to to an individual on 12-Apr-2001. You may find this EMail message useful.
The Writer asked:
``I just recently visited your website ... Just wanted to say greetings and ask a simple question: Do you think I stand a chance in the C programming field if I keep it up? Tell me what I should do in order to keep strong feelings towards C.''
Here is my reply:
Thank you for your kind words.
``... Do you think I stand a chance in the C programming field if I keep it up?''
YES!! Persistence and determination are important keys to success.
``Tell me what I should do in order to keep strong feelings towards C.''
Permit me to babble out a few random thoughts ...
Write programs for other people.
Where possible, openly publish your code, perhaps on your web site. Open source repository sites such as the Source Forge site is a good place to announce new code. Another good site to consider publishing at is http://freecode.com/.
Very important: Support the code that you publish.
Start small and work your way up ... Some of my more popular code is actually small code fragments that are used by others over and over again.
Don't be discouraged if nobody (or if only a few people) uses some of your early programs. What is important is to practice writing quality, well commented code ... to maintain and fix that code.
It is somewhat easy to write a program that works. It requires practice and effort to write code that you can maintain and support. The programs that win the IOCCC (see www.ioccc.org, a contest that I founded back in 1984) are NOT good programs. While they work, and some work very well, they cannot be maintained or improved ... often they cannot be maintained or improved even by their original author.
Parts of a well written program can be reused or borrowed by other programs. Reuse your code when possible. In fact, write your code well (with comments, etc.) the first time ... even if you are just writing a quick 'hello world' program.
If a program is not worth writing well (perhaps because you think it is just a quick test code fragment ...) then it is not worth writing in the first place.
Always, always, always write code as if it will last 30 years ... some of your code can live that long. Write code as if you expect to some back years later and work on it ... long after you forgot the details of the code. Don't write clever obscure twisted hacks. Those write clever obscure twisted hacks are hard to maintain and reuse later.
NOTE: This especially applies to short, simple test programs ala ``Hello, world!''. Comment even the smallest quicky programs. If nothing else, it is good practice and maintains a good habit. Consider keeping such code fragments.
Keep a collection of programs and samples. The first time you write something, like a set of functions to manage a linked list, safe that code in your samples directory. The NEXT time you need to deal with linked list, go back into your samples directory and reuse it. If you find a bug, or a better way to do something then update the code in your samples directory.
Remember that I suggested you should always write code as if it will last for 30 years? Well if you keep your collection of sample code around ... some of it will.
Your speed will pick up with practice. Your speed will increase as you build up a portfolio / collection of sample programs and code fragments. If you write something well once, you can reuse it again and again later on with little extended effort.
Code like you are an artist ... even if you feel your initial programs are not very good. Make the effort to improve. All artists start out not drawing very well. But their will to express themselves and PRACTICE helps them improve and improve ...
BTW: Some of the better programmers are musicians. Learn to play an instrument / read music / play music for someone else. Art seems to stimulate the mind in ways that are very helpful to programming. Someone can plunk a tune on an instrument if they memorize the notes just as someone can write a program that appears to work. But it takes practice and the will to want perform it well to turn those notes into something interest to listen too ... just as it takes practice and the will to want to code well to write good programs that last.
Just as a beginning musicians just start out with simple tunes, a beginning program must start out with simple programs. You don't expect to write a and conduct a symphony at age 14 (unless you happen to be Mozart :-)) ... you shouldn't expect to write the next 'killer app' at age 14 either. HOWEVER ... practice and have the will to improve ... in time you will exceed the j-random programmer and become very good.
A good program or code fragment will want to be improved. You know you have done something well when others (or you) want you to add this feature or improve it. It is OK if someone complains about bugs ... you will never be perfect anyway. But if someone complains about a bug, it is because they WANT your program to work because that LIKE the idea that your program is trying to express. At least they are paying attention to your code!
Writing games are sometimes a good way to get people to use your code.
Writing a tools is a good habit to get into. If you find that you are doing something over and over again ... write a tool to do it or to make that step faster. Act "smart and lazy". Write a tool to deal with repetitive tasks.
Don't be afraid to step out of the C box. For example, learn Ruby:
http://www.ruby-lang.organd learn Perl:
There are some things that C does well ... there are some things that Ruby does well and some things that Perl does well. Being a multilingual programmer helps make you a better programmer. Don't just program in C.
Interact with other programmers. Learn from them. Download their code and look at it. Learn from what they do well ... avoid what they do poorly. Talk with others about how they do their code.
Pay particular attention to open source code. Some of it is OK, most of it could be written better. Because it is open source, you can borrow code and code fragments and drop them into your sample code directory.
Look at some of DBell's code:
http://www.tip.net.au/~dbell/Learn from it. DBell is one of the best programmers on the planet.
Find bugs in other people's code. If you find that a particular open source program fails / has some sort of bug, try to fix it. Report the bug to the author. If you fix it, send in a fix later. Apply bug fixes and patches when the author releases them.
Maintaining and fixing other people's code is EXTREMELY important skill to have. It is good practice for your own efforts. In the job world, most if what you will do is to fix and improve code that already exists ... so learning to do this early and well will make you a valuable employee later on ...
Correctness is not the only goal of programming, but it is a good beginning.
Correct output doesn’t imply you are done, it implies you may have just started producing something useful.
Correct output isn’t a sufficient condition for good programming, it is simply a prerequisite to begin to evaluate the quality of a program.
Correct output can look like the output of a bad program producing the right answer for the wrong reason.
Remember that every International Obfuscated C Code Contest winner also worked as documented when they won.
International Obfuscated C Code Contest winners work, but they are utterly useless in a production environment.
Back up and protect your sample code directory. Plan to keep that portfolio of code for many years ... don't let a disk crash, theft of a system or other disaster wipe out your work. Always plan to keep that code with you ... as you move from job to job. Don't keep your only copy at your job/school ... you will change schools/jobs and you don't want to lose it. Don't keep your only copy at your home / website / laptop. Those things crash or can get lost.
Spend some time looking at the C Programming Resources I have collected.
It takes time to improve. (See Peter Norvig's "Why is everyone in such a rush?" essay). It is NEVER too late to start.
You are never too good to improve. When I look at code I wrote just a few years ago, I still see code that can be improved. Even though that code had decades of experience behind it, I feel that I could do it better today ... and make the effort to do so.
Did I say code like an artist? :-)
I hope this helps.
Best wishes on your path to being a better C programmer.