Ruby, projects & messy code.
The beginning of my coding journey has been filled with equal amounts of doubt, excitement, elation, and at times, sheer panic. Becoming accustomed to the rollercoaster of emotions that is learning how to code (especially when learning certain concepts within a specific time frame), can be just as taxing as the actual coding itself. That said, let’s take a look at some of the lessons I’ve learned from my first project, a “simple” CLI application which allows users to review historical exhibitions.
Starting your journey writing out individual functions in a single file, using a language as friendly as Ruby, was a pleasant experience, at least for me it was. Seeing first hand how you’re able to build increasingly complex functions in order to perform increasingly complex tasks can be a real high. A desire for complex ideas and solutions, however, is what can lead you down a seemingly inescapable rabbit-hole.
Going from individual functions in a single file, to learning about classes, relationships, and even useful gems, one naturally begins to visualise more ambitious projects and complex ideas. However, complex ideas are usually accompanied by more complex problems, which require well-planned and well-executed solutions.
If it ain’t broke, don’t fix it, right? Wrong.
Remember that “high” I mentioned when getting things to work? Sometimes, this is the road it can lead you down. Although the above would be fairly simple for most coders to understand, one of the first things you learn as you begin your journey is that your code should ideally be readable to anyone, coder or not.
Becoming obsessed with getting your code to work, no matter the cost, has been a real personal battle. When putting in so many hours and so much effort into something, it is easy to say to yourself when you make a breakthrough: “Wow! It works! I did it!” , bask in your glory and move on to the next function or task. But that glory is short-sighted, and most certainly short-lived. This is when you need to control your emotions, re-evaluate what you think “works”, and begin to think about efficiency. What can I do to make this function more succinct? Are there other ways to do this? How is this going to affect my other functions and the overall flow of my project?
A simple example of how the above could’ve been cut down can be found right at the top, on the first line under *when “View my reviews”*. The iteration that follows is a simple and clear one, going through all instances of reviews in order to find the ones which belong to the current user. Fairly simple to read and understand. It could’ve been even simpler though:
my_reviews = Review.all.select{|review| review.user_id == @current_user.id }
should in fact be:
my_reviews = @current_user.reviews
This is just a simple example of how taking a step back and trying to look at your code on a level beyond just what “works” and what is “broken” can lead to a greater understanding of the tools you have at hand, as well as more readable and efficient code. The solution which appears to be the most complex isn’t always the most efficient, nor the easiest to work with or relay on to others.
An idiot with a plan, can beat a genius without a plan.
Including a cheesy Warren Buffet quote in my first blog was just too tempting of an opportunity to pass up.
Having a plan isn’t all there is to keeping your project concise though. Sticking to your plan can be just as challenging. Finding new ways to create something is great, and having the intuition to look for things that go beyond convention, as well as having the will to keep trying different alternatives until something works, can be real assets, but you shouldn’t do this at the cost of constantly repeating yourself in your code, or making your code “messy” or inefficient.
If you have another look at the above, you can see that this home_menu function calls upon numerous other functions in order for the user to proceed through the app. This “works” in a sense, but is it the most efficient way to do it? Could you explain why you’ve chosen this approach to both programmers and non-programmers alike? And was this approach chosen out of a desire for efficiency, or out of desperation? I’ll let you figure that one out…
Keep calm & carry on…
So, as I begin to approach a new project towards the end of this week, are there programming lessons to be learned? Absolutely. But it is just as important to remember to not get too high, and not get too low throughout this process. Believe in your ideas and your plan, be adaptable, but stick to the principles of programming, and don’t compromise on efficiency. As you can see below, my app did run in the end, and there were no breaks, but I still didn’t pass my review. Always remember that just because something “works”, it doesn’t mean that it can’t be improved, nor that it is up to a standard which you originally set yourself at the start of your journey. Having something that “works” isn’t necessarily as valuable as learning how to properly use the tools you have available, you can make just as much progress, even more in fact, building something which isn’t necessarily “completed”, but runs efficiently and is in line with the principles of programming.
So it is with these lessons that I approach this new project, and I’m excited to let you know how that goes in my next blog entry. Until next time!
