If you have studied computer science, you have probably encountered UML diagrams and the waterfall model. Like with a lot of things from the college days, I've never had any use of that in the real world. But since I've studied it, I assume some people still use it. To be honest, I don't have much exposure to the "Enterprise" world, where I think UML diagrams are much more popular.
As I use Ruby, I am more under the Agile way's influence, where planning doesn't have much weight. Delivering frequently and getting feedback early has much higher importance here. This means that Ruby developers are much more eager to "get things done" and get into the nitty-gritty details as soon as possible. "Done is better than perfect" is a mantra that is followed here. And how do you get it done if not by programming?
But, over time, I've realized that a small amount of planning is still better than just going straight to programming, at least for anything non-trivial. When programming, it's like I have blinders on. I see only straight. I don't have a lot of time to think about my approach and question things on a higher level. It's like sprinting straight ahead.
But, sprinting in one direction for too long and then realizing that you have not hit the mark means wasting a lot of resources. Instead, you can think about where you want to go before sprinting and save resources. Writing allows you to do that.
Writing things you plan to do before doing any programming illuminates the problems in your approach before you implement it. You act as if you have already done the hard work of implementing the requirements and then ask yourself whether there are some problems that can be avoided.
Can what you're planning be implemented more elegantly? Since no code is the best code, is what you are trying to implement even necessary? Are you going to have problems going down this path, and what are the alternatives? These are the questions you start asking yourself by writing things down beforehand.
The beauty of it is that you can go into as much detail as you want. Heck, no one will stop you from writing pseudocode if you want. The beauty of Ruby is that it will look very similar to what you'll ship to production.
Doing so makes you avoid unnecessary work. It makes your plan visible, which also makes wrong assumptions visible. It saves resources, which can now be invested elsewhere.
Writing a plan before doing anything non-trivial is one of the practices I wish I had picked up earlier — another one being not blaming other people's code when debugging.