Sei sulla pagina 1di 6

How do you become a good programmer?

Decide why you want to become a good programmer:


Is it because you want a job, preferably in a high paying software firm? Great.
Then you are set to reach NOWHERE. All good programmers I know are good
because they loved what they did. Develop interest in programming. See,
programming is the only branch in engineering where you can straightway apply
what you learn. Your dad may have a car but he certainly wont allow you to tweak
the V2 or swap it for a v6 just to see what happens. But with computers you can do
whatever you want. You want to simulate a virus? Cool. Install a virtual OS and
run it. Then, when you are done, remove the virtual hard disk. If you are good at
what you do, you will get paid and surely get that dream job. Yes, even I want to
work in a big software company. But thats not because of the fat paycheck. Its
because of the work they do. Because of the exposure I will have. Have you ever
bothered to find out what all these companies do and the enabling technologies
behind their products or the kind of R&D they do? Jobs will come. Dont make
yourself a sucker for one. Sachin is not a great cricketer today because he decided
to play cricket to earn money and get dozens of endorsements.

1. Programming languages: Very often people equate good coding skills
with number of programming langauges known. Thats just damn untrue.
While knowing a lot of programming language is good and sometimes,
even, essential; it is more important that you know one or two lanugages
very well. I 'know' and have used more than a dozen programming
languages and yet C and Java are the ones I am truly comfortable at.
Thats sad of course. I really wanted to be good at Assembly and Lisp as
well. Never got the time or chance to develop those skills. To be good at
a language takes years (at least 2 years). Being good at a language means,
you understand where it is best used and where using that language
makes no damn sense. On the other hand, knowing a language takes
anywhere from 3 days to a week. If you are a beginner, learn C first.


Don't buy Yashawant Kanetkar. Buy the book "The C Programming
Language" by Brian W Kernighan and Dennis M Ritchie (If you don't know who
they are, do this 1. Slap yourself 2. Google their names). This book is not the
easiest but is the best. Its a small book but it is the most powerful. Generations of
programmers have been brought up on it. And if you think this book is tough for
you, please do not harbour any misplaced desires of being a good programmer and
do not waste your time by reading this post further. Programming is an art (not a
science. Yes you read it correctly), and like any art it requires painstaking effort.

Some people suggest Python as the first language to be learnt. Python is certainly a
good language and is easy too. But you will have to rely mostly on the internet for
help as not many around you would know Python. Also C has the broadest usage
among all programming languages. Also please DO NOT use Turbo C. Its so damn
outdated. Use GCC. If you are in Windows download Dev C++. It has GCC
USE GCC INSTEAD TURBO C

Read this (small) essay by Peter Norvig Teach yourself programming in 10 years . Again, do a
Google :D search and find out who Peter Norvig is.

2. Algorithms: Any good programmer has a good understanding of
algorithms. Its not necessary that you know each algo by heart (in fact
good programmers never learn things by rote) but you must understand
when to use what. Algos will broaden your understanding and give you
new ways to tackle problems. Another important thing is Data Structures.
Its more important than algo. Once you have chosen (or developed) the
correct data structure, the algorithm becomes self evident. For algo, read
the book "Introduction to Algorithm" by Thomas H Cormen et al. You
may also refer Andy Tanenbaum's "Data Structures in C and C++". Also
if you have desires to participate in coding contests (the respectable
ones), "The Art of Programming Vol I to V" by Donald E Knuth are
mandatory. Also may be "Concrete Mathematics" by Donald Knuth.
Again reading does not mean remembering everything. Just try and
understand what is written.

