Comments on: The most important things I learned about Rails development from RailsConf and RailsDay http://metaatem.net/2006/06/28/the-most-important-things-i-learned-about-rails-development-from-railsconf-and-railsday its a mirror - get it? Erik Kastner's blog. Thu, 28 Aug 2008 01:59:29 +0000 http://wordpress.org/?v=2.6 By: Phil Hagelberg http://metaatem.net/2006/06/28/the-most-important-things-i-learned-about-rails-development-from-railsconf-and-railsday#comment-1694 Phil Hagelberg Fri, 30 Jun 2006 21:38:09 +0000 http://metaatem.net/2006/06/28/the-most-important-things-i-learned-about-rails-development-from-railsconf-and-railsday#comment-1694 To learn more about the obsession with beauty in code, I would recommend reading Steven Levy's book _Hackers_. It's not a technical book at all, but it describes in great detail the hacker's mindset and the kind of amazing code squeezing that used to be necessary just to get things to work. We don't currently work under the same restraints as they did back then (if it doesn't fit in 24kb, we can't ship it!) but we can learn a lot from their obsession with "bumming" a few LOC here and there. You should be proud of your code when it's as short and it can be and still straightforward. It's worth going over your code after you've gotten it working just to make sure you can't tighten it up a bit; remove a local variable here, rename a method there. The other thing which I've recently come to appreciate is the ability to learn from pain. Just like it is with your body, problems in your code base should be painful. When something begins to cause pain, rather than focusing entirely on getting it to work, try to think about why it's painful and what you could do to make it easy and straightforward. Of course, this applies not only to application development but also things like editors and file management. Pain is your codebase's way of trying to tell you that something is wrong--don't "be a man" and ignore the pain. To learn more about the obsession with beauty in code, I would recommend reading Steven Levy’s book _Hackers_. It’s not a technical book at all, but it describes in great detail the hacker’s mindset and the kind of amazing code squeezing that used to be necessary just to get things to work. We don’t currently work under the same restraints as they did back then (if it doesn’t fit in 24kb, we can’t ship it!) but we can learn a lot from their obsession with “bumming” a few LOC here and there.

You should be proud of your code when it’s as short and it can be and still straightforward. It’s worth going over your code after you’ve gotten it working just to make sure you can’t tighten it up a bit; remove a local variable here, rename a method there.

The other thing which I’ve recently come to appreciate is the ability to learn from pain. Just like it is with your body, problems in your code base should be painful. When something begins to cause pain, rather than focusing entirely on getting it to work, try to think about why it’s painful and what you could do to make it easy and straightforward. Of course, this applies not only to application development but also things like editors and file management. Pain is your codebase’s way of trying to tell you that something is wrong–don’t “be a man” and ignore the pain.

]]>