in Learning Tips

What I learned from shipping my first Ruby gem

This last Saturday was a milestone of sorts for me.  Together with my Flatiron School classmate Joe O’Conor, we shipped the first release of a web app, in the form of a Ruby gem.  For me, this was the first time I’ve released a piece of software since starting my code learning journey earlier this year.

Simple Forecast on RubyGems.org

A Ruby gem is basically a packaged-up piece of functionality that can be used by others who build software using the Ruby programming language.  It can also be used as a stand-alone command line tool (for those who have Ruby installed on their machines) which is how we released Simple Forecast.

Why build a weather forecast gem?

Aside from the educational value of building your own software, you might wonder why we decided to build a weather forecast app. The idea for this app came from my frustration with data-filled weather forecasts that look like this:

Data Filled Weather Forecast page
(One thing I always find funny is the practice of presenting a degree value, like “53.1” in this case, and then stating that this degree values feels like some other degree value. What, pray tell, does that other degree value feel like?)

What’s the problem here?  In my view, the issue is the strong focus on data and numbers.  Unless you’re some meteorologist in a white lab coat, I’m guessing 90% of this info is completely irrelevant to you.

Personally, the only thing I’m interested in knowing is the following: What is the weather forecast relative to the current weather?  Colder?  Warmer?  Rainer?  Muggier?

In other words, I would like a forecast that is free of numbers and nerdy data.  So I decided to design and build just such a data-free weather forecast app.  Now, you might say, there are already other apps out there which provide a simple data-free weather forecast, which brings me to my first lesson learned about building your own software.

Don’t let the fact that someone else already has built something similar stop you from building your own

One of the most common responses I hear when describing an idea I have for a piece of software is:

“Oh, there are already several apps out there that do that.”

This seems to imply that there is no point in creating a piece of software if someone else already has created something with similar functionality.

First, if you are creating software with the purpose of learning to code, it doesn’t matter if there already are a gazillion versions of that software out there.

But more importantly, statements like this, in my view, exhibit of lack of understanding of software products in general.

Software is inextricably intertwined with the people who create it. No matter what someone else created, it will never be identical to what you will create, in the same way that two novelists can both sit down to write a book on the identical topic and are guaranteed to end up with significantly different works.

Like writing, no two teams of developers are going to ship the same product. And even the identical team of developers would never ship the same software product over time.

So, the fact that someone else already has built something similar to what you’re thinking of doing should not stop you from pursuing your own vision.  And speaking of vision, that is often a great place to start your software-making journey.

Start by sketching a grand vision…

