This advice by Philip Chu is
highly influenced from Steven Covey in his best-selling book, The 7 Habits of
Highly Effective People, but is really a high quality read - peppered with
illustrative real world programmer tales. I am just putting bullets points and brief
description in the blog here; however you must read the complete article at http://drupal.technicat.com/writing/programming.html.
Also other articles at Philip’s site is certainly worth a read.
1. Understand Your Requirements
The first step
in becoming an effective programmer is to ensure that you are spending your
time wisely. And there is no greater waste of time than in working on something
that is not useful or never shipped.
Gets a
demonstrable system working as early as possible?
Once you have
something working, don't just leave it as a "proof of concept". Let
people play with it, see their reactions, and let this guide and prioritize
your development.
2. Keep It Real
Keep your
software running in as close to a shipping state as possible. You never know
when you'll have to demo the system, send out an evaluation copy, or even
deliver ("OK, time to wrap things up!")
If you just
test with sample data, that big iceberg of real data out there is going to sink
your program, hence use real data.
The development
build on your machine is not the real build, hence use real build machine.
Don't
procrastinate on merging your code with the main code base - the longer you
wait, the harder it gets
3. Understand Your Code
Life is full of
wonderful mysteries, but your code is not the place for them. You don't have to
know how your car works - if the engine starts making strange noises, you drop
it off the mechanic. When it comes to your code, if you don't understand how it
works, or doesn't work, no one will.
The best
writers and coders have an esthetic and their work features structure and style
that can often be identified with the author.
You should
periodically inspect your code, sweep up accumulated hard-coded numbers,
outdated comments, misleading function names, or you'll inevitably end up with
uninhabitable code that's embarrassing to show anyone else.
Document your
code as if someone else might have to take it over at any moment and know what
to do with it.
Ignore compiler
and runtime warnings at your own peril. They are called "warnings"
for a reason.
4. Optimal Programming
On the other
extreme from cut-and-pasters are those who change code just to make it look
prettier (at least to them). While it's laudable to have a programming
esthetic, it's a waste of time (and a useless risk) to change code just so it
looks better to you.
"Refactoring"
is all the rage, now, but programmers often take it to mean any code cleanup or
redesign. The trick is in reorganizing code for the better without breaking
anything.
If you do need
to optimize for speed or space in you application, attacking anything other
than the bottleneck is a waste of time.
5. Manage Thyself
You probably
have a lot of complaints about your boss being a lousy manager, and you're
probably right. So you have to be your own manager. Even if you have a decent
boss, he's not going to stand behind you telling you what to type and how fast
Programmers are
notoriously inadequate at providing useful schedule estimates. I think this is
a bad rap, since management, left to their own devices, often make even worse
predictions, and unwelcome news from engineers is often ignored. (A common
theme in any engineering disaster). But still, awareness of the schedule is
critical to actually getting the project done on time.
You wouldn't
just hop into your car before deciding where you want to go, right? And
probably you have a route in mind before you start driving, too. Similarly,
before you sit down at our computer, you should know what you want to
accomplish that day and have some idea how.
6. Continuous Education
A corporate
soccer team member once asked me, as we were lacing up our cleats, "what's
the secret to C programming?" If there was such a secret, I'd be hawking
it on late night TV along with ab machines and how to get rich in real estate.
Sorry, there's no shortcut - you have to learn and practice and make some
mistakes. And you don't necessarily have to rely on corporate training or going
back to school - there are plenty of (inter)national and local professional
groups, books, and of course, the Internet.
It's called
"computer science" for a reason. It's easy (maybe too easy) for
anyone to to start programming, without a formal computer science education. In
particular, those from other engineering and science disciplines can pick up
programming quickly and make a good living. But to effectively tackle
non-trivial tasks, you need to know the inherent capabilities and limitations
of software and recognize prior work, so you don't waste time reinventing the
wheel, badly. You don't have to know everything under the sun, but you should
have at least a cursory familiarity with many areas and be prepared to do some
additional research as necessary.
7. R-E-S-P-E-C-T
One requirement
for being an effective software engineer is to be taken seriously. You need to
have the respect of your peers and managers, at least for your technical
capabilities, to have control over your own work and influence over others.
Engineers
sometimes communicate more to show off their own knowledge rather than to
inform (although, if you can do both, kudos to you). This is often inflicted in
employment interviews, under the guise of "finding out how you think"
the candidate is asked inane puzzle questions. This can backfire, though, if
the candidate has any self-respect.
