Building any project on your own (especially as a junior) is a series of: “So I’m going to do this, and use this.” - Some Implementing - “Shit, actually that’s not going to work.” - Queue Googling, asking around - “Right, so I’m going do this instead and use this other thing.” REPEAT.

It’s exhausting and you’re often in information overload because everyone has an opinion about everything, and you don’t really know how to gauge which is the best option for you, given your skillset and the purpose of YOUR project.

Working on a new project is fairly equal parts programming, as it is reading documentation, sifting through opinion pieces and backtracking. Once you get used to that reality, you become more secure as a programmer and stop questioning your intelligence. The whole purpose of working on a new project is to learn things that are new to you and becoming better at your craft. Failing is part of that.

Do you know how many times you stumbled before you could walk? Likely a lot. But we learned how to walk, and we got used to stumbling over (maybe even better at it). Like with any talent, it takes time and repetition. Stick through it!

About two years ago is when I first started attempting to program. Back then, if whatever I was working on didn’t function correctly, I’d blame myself. I’d immediately think: “OMG, come on, it’s not that difficult. A lot of people know how to do this, why don’t you know?!” - Except, that’s an absurd expectation to have of myself and any junior developer. I didn’t know, because I’d never been exposed to it before. I didn’t know because I was just starting to learn. Same way, I didn’t know I was meant to stand on my two legs to get places instead of crawling around, which to Baby Luisa was probably a ton of fun.

This expectation kept me from progressing as a programmer, and led to me saying things like: “I just don’t understand this, and maybe it’s because I’m not meant to be a programmer. I should stick to what I’m already good at.” - Absolutely wrong.

Two years ago, I stopped programming because it was too overwhelming. There was a lot happening in my life then, and the voice in my head was more powerful than my will to keep going. Roughly a year ago, I decided to ignore that voice and embrace the unknown. I’ve stuck it through, and if you ever feel this way, know that it isn’t you and you aren’t alone in having this feeling. You can do anything you put your mind to, it’s about perseverance and (quite honestly) becoming better at reading your error messages and Googling for their potential solution.

Below is a summarized (not short, by any means) breakdown of what building my side project Did You Know? was like. I’m sharing this because I personally want to remember what I went through with this project, and also because I want to share the reality of what programming is like: basically, a ton of trial and error.

I initially planned:

  • Use JS on the frontend to pull in data from Twitter and display on the site.
  • Use GitHub Pages to host the project.
  • Use MAMP for local development.
  • Use no frameworks, no preprocessors.

I figured: I’ve done all the above before, in some combination. I’ve got this.

Once I got started:

  • Local Setup: Done.
  • Basic page layout (HTML): Done.
  • Basic CSS styling: Done.
  • JS: Fuck, Twitter requires authentication (OAuth, specifically) and apparently it can’t be done on the frontend, because of security concerns.

And so, the Loop Begins

New plan:

  • Use Node - And learn Node, at least enough to get me through the project.
  • Find a library to assist.
  • Use no frameworks, no preprocessors.
  • Use GitHub Pages to host the project.

I find a library…

  • Cool, this library looks good.
  • Yey. Things seem to be working.
  • Fuck. Library has a bug.
  • Fix bug locally.
  • Fuck. There’s another error.
  • Check the libraries issues list on GitHub: Don’t see anything about the error I’m getting. Maybe I’ve messed up somewhere?
  • Investigate.
  • Nope. It’s not me, or well, it’s highly unlikely it’s me… Literally not much of my own code at this point and what I’ve written so far has nothing to do with the issue.

And so, the Loop Begins Again

(but, this time I pause for a few days, because life gets ahead of me)

  • After a few days, I check the issues list for the library on GitHub again.
  • Hey! That’s my issue, right there! I get it when I do something slightly different, but it’s the same error and same line of code causing it.
  • I fix the issue and submit a pull request so it’s fixed for others.

Whilst I wait for feedback on the 2nd error I was getting, I try other things…

  • Look for another library.
  • Find another library.
  • Looks good, but not sure it does things the way I want.
  • Explore other options.
  • Decide: Aah fuck it, OAuth is working with the second library I found and I’m able to get a Tweet to console.log(); in terminal. Let’s use the library.

Queue Googling and watching videos to learn Node.js

I watch:

