Words and Code

One writer’s journey from words to code.

So You Wanna Ship Some Software, Eh?

flatiron, non-technical

Disheveled hair. Bags under your eyes. Hermit-like tendencies. Suffice it to say, project mode can do a lot of things to a person. It’s the first time you’re on your own, and the feeling of “sink or swim” will, inevitably, hit you in the face at some point or another.

But, project mode also teaches you a lot about what it means to focus and ship software. And it doesn’t really matter that you’ve only been coding for 9 weeks and that your application has only four models and that you’re missing a ton of <div> tags. Why? Because the mistakes you make in your first application are ones that you’ll never make again. So, inspired by Blake’s post on lessons learned from building a web application, here are a few things I learned in the process of shipping my first piece of software:

1. Build something you actually care about

This seems obvious, but it’s worth repeating: don’t choose a project or problem that you think other people would find interesting – choose something that you genuinely find interesting. If you aren’t invested in the question that you’re trying to answer, it’s going to be evident in the product and demo. On the other hand, if you really care about what you’re building, your passion will not only come through in your product and presentation, but will filter down and get other people excited about what you’re building. It’s also important to remember that you, more than anyone else, are going to have to look at your data and code; you might as well pick something you won’t mind looking at for hours at a time, days on end.

2. Ignore the OCD impulses, leave styling for later

Possibly the biggest mistake we made while building our app was trying to make it look better before it was really done. We tried to implement some styling not only before we had picked a theme, but worse: before we actually knew what information we’d ultimately end up displaying to our users. All in all, we probably wasted 6-10 hours collectively, all in a futile attempt to make a broken application look prettier. When the time finally came to actually style our application, a lot of time went in trying to reformulate our CSS to make it work with the theme that we chose. So, no matter how much it gnaws at you, leave the styling, design, and UX stuff until your application is fully-functional and, most importantly, finished.

3. Set small goals & short time limits

One of the things that our group did quite well was building out one feature at a time and adding functionality to our application bit by bit. We did a good job of writing out and prioritizing the different kinds of functionality and types of features we could tackle in a given day. But it was much tougher to learn how much time to spend on actually building a feature out. A few days into project mode, we started setting time limits for ourselves, both individually and as a team. One person could only spend so much time working on a problem before opening it up to the group, and as a group, we could only debug a problem for so long before outsourcing to a TA or classmate. This minimized the number of hours we spent staring our screens without knowing which direction to go in next. With small, progressive goals to work towards and short spurts of time to complete them in, we were as a whole, far more productive.

4. Do what you don’t know

I have this fear of routes. Correction: I had a fear of routes. How did I stop being scared of routing and that silly little routes.rb file? I forced myself to map out the routes with my group and take the lead in actually programming them out in our application.

While I coded, my project partner Joe (who’s a super skilled router) helped me debug our routes, and made sure to explain why we were routing certain things in a specific way. And when we got to the CSS and styling, he took over the wheel while I helped him navigate the grid column framework in Bootstrap. This ended up being a super symbiotic relationship, because we both worked on the exact topics we knew that we were weak in, and both became better programmers in the process.

5. Version control: ‘Nuff said.

If you’re rusty on merging branches, making a commit, or merging conflicts, use project mode as an opportunity to conquer your git fears and learn as much as you can. Version control is awesome. It will probably (read: definitely) save you at some point in your project.

tl;dr?

  • Build first, design later.
  • Write code that you care about.
  • Practice what you don’t already know.
  • For the love of God, commit yo shit!

git commit comic