A Day in the Life of a Software Engineering Bootcamp Student
Let us revisit one of the most significant moments in computer history . . .
The year was 1983. Two young Fort Worth based engineers travelled to Las Vegas, where they planned to unveil their groundbreaking operating system at Comdex computer expo. There was a buzz in the air as the engineers set up their booth for the second day of Comdex. The only thing that exceeded the engineers’ hopes were the expectations of all the attendees. No one knew exactly what the engineers had created, only that it had the potential to be at the forefront of a computer revolution. A few hours later, the moment had arrived. Attendees packed-in along the aisle to get a glimpse of history. The engineers plugged in the computer, greeted the attendees, and with glowing and confident smiles, jointly pressed the return key. All of a sudden, the screen lit up, and the now famous words appeared . . .
A collective gasp was almost immediately drowned out by the mocking laughter of the attendees. One of the engineers put his head down in shame and closed his eyes. As he slowly opened them, he found himself not at Comdex but in a one-bedroom apartment in Williamsburg, Brooklyn.
After a momentary confusion, I put the pieces together: I was not an engineer at the dawn of the personal computer era but rather a software engineering student at Flatiron School and in the middle of a grueling debugging session. I had passed out while taking a quick break to watch an episode from one of my favorite shows: Halt and Catch Fire. Unfortunately, there was no hiding from this elusive NameError and even in my dreams, the bug found me. As I got back to work, I took a deep breath, let out a soft grunt, and thought “f**k this f**king error.” More on this later.
The Bootcamp
The Flatiron School Software Engineering bootcamp I am attending is 15 weeks long and divided into five three-week modules(or “mods”). The first two weeks of each mod are filled with lectures, discussions, group work, pair programming, and mini-projects. This leads to “Project Week” during which we discuss, plan, create, execute, debug, and present an application that will utilize everything we have learned up until that point and maybe a little more.
At the end of Mod 1, students are tasked with creating a CLI application. CLI stands for Command-Line Interface and was the precursor to the GUI, or Graphical User Interface, popularized by the Macintosh and Microsoft operating systems of the early 80s. Instead of windows, cursors, and colors, the CLI provides a simple text prompt to enter commands in order to interact with a computer. A CLI application is a great project for new coders as it allows them to focus on the foundation, database, and structure of a program rather than graphical bells and whistles. Those bells and whistles are certainly important, I just have not learned a thing about them yet.
The Project
On Tuesday of Mod 1 project week, we were assigned partners to tackle the CLI App and begin what, at the time, felt like an insurmountable task. I was paired with classmate Grant Yoshitsu, with whom I had yet to interact. Grant and I quickly found common ground in our love of eating and decided that the focus of the app should be a pantry management system(exciting, right?). The next step was to decide how components of our program should interact with each other. That is to say, how should a user interact with their pantry, how should a pantry interact with a pantry item, and how should a pantry item interact with a user.
We continued spitballing ideas and discussed how cool it would be if we could generate recipes based on a user’s pantry items. However, no one with easy access to the internet has trouble finding recipes. We wanted to make an app that would not just mimic a simple google search but rather one that would solve a problem. Eventually, we found that problem: food waste.
We decided to provide our users with recipes that would maximize items nearing expiration. An item that either needed to be consumed or thrown away, where the user had two options: USE IT or LOSE IT. Just like that, we had the name of our app. Grant and I drew a diagram to reflect this new concept. We would have users, pantry items, “use it or lose it” items, recipe searches, recipe results, cookbooks, ingredients, and shopping lists. Each of these would be a different class of objects in our program and they would all be interacting with each other in an expansive web of chaos.
Even though our program would exist within the confines of a CLI, we were determined to provide easily accessible and relevant data to our users. Dividing up our responsibilities, Grant would handle the easily accessible aspect, while I would work on getting the relevant data. These would be created through TTY Prompt and API respectively, two things we knew little to nothing about. I am not going to get into how we learned and executed our aspects of the program but suffice it to say, it involved hours of blank stares, confusion, slowly reading documentation, trial-and-error, reading documentation even slower, and finally success.
Fall or Fly
On Thursday morning, two days after our project was assigned, Grant and I were ready to bring our completed portions of the app together for testing. It was an amazing feeling. Not to be dramatic but it felt like I had jumped over a vast crevasse and just as I passed the halfway mark, certain I would imminently plummet to the ground, Grant caught me. We would either get our app working and fly or fail to do so and fall gloriously together.
Although the early debugging was flawless, at around 6pm, we hit a wall. Every time we ran our app from bin/run.rb, we would immediately be faced with the same error:
Grant and I spent hours combing through every line of code. We followed the usual debugging protocol, searched message boards, and considered rewriting everything in new files just to make sure we were not missing the one line, the one command, the one god damn letter, that was causing this error. Nearly every project file and folder was moved, adjusted, or edited but no matter what we did, the result was the same and we continued our fast descent into the crevasse.
At this point, I was convinced the error had something to do with the environment.rb file, the mechanics of which I only had a superficial understanding(“superficial” is being generous). I copied and pasted into environment.rb with reckless abandon and, before I knew it, the file had quadrupled in size. Eventually, I snapped out of it, took a deep breath and looked at the current state of our sad environment.rb which was now as bloated as it was impotent. It was over, time to throw in the towel. “Is it too late for Grant and I to write something from scratch?” I thought.
I decided to manually revert all of the project files and folders back to their state when we first encountered the HellError. Manually because, in addition to everything else, I did not trust my novice GitHub skills and was concerned I would accidentally obliterate the entire project. As I put the final pieces back in place, I saw it. It was right in front of us the entire time: require_relative ‘../config/environment.rb’ was not at the top of bin/run.rb. It had either been removed on accident or had never been added at all. I added the missing line and upon running bin/run.rb got a new error. However, this was an error about TTY syntax. It was a great sign that we were back to our regular scheduled debugging. Grant took over and shortly thereafter he slacked me.
Just like that, It was over. We ran the program a few dozen times with smiles glued to our faces. Use It Or Lose It, an idea that started as a few blocks and lines, had become a reality.
I cannot begin to describe what an incredible experience this was and I could not have asked for a better partner. Use It Or Lose It may seem insignificant when compared to contemporary software but I am so proud of what we accomplished during those few days. It was the first time that I felt like I made a real application and I was fortunate enough to have an amazing partner to do it with.
The completion of our first project week marks the beginning of what is sure to be an exponentially challenging bootcamp. I know there will be many more stressful nights and TV-induced fever dreams but as I enter Mod 2, I am ready and excited for things to come.
