Intern Adjustments: You Mean I Can't Start From Scratch?

As a junior developer fresh out of code school, there was one thing that I didn’t get too much exposure to before I began my internship – working on a project that I didn’t create. There was a lot that was covered in the short 6 months of my Epicodus program, but this was one topic that intrigued me that I didn’t learn much about prior to my internship.

I quickly learned that updating an older project comes with many different challenges. Think of it this way: Rather than building the house you want to live in, you just bought an existing house. It has some leaky pipes, a wall you just have to remove, and hidden rooms you didn’t even know existed. You will now be working on that old house. This story is about understanding the house before you can even start giving it that fresh update.

Now before we even get started diving into the house (our code), let’s take one step back. I had just assumed that getting to work on a project was the easy part. I could picture it in my mind, sitting at my desk and hacking away at a project to fix a bug, run a test, etc. This is where I had my first issue.

You know how you had “the talk” about how README’s are actually important and that you should always write a good README? Think of a README like a blueprint to the house that you just bought. You’re staring at it, but for some reason, the blueprint is one square, with a triangle placed atop of it, and nothing else.

That’s right, there are just 6 white lines on a blue piece of paper. This isn’t very helpful when you’re trying to decide if taking that wall out means taking down the rest of your house with it!

If you take anything away from this post, it should be to always make sure to write a good README. It’ll not only save you from having a future developer frustrated with you (because your commits are no secret, and they will find you), but will also save you a lot of trouble when you find yourself going back to work on a project. Specifically, that project you haven’t touched in a month and you don’t quite remember how it works and your new freshly-purchased Mac doesn’t have everything set up the way you like (or need) it.

After some setbacks, you’ve got the tools you need set up and you can finally write some code! Or, maybe not. You find yourself doing all of the things you were taught: open your terminal, clone your repo, open your code editor and then…it hits you. You open this app and you have no idea where to even begin.

Do you try and run it? That seems like a logical place to start right? You go to your terminal and you try and run the app, rails s. You sit in anticipation as you wait for your terminal to boot and confirm your app is running on localhost:3000, but to your disappointment, you find yourself stuck yet again.

Your app is not running on localhost:3000. Your app isn’t running at all. You sit, you ponder, you try and figure out what you did wrong. I bet you even try typing rails s again just in case you didn’t do it right the first time. You get the same thing. You act surprised like it was the first time you have seen this error, even though you just saw it only moments ago.

Now you are probably in that phase of, “What am I doing here?” You’re probably thinking there is absolutely no way you are going to be able to run this app, let alone work on it. Now is when you go and look at your terminal and start to figure out what all of these issues are. Little by little you make some tweaks and changes to your development environment and then you try running rails s one more time and…you get it!

The app is finally running and you’re on your way, right?! You then remember you’re a trained responsible developer who has been taught Test Driven Development (TDD) and you will never stray from the core of your teachings. You then try to run your test suite, ‘rspec spec` and you get…failure. And by failure I don’t mean your tests fail, I mean that your test suite can’t even run.

You’re once again back to questioning your skills as a developer. You again run rspec spec because computers aren’t perfect and maybe this was just a mistake and then again…failure. A rush of blood comes over your head and you just want to throw your computer across the room. But then you remember...

You got the app to run. You did. Sure, you did have some help from your colleagues (and trust me, you’ll be going back to them with question after question) but you got it to work! You find yourself more and more determined and after some time, a lot of Google searches and error messages, you FINALLY get the test suite to run, all tests passing.

Some of you reading this might think that this is not that big of an accomplishment. You may be thinking “So what, you can run tests and the app? You haven’t even done any work.” But I would guess that many of my fellow junior developers have experienced this sense of accomplishment recently.

In reality, the process of getting an application running on your local environment takes some work and can be difficult and daunting. Coming from a boot camp, I never got the opportunity or experience to work on a project that wasn’t started by me. Next time you find yourself in a similar situation, doubting if you’re cut out for development or engineering, just remember – setting up environments is hard!

Try to take things one error message at a time and eventually you’ll get there.