Forum: Ruby on Rails programming tips for a newbie

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
9f173c578c2ff435a41d448e25d62870?d=identicon&s=25 SB (Guest)
on 2006-04-23 11:48
(Received via mailing list)
I kind of feel guilty for posting something like this since it's kinda
off topic but as a newbie I wanted to share with you some tips from
Wil Shipley (of OMNI Group fame) geared towards the programmers
starting out since I found it really relevant.

Just to give you a taste:

* The Way of the Code Samurai *

Now, I don't actually know much about real samurai, but the basic
thing I've heard is they stand and stare at each other for hours, and
then suddenly BAM strike once and the other guy is down.

That's how you should code.

- Think first. Think some more. Think about the whole problem. Think
about a little part of the problem you're going to start with. Think
about the whole thing again, in relation to your idea on the starting

Don't write code until you know what you're doing. Now, you may not be
able to "know what you are doing" just from thinking, in which case
you should start a TEST project and write a bunch of ugly code to make
sure your ideas are correct.

Then, start again, in a new directory. We had seven or so different
test project directories during the making of Delicious Library -- one
for the video barcode reader, one for the store, one for amazon XML
parsing, one for talking to Bluetooth scanners, etc. We learned how to
do what we were going to do BEFORE we uglied up the main project with
a bunch of code.

Then we copied the good parts out of the test project, and left the
cruft. This let us observe rule #2...

- Write all your code "clean," the first time you write it. Make
classes for everything. Use enumerated types. Don't take shortcuts.
Don't have any part of the code where you say, "Oh, yah, I just
glossed over that for now." You are NOT going to go back and fix it.
Seriously, how often do you say to yourself, "I think I'll dive into
this messy code today and try to make it nice and pretty without
adding any functionality?" Nobody is going to pay you for that. In
fact, I got called on the carpet for cleaning code during a major
update to a piece of software at a previous job -- "What are you doing
spending time modifying code that already works? Just add your new
features and be done." Never mind that I couldn't understand the code,
or that clean code is stable, maintainable, extensible code.

The rest:
This topic is locked and can not be replied to.