I get back to the project and..

  • Noo!!! Now that I’m trying to display the Tweet on the page (inserting through document.getElementById();) it throws an error.
  • Dang. Does this mean I’m going to have to forgo my ‘No frameworks’ idea? Do I need a framework?

Tip to Remember: Googling the error you get, is key. I check for: “Node.js ReferenceError: document is not defined”, which leads me to this lovely Stackoverflow response. It explains:

Node.js is a backend language - As such, it doesn’t have connections with the browser, so you can’t target the window / DOM like you can with JS. This is why tools like Browserify exist. Browserify gives you the ability to manage your project dependencies and Node.js code, whilst also allowing you to write to the browser / DOM using vanilla JS or other libraries / frameworks.

Learning this, I:

  • Set up Browserify and Watchify
  • Now I start getting a Error: Fetch API cannot load error when submitting my API request to Twitter, when attempting to display the Tweet on the page.
  • GAAAAH. Come on, not again.

Back to Google I go, where I learn the library I’m using and Browserify are colliding.

  • I assume I can remove the library altogether and include the Node.js https module to submit my API request.
  • Nah. Instead EVERYTHING BREAKES! WHAT’D I DO??!
  • I reset my Twitter credentials - thinking maybe the error means my Bearer token (a “token_type” assigned by Twitter, which gives you access to their API through OAuth) might’ve been deleted / affected because my request returned OAuth errors.

I now end up down a rabbit hole..

  • Eventually I find a Gist with some code that works and guess what? The fucking Bearer token wasn’t reset, because that’s not how it works! Eh fuck.. now to try and get Browserify to work again.
  • Um so right, now the request is working in my terminal again, but I’m getting a CORS (Cross-Origin HTTP request) error when trying to display the Tweet on my site. This makes sense. The error describes what I’m attempting to do by sending an API request - AKA attempting to display information on my site, that is located on a different site. But that error means my permissions aren’t working. UGH. Just give me the information. PLEASE.

I Google and a potential solution comes up: set up a reverse proxy server. Sure. Not a clue what that is…

And so, the Loop Begins Again

New plan:

  • Use Node.js (backend)
  • Use Express.js (server framework for Node.js)
  • Use TwitterJSClient (Twitter library)
  • Use GitHub Pages to host the project

I get past the CORS issue, but start encountering others. At this point I scratch most of the project, and decide to embrace what Google has been telling me: Use Node.js with Angular.js, here are a bunch of blog posts woman!

  • Read blog posts
  • Use bits of code I’d already created (thank you Git and GitHub for versioning) and copy the Express code, example Twitter requests and Angular bits from different blog posts.
  • Run into an issue, but can’t figure out what’s going wrong. Spend too long looping (hours worth of “uh, maybe this. nah, maybe this..”). Need to get out of the loop, so ask a colleague about the error.
  • Turns out: It was an issue with my file path. For this project index.js works as the root (because I’ve set it to be), so any path to the ‘public’ folder leads from there! lightbulb moment
  • I get the app working!

Holy shit, it actually works!

  • Now, let’s get this baby on the Internets so it’s accessible to others.
  • Set up site on GitHub Pages, but that doesn’t work.
  • Google tells me GitHub Pages only host static sites, and since my site involves API requests, it’s “dynamic” (aka: not just local text files).

And so, the Loop Begins Again

  • Read a bunch of blog posts to set my site up on AWS using Docker.
  • Information overload.
  • Finally, this article: Running Docker on AWS from the ground up, by Yevgeniy Brikman saves me. Best post I found to help fill in the AWS gaps.

AND DONE!! PHEW

Final outcome:

  • HTML, CSS, Angular.js (frontend)
  • Node.js (backend)
  • Express.js (server framework for Node.js)
  • TwitterJSClient (Twitter library)
  • AWS + Docker (hosting, deployment)

So there you go - I got derailed at least 4 times, though the bumps I encountered were in the double digits. If I’d used a framework from the start, I would’ve saved a lot of time and headache, but I also wouldn’t know what’s happening under the hood. This is entirely a personal choice, and I’m happy not having used a framework until the end, at least for this project.

View the code for Did You Know? on GitHub

To sum things up: There’s much more to building a project than just the code you implement (including a lot of wanting to pull your hair out and thinking your computer is secretly scheming against you).

Don’t let not knowing something discourage you - Let it instead be an opportunity to learn something new, so you can learn the next new thing.