My First Large Programming Project - Lessons Learned
Published: 2020-02-14 18:18:08

---
title: My First Large Programming Project - Lessons Learned
published: true
description: I had 3 weeks to be introduced to Ruby and create this project (utlizing many_through relationships, belongs_to, and database interaction using rails), here's some discoveries I made along the way
tags: 
---

I am writing this post now after completing the alpha of my very first project, Ruby Wizard, an interactive text-based game framed to lay foundation for a game introducing new programmers to Ruby. It was a humbling and gratifying experience trying to storyboard and plan a project with a deadline for the first time, but I wanted to take a moment to point out things I picked up along the way I learned during my first real project. 


1. --You can never plan too much--

    Seems straightforward but the more you can storyboard, whiteboard, brainstorm and draw out before you actually even touch a computer the easier you will find getting everything to connect in the end. It's easier to take an extra day to plan than an extra 2 days to debug! We started basic brainstorming on a combination of GoogleDocs for content and Draw.io to whiteboard our object interactions and map our software layout, and probably spent at least 2 days planning as much as we could before we typed a single word of code.

2. --Make small changes with each test, and isolate as much testing as you can--

    My first alters to code were vast and sweeping, adjusting multiple values and methods across several pages all at the same time. It shouldn't be hard to see why this was a terrible idea. I would often spend longer debugging the mess I created than I would have if I just tested along the way. My rule of thumb has become "Every time you make an edit that breaks your code, as soon as it should be fixed check it". If all you do is change one value or variable, save and test immediately. Run things early and often and it saved me a lot of trouble in the later stages of our project debug.

3. --Break problems down as small as possible--

    There were many aspects of making a game that were completely overwhelming, especially some of the stretch goals we still have in mind as we continue to tinker with this project in the future. Any task you have ahead will be exponentially easier if you break it into it's smallest compartments.

4. --Always check for gems--

    We were doing a game operating entirely through the console, so we already knew that graphical interface was going to be minimal...but we still wanted things to look good! Thankfully, other developers have had the same issue and were kind enough to openly source their solutions. We ended up utilizing TTY-prompt, TTY-box, and TTY-font as our primary display functions...which leads me to my next tip...
    
5. --Take the time to view the readme on any gem you use!--

    If you find a gem that looks like it may help you out, definitely take the time to go through the whole readme/documentation if possible. During out project we were using boxes to frame data pulled from a database with one method we found in the gem TTY-box. We found the gem for exactly this one purpose we had in mind, and, having accomplished that task, promptly forgot we had the TTY-box gem installed. Later we came across issues with our display output in a context that we spent hours working on ways to re-configure the text and data to make it more presentable, and finally after 30 minutes reading the TTY-box gem readme I found it had a function that did exactly what we just wasted an afternoon trying to work around. You already installed the gem and required it, might as well take advantage of that!  Be careful though, the more you utilize a gem the more you depend on someone else upkeeping their code.





My project is available to view on my github [here](https://github.com/Dane-Dawson/Ruby-Wizard), feel free to check it out and give some constructive feedback!