3. Coding contests: Coding contests are good for developing your
algorithmic skills and they make you think fast. Its a good idea to
participate in ACM ICPC or Page on topcoder.com. Then there are
coding contests (like Sun's Code for Freedom, Google's Summer of
Code, Microsoft's Imagine Cup) where you develop a complete software.
Such contests are spread over many months. Both require different sort of
skills. You may be good in one and bad in another and yet you could be a
good programmer. Contests like ICPC require lot of practice, fast
thinking and you are expected to keep algos at the back of your mind.
CFF, GSoC, on the other hand, requires creativity and focus spread over
a long period of time. You dont have to come up with solutions too fast
and you dont have to mug up algos. ICPC is like T10 while CFF,GSoc
and Imagine Cup are like Test Matches. I would suggest you to
participate in both types and then decide if you want to focus on either or
both.

4. Participating in FOSS projects: You MUST participate in some free
software projects. There are just too many. I am working on SCALASCA
right now and then I will move on to Sun Grid Engine and Sun xVM
Hypervisor and contribute code there. You learn a lot from these. You get
to see a lot of code and learn the best practices. And did I mention, it
looks good on your CV too. Most people catch cold feet when they go
through some of the prerequities of such projects. Take Thunderbird for
example. You would need to know a lot of C/C++ and Javascript (for
developing modules). Now don't wait till the day you are an expert in
these languages before contributing. Programming is an art, don't waste
time sharpening your pencil when you should be drawing. You can ask
me for directions.

5. Design Patterns: Any art is learnt by emulating. And therefore, you must
emulate the best. Design Patterns are tried and tested architectural (of the
software kind) solutions to some commonly encountered software design
issues. And therefore, a basic knowledge of some common design patters
in needed if you are planning to develop something that is even
moderately complex. I suggest "Head First Design Patterns" from Oreilly
as the first step.

6. Learning by emulation: [ In computing, an emulator is hardware or
software or both that duplicates (or emulates) the functions of one
computer system (the guest) in another computer system (the host),
different from the first one, so that the emulated behavior closely
resembles the behavior of the real system (the guest).]

Emulate the best. And this is possible by reading books written by the
best and/or going through code from some of the best free software
projects. I would urge anyone serious about programming to read the
book "The Art of Unix Programming" by Eric S Raymond (dont forget
to first slap yourself for not knowing who Eric Raymond is and then
googling his name). You are not a programmer if you have not read that
book. Period.

Now let me address a few common grouses

a. I dont find any interest in computers and want to do an MBA:Mainly
a statement often repeated by Second Year(sophomore) students. Thats
really your problem. I did not ask you to take Computers or even to join
Engineering. You did not know, or bothered to find out, what you were
getting into when you took up this branch of engineering and I am pretty
sure you have NOT bothered to find out what awaits you in a MBA
course either. I am also quite sure that 2 years after an MBA (if not
earlier) you will also say pretty much the same thing about your job. Well
what can I say.
b. I dont like reading the books (or any books for that matter) that you
mentioned above: Well this is not yet the world of Matrix where I can just feed in
programming skills to your brain. Dont force yourself to read them. You can't . Do
it only if you want to. And if you don't, please forget about being a good
programmer. May be its time for you to use the excuse mentioned above (point a).

c. Give me one programming language that does all: There is none. Each has a
different purpose. And thats how things are gonna remain buddy.

d. I want to a 'real' project: Thats great. You can do two things:1. Start one of
your own 2. Join a FOSS project. But most people are not happy with this. They
expect me to 'give' them a project, one thats easy (read, should not involve
anything other than C and the only files you need to include should be stdio.h,
conio.h (yes people here still use Turbo C) and may be string.h and math.h) and I
should tell them what to learn. When people say this,they expect to go on a
Autopilot ride.

e. I will learn X programming language by this sem/year/decade :There is no way
you can sit with a book and learn a language. You need to do some real work with
it, develop some real software and not just do those exercises in the book (that is
necessary of course but not sufficient). Most of the languages I have learnt are
because I was forced to do so as part of some project. Just pick up the basics in a
day or two and then apply it to a real life project. Need ideas? Come to me.

Finally as Larry Wall says in Programming Perl : "We will encourage you to
develop the three great virtues of a programmer: laziness, impatience, and
hubris."

Laziness:
So that you go to great effort to reduce overall energy expenditure. It makes you
write labor-saving programs that other people will find useful, and document what
you wrote so you don't have to answer so many questions about it. Hence, the first
great virtue of a programmer

Impatience:
The anger you feel when the computer is being lazy. This makes you write
programs that don't just react to your needs, but actually anticipate them. Or at
least pretend to. Hence, the second great virtue of a programmer



Hubris:
Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes
you write (and maintain) programs that other people won't want to say bad things
about. Hence, the third great virtue of a programmer.
By Abhineet Swain .

Potrebbero piacerti anche