The Online Web Development Course Fallacy

2 min read
The Online Web Development Course Fallacy

I lack a formal education in programming. Outside of taking an introductory development course in college, I learned how to program by reading various books and developing side projects. When I began my journey there wasn't an abundance of interactive online courses, but now this material is the preferred method of learning and has accelerated the education of novice developers faster than ever. While this development is incredible to see, the downside to modern courses are that many create fallacies of teaching students that they can easily go from course projects to a hosted production version. Unfortunately this isn't the case and mistakes can easily be made in the transition from learning how to program to building your first public project. From exposed credentials to costly server invoices, the lack of education on devOps and secOps in the process of learning to program can negatively impact a novice developers wallet and psyche and I want to share three tips for these developers to help prevent issue before they arise.

The first thing to be aware of when deploying your project is that private keys and credentials could be present in your code repository on websites like Github or Gitlab. If you are uncertain of what keys and credentials might be accidentally exposed in your code, then play it safe and make your repo private. I made this mistake early in my career and was surprised by a massive AWS bill that generated a concerning amount of anxiety. What had happened was a bitcoin hacker had found my AWS keys with a simple Google search and used them to spin up servers to mine bitcoins. I was facing a bill of over $5,000 (Not a fun number as I was rent poor at the time) and was saved, thankfully, by AWS after they recognized the unusual activity and eliminated the bill no questions ask. Ever since I made this mistake years ago, I followed the second piece of advice.

Follow programming best practices by using environment variables. Environment variables are values set outside of the application, typically through an operating system. Using these types of variables are a best practice due to its separation of the value from the codebase and if followed correctly will prevent you from committing a file with a value that could appear in a public environment, like what happened to me. These values can be stored on local and remote environments with differing processes based on your operating system or cloud-based hosting service. Twilio has a great article that explains how you can set up environment variables.

Lastly, if you are using a customizable cloud service for your server hosting, then read the documentation and make sure you understand the settings you are selecting. I used AWS for some of my first projects and naively assumed that the bigger the storage unit, the better, without consideration of associated costs. Dumb I know, but there were so many options to choose from and the language did not make sense to me. This mistake led to another massive bill as I had unknowingly selected m4.16xlarge for my EC2 instance which ran at a whopping $3/hr. Convert that into a monthly bill and you are facing ~$2,300 out of pocket. Thankfully AWS came to the rescue again, excused my incompetence and forgave the bill.

Each of these problems could have been avoided if I took courses on devOps like I did when learning a programming language. No one wants to learn server languages after frying their brain trying to learn a programming language, but it is absolutely necessary to safely run code on the internet.

Sign up for my monthly newsletter to receive more content like this: