Public Learning

project-centric learning for becoming a software engineer

Week 2: A Recap

Many Meetings

By talking to many people with similar experiences to mine - current and former Launch School students - I was hoping to fine-tune both the general structure of my approach as well as the exact topics I want to immerse myself in. I am very grateful for the opportunity to pick the brains of many bright people who were all more than willing to take time out of their (sometimes really busy) schedules to answer my questions.

One talk in particular stood out: on Thursday I talked to Chris Lee (Launch School founder and instructor) and he made me realize a few things about emulating Capstone I did not have in mind. First, he strongly emphasized the extraordinary circumstances that Launch School‘s Capstone program create, most importantly the strong mentorship by people with many years of industry experience as well as the power of having a tightly-knit group of like-minded folk to study with.

I already knew I was lacking those, but still thought I could compensate. What I never questioned was my intention of focusing on distributed systems. Watching the Capstone presentations for both RedPoint Notebooks and Mothership this week fueled my belief of building something in that space.
There were two problems with that: first, the vague idea of building something that scales means skipping an important step. Creating a distributed system at scale requires some constraints or bottlenecks that the scalability aspect is going to solve, but it can never be the general idea itself. And second, even if I had an idea that required something like heavy containerization or a sharded database, the amount of knowledge required to navigate that space is enormous. There would be a real possibility of me digging through books like Designing Data-Intensive Applications like a madman and still not “getting it” to the extent required to make meaningful decisions.

So I am going to take few steps back and refocus. I have scrapped my plans to quickly dive into Docker and such, instead I’ll do a series of explorations into a number of different topics in the hopes of finding something that sticks enough to be able to develop a project idea. Those exploratory topics will include:

  • React
  • In-Memory Data Stores like Redis or Memcached
  • Parallel Node.js with Worker Threads
  • WebSockets
  • Docker (to at least see how it is used)
  • Functions as a Service (AWS Lambda plus a quick look at the whole Cloud Computing space)
  • Service Workers
  • TypeScript
  • Event Streams (and message brokers)
  • Logging and its ecosystem/surrounding challenges

I have a few additional topics in mind, but I’ll see how quickly I progress. My goal is to spend about two full days on each of those topics (so roughly 15-20 hours) to get a few insights into how the particular tech works, where it is used and how it can fit into the overall picture. I have also started a list with possible project ideas that are not restricted to just distributed systems. Right now, it’s a continuous stream of ideas, no matter how crazy or far-fetched they may seem, and I’m hoping to get enough inspiration from at least one of them to derive my final project from it.

Flotsam and Jetsam

There was much that I could still salvage from my original planning (I was just getting started, after all) and it did not have an effect on my day-to-day learnings anyway. I just wasted a whole lot of hours making my mind up. Nevertheless, my studies continued.

The beginning of the week has seen me complete my first round of Node.js exploration with a finished prototype of a social network-type website called Shallow Content. I focused on user authentication and account management, implementing a session-based and database-backed auth system with the help of Passport.js. I was very thankful for Bulma, which made styling the project a suprisingly easy task. It’s no secret that HTML/CSS is not my strong suit, so having a CSS Framework to do the heavy lifting was nice.

Shallow Content UI

I quickly began to regret my choice of using MongoDB as the backend database when my feature set grew. I knew beforehand that using a document store for relational data was no wise choice (I just wanted to learn some MongoDB/Mongoose, to be honest). I wonder, though, why so many CRUD app tutorials make MongoDB seem like the best thing since the invention of fully automated espresso machines. Creating relationships between different MongoDB collections is awkward at best and it leaves it to the application to correctly identify and delete related data on deletion. SQL had the awesome ON DELETE CASCADE which propagated removal of rows through all foreign key references, with MongoDB I’d have to write hooks to check whether a reference might need to be deleted (but I guess MongoDB automatically wins because it is Web Scale). I will most likely use SQLite or PostgreSQL again for my next small project and see how it compares. I’ve heard words of warning about Sequelize’s bad documentation and confusing approach, but I’ll reserve my judgement until I actually use it. I may also just get by with using prepared statements.

A few hours last week were also spent on various backend-related things like writing some example code that uses JSON Web Tokens as a stateless alternative to session management. I also tried to get a deeper understanding of Node’s event loop. For client-side JavaScript, the event loop works pretty transparently, but Node.js provides lots of low-level I/O functionality (like accessing the file system or network sockets). I learned about libuv (link) and how this C library does most of the heavy lifting in regards to async I/O. Its event loop functionality is actually used by Node itself, and learning about how different types of callbacks are handled gave me a good idea of when some of those callbacks are actually invoked (and what the difference between setImmediate() and process.nextTick() is). This might actually be a good topic for my first long-form technical blog post.

I also started with React again and it feels like completing a full circle. More than three years ago, I set out to learn web development with a handful of tutorials and books and started - of course - by diving right into React. It confused me a lot as I was lacking any understanding of JavaScript and I was doomed to fail from the beginning. Coming back now, much of it makes sense immediately, which shows the value of Knowing The Fundamentals First™. Unfortunately, it’s a strange time to return, with version 16 of React introducing a whole new way of writing stateful components, now preferring a function-based syntax with so-called hooks for state management instead of the old class-based syntax. I will write and use both approaches to see for myself what they bring to the table, and I’m excited to continue with it this week.

Riddles In The Dark1

I have also come to a point where finding learning material has become a challenge and I was especially disappointed in quite a few of the courses on Frontendmasters. I know that the quality of such a course depends heavily on the teaching instructor, and so far both Kyle Simpson and Will Sentance have been on par with what I came to expect from the Launch School material itself. Simpson (author of the You don’t know JS series) exudes the kind of confidence you can expect from someone who has demonstrated deep knowledge of a language. His JS courses have been excellent and his explanations as precise as I wanted. Will Sentance has made it his motto to basically teach mental models. He radiates excitement and his JavaScript: The Hard Parts course fits the Mastery-based learning approach really well.
Other courses I have watched so far include API Design in Node.js from Scott Moss and very recently Complete Intro to React from Brian Holt, and both instructors did not use the precise language I’m craving. I’m no fan of flowery metaphors for describing concepts and handwaving away important details about their implementation. I’m sure many people find Frontendmasters very helpful, but some of their courses are just not to my taste.
So far I’m lucky to still only scratch the surface of various topics like React, so I manage to get by with the official documentation and API references, but I dread the day when I want to learn about something like, let’s say, WebSockets or Server-Sent Events and will have to scour Google for explanations about the practical implementation of those things. Wading through badly written (or even flat-out wrong) Medium posts surely is no fun.



Time spent this week: 56.5 hours 2

  1. If you were able to correctly identify all headings in this post as chapter titles from either The Lord of the Rings or The Hobbit, you win as many oliphaunts as you can carry. ↩︎

  2. Again, this is a rough estimate according to my notes. It neither includes a few Zoom calls this week and some (but not that much) reading in the evening hours, nor does it take into account Thursday night, where I kept staring into the dark for a few hours, wondering whether I should instead pursue a career as a burger flipper at McDonald’s. But I didn’t learn a lot from that anyway. ↩︎