Here’s a mockup I created (using one of my favorite mockup tools, Balsamiq of how I envision some future version of Simple Forecast to look like.
Vision of what an iPhone version of the app might look like
Instead of presenting the weather forecast using a bunch of numbers, which would force me to think about numbers and translate in my mind how they relate to the weather, I’d instead get a forecast relative to something I  will know, what the weather was like yesterday, and in plain English without any annoying numbers.

….and then think of the smallest possible steps you can take toward your destination

So that’s  a possible product vision.  But while it’s important to have a vision of how you’d imagine your tool to maybe look like some day, it’s also just as important to remember that your vision is just something imaginary off on a distant horizon.

Keep your vision in mind, then try to think of the smallest possible steps you can take now to bring you closer to your destination.  To achieve that, you’ll be starting think about specific features and task and so forth, and it’s probably a good idea to start to get organized.

No matter how (seemingly) small, treat your development work like a real project

One thing I’ve learned from learning to code is that even the most seemingly simple project is bound to have a lot of moving parts. (I wrote a bit about this before.)  Just sketching out an idea and starting to code might work for some people, but at least for me, I find that there are just too many moving parts.

No matter how small the project (and the reality is that projects often only seem small at first), for me it’s incredibly helpful to start listing out all the features and tasks that I will be needed to reach that vision destination.  A great tool for doing this, especially if you’re collaborating with others, is Trello.

When starting to add tasks and features, don’t worry so much about if you’ve get every feature or task you can think of.  Whatever is missing will emerge as you start working on some part of the software.  What’s most important is to list out everything you can think of, and then decide which of those tasks would be easiest to start working on, and which you think is likely to help you make actual progress.

As an example, here’s a version of the Trello board we’re using for building this app.

Our Trello board we used for building the Simple Forecast gem

Even if you’re working on an app by yourself, you should still consider using something like this.  But if you can, you should definitely definitely try pairing with someone else on your project.

Pair, Pair, Pair!

Two people pairing

1 + 1 developers = much more than two

Pair Programming (or just Pairing for short) is basically the practice of two developers working on the same code or feature at the same time.

I remember having heard about pairing and thought it seemed both interesting and a bit weird.  But it wasn’t until I actually started pair programming that I really understood what pairing means, and how powerful it can be.  It’s just is one of those things that you have to experience in order to understand it.

For this project, as I mentioned earlier, I’ve been pairing with Joe, a fellow classmate at the Flatiron School.  Joe and I started pairing on the app this last Saturday morning.  Before we started pairing, I had done some initial work and research, which gave us a bit of a head start.

About three hours later, we had shipped version 0.0.1 of the gem.

I can without a doubt say that, had we not paired on this app, there is just no way we would have shipped the first release as quickly as we did.

While it may seem that pairing is all about coding, the reality is that it is about human collaboration and exchange of ideas and knowledge.  These are some things to keep in mind when pairing.

Replace ego with lots of patience and humility

When two people are both focused on the same task, you somehow create a kind of virtual zone of shared focus, which can be incredibly intensive.  Being in this type of zone can be incredibly powerful, and with great power, as they say, comes great responsibility.  In this case, the responsibility is for you to be incredibly aware of your behavior and how you are responding and interacting with your pairing partner.

One of you might propose an idea for how to code a certain feature. How the other person responds is just as important as the feature idea itself.  It’s essential to not let your ego get in the way, such as taking criticism of an idea personally.  Just as important, it’s key to be patient and let the other person complete their thought before starting to critique it.  Similarly, it’s essential to be open to ways of working, including how your environment is set up and other details of how you code, that you may not be used to or even dislike. Last but not least, it’s key to go slow and not feel some kind of pressure that you have to sort of perform and type super-fast or whatever, when you’re driving.

There’s lots more when it comes to the human, emotional aspect of pairing, but this gives you an idea.

Change drivers regularly

When you’re pairing, you normally have one person who is the driver, while the other person is the navigator.  In other words, while one person has their hands on the keyboard and is doing the typing, the other person is saying what should be typed in.

Working in this way has a number of benefits.  First, the person who is typing will be continually debugging the ideas stated by the navigator as they type.  Conversely, the navigator, looking at the screen, will debug what they see the driver typing.  This can greatly reduce the number of bugs you have in your code and reduce pesky typos, which is what bugs often are.

A common, and very apt, metaphor for this relationship is a pair of rally race car drivers, who are both intensively engaged in the same task, and yet have distinctly different but overlapping roles.

Rally race car driver and navigator

However, in contrast to rally race car drivers, you want to be sure to regularly switch drivers.

If you know the way, give the other person the wheel

Usually, the person who has an idea for what should be coded is the navigator.  In other words, if I know that we should code feature X in a certain way, I will describe the code I want typed in to the other person.

One trap you might fall into is to let the person with the idea for what code to type to also be the driver.  This is a huge mistake.  Often, it can lead to them just silently typing code, which means you’re no longer pairing.

Instead, you should be sure to let the person who maybe has less knowledge about the given feature or implementation to drive.  Because they are physically engaged in entering code, they are more likely to learn, and also have the power to stop coding and ask the navigator if there is something they don’t understand.

Ship Early, Ship Often

Agile software methodologies have taught us the importance of shipping working software early and often.  One reason for this is that  you can’t fully understand what you’ve built until you’ve released it into the wild.

For our Simple Forecast app, we therefore decided to implement just one basic feature of the app and then release it.  Additionally, we decided to release this early version with only a Command Line Interface or CLI, which would allow for releasing it much more quickly than trying to do some kind of wen app, and therefore more quickly gain from all the learning and insights that having a released version of your product can offer.

This is basically that you can do with version 0.0.1 of our gem.  At a the command line, you type “forecast tomorrow”

Simple Forecast - forecast tomorrow command

Then, the app responds by connecting to a data source and pulling the forecast for tomorrow, after which it returns a simple forecast explained relative to today’s weather:

Simple Forecast: Colder than today

Maybe the most important lesson I learned from working on this project is the amazing sense of satisfaction you get from shipping working software.  Even thought it’s just something very basic at this point, it’s very exciting to be able to build on that and continue to take one tiny step after another toward your grand vision.