Practice
Write lots of
programs, especially big programs. A lot of good practices become obvious once
you've made the typical mistakes.
Writing small
programs lets you write more programs in the same amount of time; this will
improve some of your programming skills much more rapidly, but others not at
all.
Modify existing
programs written by other people. Reading code without having previous
knowledge of it is a valuable skill - you can't debug without it --- and you
don't get much practice with it when you're writing programs from scratch by
yourself. If you reflect on what you've found hard to understand, it can also
help you learn how to write maintainable code. Also, this lets you work on many
more big programs than you would have time to write yourself from scratch,
which helps a lot with those skills that only apply to large programs.
But...
CodeLessTestMore.
Refactor
Learn about
Refactoring.
Spend a lot of
time Refactoring and improving programs, even if they work fine.
Design
Learn about
Software Design Patterns!
Code Review
Find some good
mentors and let them review your code, and try to do some PairProgramming with
them.
Find some peers
with whom you can review your code. People of similar skill levels can teach
each other a lot. And this gets around problems with sharing your "bad
code" with a senior person who might give you a harsher critique than you
want (not to mention a bad performance review).
Learn from good programmers
Read Great Programs.
Adapt some good
code (I learned a lot about C idioms while adapting a Btree Index library in
order to add compound key index feature).
Team with good
programmers. Sit at their knees and learn. Emulate their habits. Do not insist
they adopt your practices/tools/habits because you think you know a
better/faster/cheaper way.
Broaden your horizon
Learn multiple
programming languages. Each language you learn will give you ideas about how to
do things better in other languages. (The worst programmers I know are the ones
who think that language X is the only one they need to know.) See
Learning Programming Languages for related tips.
Learn different
kinds of programming languages: procedural, functional, Object Oriented, etc.
See Ground Breaking Languages.
Learn multiple
operating systems. Learn to write portable code.
Read
Read books about
code quality, like Code Complete. It can save you a lot of time.
Buy the book
The Pragmatic Programmer and read it, learn it, live it.
Generally, read
Great Software Books
Read books about
other subjects. Philosophy, history, art... anything. Become a broader person.
It doesn't directly affect your programming as such, but it widens the mind,
which has to be a good thing.
Learn the Problem Domain
Get into the habit
of understanding the problem domain. Try to create a Mind Map for the problem.
Spend good amount of time learning about it. A good knowledge of the problem
domain goes a long way in creating good code.
Work closely with
end users. Get their honest opinions about the software you make. It doesn't
matter how many algorithms or data structures you know if you aren't making
someone's life better.
And on a similar
note: learn from your users. Try to understand where they're coming from. If
you learn the problem domain, their requirements make more sense and you get
closer to being able to give them results that will do what they wanted, not
what they asked for.
Reflect
If somebody
complains that they don't understand your code, find out what it is they don't
understand. ("That guy is an idiot" is generally not the reason.)
Every time you fix
a bug, think about how you could have avoided the error in the first place, and
what could help you avoiding it next time. Some of the answers lie in GoodCode
quality principles, and others in good programming practices.
By the way, just
stop thinking that bugs come to life just from disruption or fatigue. Bugs
proliferate in poorly written code. (But do remember that rest and
concentration are requirements for doing good work)
Learn to quit
habits and to adopt new habits.
Take a break. It's hard to do any of these
things when you're already coding all week, as fast as you can.
No comments:
Post a Comment