Sometimes the wrong way isn’t so wrong after all?
I do not write software professionally. I’ve been doing some solo work on projects that are of personal interest to me, but along the way I’ve learned valuable skills that will hopefully serve me well, should any future career opportunities require me to demonstrate my proficiency in one or more languages. I am by no means an authority on anything programming-related in the real world, as I do not have any experience working in teams or developing solutions for clients other than myself. However, all of us started from scratch at one point! So hopefully even experienced developers will agree with what I’m about to say.
I believe the evolution in ones habits and abilities as a programmer is comparable to the journey of an adolescent through their crucial preteen and teenage years. And like any good coming-of-age story, we have our teenage protagonist, Ruby (yes, this is a play on that Ruby, but has nothing to do with the language at all).
Ruby’s Programming Journey
Ruby’s parents were once kids themselves, and made plenty of silly and sometimes regrettable decisions back then. But through the experiences they’ve had and wisdom they’ve gained during their years on Earth, they know they would do things differently were they given the chance to relive their childhoods. They do their best to convince Ruby to walk the straight path, and not to place popularity above everything else. “I know high schoolers can be judgmental. I was once your age too. But focus on your studies! Those kids will grow up to have regrets, while you reap the rewards of your good habits and commitment to higher learning”.
Will Ruby listen? Well, she’ll at least nod and say she gets it. But will her parents’ words affect her decision-making? Probably not! I doubt there are many parents telling their children to drink before they are of legal age or stay out beyond their curfew, and yet we have plenty of teens who do just that. Because teens are reckless! They think they are invincible! Yeah mannnn!
“I just want to live my life however I want!” says Ruby as she writes her first Java program on a whim, with neither a concrete plan for how to structure her project nor a solid understanding of the core principles of object-oriented design. And that’s what I’m getting at.
Rules are meant to be broken…then followed
Most books or articles on programming will teach you good habits:
- They’ll urge you to use descriptive names for your variables so they are easy to understand.
- They’ll urge you to plan out your vision before diving into code.
- They’ll urge you to use version control to keep track of changes, especially if you’re collaborating with others.
- They’ll encourage you to write modular code that can be tested in pieces (i.e. unit testing)
- If you’re building user interfaces, they’ll encourage you to separate the business logic from the views.
But Ruby just wants to get her code from concept to deployment as quickly as possible. Ruby is tired of reading books and wants to create! She wants to live on the edge! And sometimes, that’s a good thing.
I’ve found that the joy of learning programming on my own is that I can afford to make mistakes. I have no deadlines, and no clients are depending on me for a finished product. In pursuing my personal projects, I have made MANY mistakes. And when you’re in my position, making mistakes is okay. Because when I go back to a previous project I’ve worked on and realize how horrible some of my choices were, it means I’ve learned something. And it means I’ve gained the experience to prevent mistakes like that from happening again.
Below is how our friend Ruby might progress as a programmer. Each subsequent revision leads to further enlightenment:
- What a mess! Ruby comes back to a project from last year and realizes she has no idea what she was doing! The indentations are inconsistent, the variable names don’t mean anything, and there are no comments to help her understand what’s going on. So she takes the time to restructure her code and add helpful comments where needed (though there is some debate as to how often comments should be used, versus simply making human-readable code).
- Everything is in one file! Everything is formatted nicely and readable, but it’s a pain to update and maintain such a big file! Ruby put all her
classes in this file - one public class with a
mainmethod and then all the others, with no access modifiers specified. Ruby decides to wise up and put her classes in separate files, changing the access modifiers as needed.
- Recall that Ruby the person hasn’t been programming in Ruby the language - she’s using Java! But Ruby’s done a poor job taking advantage of key features of the object-oriented programming paradigm. Let’s say Ruby is working with a database of people of all different careers (e.g. police officers, firefighters, lawyers, etc.) and she used distinct classes to represent each type of employee. Every time she would add a new profession, she did a lot of copying and pasting. But Ruby now realizes that at the most basic level, they’re all just people. She could start by creating a
Employeeclass, which she can then extend to cover the specific states and behaviors of each profession. The choice of design is ultimately up to her, but she is starting to think about her project in an object-oriented manner!
- Ruby revisits another Java project, this time for Android. She realizes that she has included code to load information from
a database and populate a view directly inside the
onCreatemethod! She is not keeping her business logic (database querying) separate from her view controller (Activity)! She instead creates a new class to load information from the database, and this new class has no information about the UI. So this class is instantiated and the view updated via the Activity.
Once Ruby realized what a mess all her old code was, she realized her parents were right. If only she had listened to them! Well, the truth is, sometimes you don’t understand the importance of following good design principles until you write yourself into a corner. So don’t sweat it, Ruby! Those experiences were essential for you to evolve!
So read all the material you can. Your parents will tell you how to code properly. But chances are, as you apply what you’ve learned, you’ll be tempted to ditch the good habits they taught you and opt for the faster route. Want to name all your variables after letters of the alphabet with no explanations for what they represent? Want to throw a party the night before an exam because the parents are out of town? Go ahead! It’s part of your evolution.
…But really, you should probably study for that exam.