Taylor's Blog

Atypical ramblings

Summer’s End Update

I am back into the swing of things with school next week. This semester I will be taking CS261: Data Structures. Our teacher was kind enough to release the first week content early and I have been doing my best to go through it all before class starts for real next Wednesday. I had a little trouble wrapping my head around the basics of algorithm analysis in the beginning, but the more I study and review, the easier it comes. I am feeling a bit more confident about the class than I was two weeks ago.

I have also taken a break from my Spring studies as well. I had been doing the Udemy course for over a month at this point and was getting a bit burnt out. There’s really a lot to learn and the course is a bit slower paced – which can be both a blessing and a curse. I was really getting exhausted with not having any real solid apps built with the amount of time I had put into it.

With that in mind, I have decided to go back and revisit my roots with Node.js. I realized that my ultimate goal was to get some apps built to showcase my skills as a developer. With Node, I feel that I can get something up with a lot less work than with Spring. I also had a lot of fun working with Node in my Web Development class. I made my final decision when I came across this Reddit thread that was filled with comments that really resonated with me:

I use spring on the job everyday, but in my side projects I always use node/express. Besides the fun factor, restarting a node server is painless, and your code base should be significantly smaller.

Node.js is more cutting edge and will have less development time. For me, it’s just a hell of a lot more fun.

The one thing I noticed in that thread was how often people equate Node.js with fun. That’s really important to me. Creating a personal app should be something I enjoy doing, otherwise I will be less likely to complete it.

After I had made my decision to go back to Node, I needed a plan. That’s when my friend Tom came to me with a problem. Tom is a big video game collector. He has tons of classic video games and he often goes out shopping to buy more. His problem was that when he’s out, he doesn’t remember what games he has, so he’s often buying a duplicate of a game he already owns. He needs an app that he can use to store and review his video game collection with. I liked this project idea because I could easily see what components I would need to wire together:

  • The app needs to connect to a database to store info about what games he has or doesn’t have. I can focus on making a simple CRUD app and doing it in a RESTful way.
  • The app needs to have a login screen for different users – something I have never created before but would be valuable to learn how to do.
  • The app should look good. In the past, all my web apps have been just straight HTML and CSS. I decided I should learn a design toolkit and naturally chose the most popular one: Bootstrap.
  • The app should be able to connect to an existing API to look up information about the games in your collection. Luckily one already exists: The Internet Game Database.
  • At some point, we decided it would be really awesome if he had a phone app with a barcode scanner that would allow him to just scan his games and automatically add them to the database. Awesomely enough, Google has a Barcode API for Android that does just that.

So with all of those things in consideration, I had a relatively good idea of what I needed to learn. After doing some scouting around, I found the holy grail of tutorials: The Web Developer Bootcamp by Colt Steele. It’s one of the most popular tutorials on Udemy and it is awesome. I am already over halfway through it and I have learned a ton. There was a lot of stuff in their I had already learned but served as a good review anyway. The only comment I have about the course is that it uses Bootstrap 3. I didn’t want to be left out so I also picked up another awesome course: Bootstrap 4 from Scratch with 5 Projects by Brad Traversy.

Together, I feel these two course will give me almost all I need to create this app. So far I’ve been able to balance my coursework with my self-study, and hopefully I will be able to keep it up once school starts for real next week.

Lastly, I read a humorous article recently titled How it Feels to Learn JavaScript in 2016. It’s really funny, but one of the greatest takeaways I had from it was this comment from Addy Osmani, Senior Staff Engineer at Google. It’s a long one, but it really is just that good and something I think will to revisit in the future when I get frustrated by all the materials out there:

Totally get your frustration 🙂

I encourage folks to adopt this approach to keeping up with the JavaScript ecosystem: first do it, then do it right, then do it better.

First do it: Take a breath and acknowledge that you’re totally new to a space. It’s okay not to use everything. In fact, it’s better if you don’t. Get a simple prototype built that does the trick. Nothing wrong with straight-up using HTML/CSS/JS.

We don’t acknowledge enough that it takes time, experimentation and skill to master the fundamentals of any new topic. Beginners shouldn’t feel like they’re failing if they’re not using the library-du-jour or reactive-pattern of the week. It took me weeks to get Babel and React right. Longer to get Isomorphic JS, WebPack and all of the other libraries around it right. Start simple and build on that base.

Then do it right: Iterate. Improve on what you’ve got. See a problem that you keep having to solve? Maybe layer in a small library/module to help with it. There is zero reason to be worrying about rewriting your project in another language or framework nor adopting any more tooling unless it helps you move the needle forward on your project. Everything you add to your project should really be offering value. If it’s complicating things or making it harder for you or your team to get a job done, get rid of it.

Then do it better: master your craft. Once you’re comfortable navigating the waters of the tools and libraries you know for sure add value to your workflow, you’ll find that including them as a default “just make sense”. I’m heavily using 9–10 different tools in my project these days but I’ve learned enough about how to avoid their rough edges that they save me time. I would never suggest a beginner use most of the things in this post right off the bat. It’s a recipe for pain. Instead, get the basics right. Slowly become familiar with tools that add value and then use what helps you get and stay effective.

It’s also worth noting: everyone — even the people writing the tools and libraries mentioned in this post — go through the same feelings of fatigue and frustration learning, debugging and staying up to date with modern JavaScript. I’d encourage folks to remember we’re all in the same boat and our tools are here to help us. If they’re not doing that, we should get them out of the way 🙂

Updated: September 14, 2017 — 4:45 pm

Leave a Reply

Your email address will not be published. Required fields are marked *

Taylor's Blog © 2015