A good programmer is someone who always looks both ways before crossing a one-way street. ~Doug Linder
Working
as a software programmer in IT industry, one thing that drives us
daily to the work place; is that fun and passion lies in programming.
But to make that programming a fun and to get an eternal elation out of
it, one needs to learn and adhere to some basics which make you a good
programmer.
I
am not writing mantras which you can follow to become a good
programmer, but the intention is to collate a list of helping tips
which I learned and implemented in the industry to get good results.
There is no definition of a good programmer, but here we are referring
to the category of programmer who have developed excellent IT solutions
and helped in overall growth of this industry.
1 Work on Basics
As
it is true for any industry and any job, the conceptual understanding
is the key for success. Unless one has strong conceptual foundation,
he/she can never be a good programmer. The core conceptual understanding
helps you in designing and implementing the best solutions in the best
possible way. If still you feel gap in core computer science and your
programming language specific concepts, it’s never too late to go back
and review the basics.
Start putting question tags (how, what) with every set of code you write
One
thing that I realized creating a clear separating line between good
programmer and rest is that zeal to know what and how it is happening.
There is small group of people who can never leave a code without
knowing exactly what is happening when it executes. I understand that in
tight deadlines, we don’t get this liberty always and hence have to
leave the code just knowing that it’s doing its job. Although this is a
bit different topic of how to handle such situations, but as a
programmer one can always try the level best to dig into as much as one
can. And believe me, this becomes a habit with time and then you do it
unknowingly every time.
You learn more by helping others
Most
of us have a common tendency of turning our heads towards forums or
groups only when we need help. And again a clear separation between the
good programmer and rest that the formers visit these places more often
to help others. This makes them learn more then they learn getting
their problem solved by someone else. Within a team as well, help
others to solve their problems. Believe me, understanding others’
problem in their context, investigating on that and providing
solutions; will leave you much more learned than before.
Write simple, understandable but logical code
As
in almost every aspect of life, the formula of KISS (Keep it simple
and short) works in programming as well. Write more logical code and
avoid complexity. Sometimes people do write complex code just to prove
their capability to write such codes. My experience says that simple
but logical codes always works well, resulted in fewer issues and are
more extendable. I remember an excellent quote
Good
code is its own best documentation. As you're about to add a comment,
ask yourself, "How can I improve the code so that this comment isn't
needed?" ~Steve McConnell
Spend more time in analyzing the problem, you’ll need less time to fix it
Spend
more time in understanding and analyzing the problem and designing
solutions for it. You will find the rest of the things quite easily
doable. Designing not always mean using modeling languages and tools, it
can be as simple as looking at sky and thinking solution in your mind.
Those who have habits of pressing keyboard (for coding) the moment get
the problem, usually ended us something different than the
requirement.
If you cannot grok the overall structure of a program while taking a shower, you are not ready to code it. ~Richard Pattis
Be the first to analyze and review your code
Although
a bit difficult, but try to break your own code before others can and
with the time you will learn to write close-to-bug-free code. Always do
a close and unbiased review of your code. Also never hesitate to take
others view on your code. Working with good programmers and taking
their feedbacks will surely help you become a good programmer.
Don’t dismay yourself by looking at changing technology world
Over
these periods in IT industry, I met with many people who are either
disappointed by their work or even left it to search new job saying they
want to learn and work in latest technologies. I don’t see any problem
with this aspiration but the very first incorrect word is the ‘latest
technologies’. What we are hearing everyday and mean here is new tools,
APIs, frameworks and others means coming up everyday to make the
programming easier and quicker. This anyway will continue in technology
world. But what needs to be understood is that the core and basic
technologies changes with much lesser pace than frameworks, tools and
APIs around it. This is like the sea where the surface water moves very
rapidly but the deep water is relatively calm and concentrated and most
of the aqua lives survive here. So, feel yourself in that deep water
and close to core technologies. For e. g. in Java enterprise world,
lots of web frameworks exist and new ones coming every other week. But
the core concepts of request based client-server communication, MVS
pattern, filters/servlets/JSP, resource bundling, XML parsing etc
remains same. So spend more time in learning these core concepts rather
than worrying about ever changing frameworks and tools around it.
Believe me, with the foundation of core concepts, you will always find
easier to learn new frameworks, tools and APIs.
Work-arounds don’t work for longer time
Many
times software programmers implement work around solutions (may be
because of lack of time, lack of problem understanding or lack of
technology experience).But over the period these work around solutions
always resulted in corrupting the code, making it less extendible and
maintainable and lot of wastage of time later on. Always prefer to
implement when you know the in-out of the solution. I understand that
it becomes unavoidable in some circumstances, but it’s like, one should
speak truth always but you tell lie in some circumstances.
Read documentation
One
of the essential habits of good programmer is that they read lots of
documentation. May it be specifications, JSR, API documents, tutorials
etc. Reading documents helps you creating that essential foundation
based on which you program in best of the way.
You can learn from others code as well
I
interacted with some excellent programmers who actually have java
source project inside their IDE all the time and read/refer that in
daily work. They do it not only to fulfill their appetite of knowing the
basics but also to learn ways of writing good programs. Reading and
referring reliable and known open source code or your senior’s code, can
also help you making your programming better.
And the last, not listed above: Don’t compare yourself with others
Your
comparison of yourself with others will only result in evolution of
negative feelings and un-healthy competition. Everyone has got his or
her strengths and weaknesses. It is more important that we understand
ours and work on it. I have seen many times that so called
‘fundoo-programmers’ (fundamentally strong programmer) also make silly
mistakes. So, analyze yourself, list down your areas of improvement and
work on it. Programming is a real fun, enjoy it.
Any fool can write code that a computer can understand. Good programmers write code that humans can understand. ~Martin FowlerSo most of the tips below are lessons learnt from failed endeavours, they are
1.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 endoresements.
2. 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
3. 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 whats written.
4. 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
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.
5. 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.
6. 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.
7. Learning by emulation:
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.
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.
No comments:
Post a Comment