Public Learning

project-centric learning for becoming a software engineer

An introduction

My motivation

There is no question about the quality of Launch School’s Capstone Program: twice a year, the best students who have finished the already impressive Core Curriculum are able to join a Capstone cohort and learn intensely about advanced programming topics as well as building a project that can open doors even at the most prestigious tech companies.

But Capstone is not for everyone. Both financial, time-related and personal reasons might prevent a student from even considering the Capstone program. This has also been the case for me. While I would have loved to participate and continue with Launch School’s quality education, my geographical location, financial background and certain time constraints simply wouldn’t allow it.

I still see the value in having a final chapter of my learning journey to try and fill as much of the gap as I can between a Core alumnus and a Capstone graduate. So I decided to embark on a self-led, self-motivated three-month journey, where I will not try to replicate the Capstone experience in detail, but instead tailor it to my needs and to the kind of job I want to get afterwards. Because that’s the ultimate goal: to get a job that is more than just a badly paid, uninteresting entry-level gig.

Starting on January, 1st 2020, I will quit my job to be able to do what I call a “Mini Capstone”, my own version of a Capstone program. I will have a strict learning schedule as well as about 6 to 8 weeks of time to build a project that can impress a possible employer. If all goes well, I’m going to apply for a software engineering job in April 2020.

My current interests are very much in the backend and web infrastructure space. Doing the frontend portion of Launch School’s Core Curriculum, I quickly realized that frontend development doesn’t give me much joy. What I’m curious about are the systems behind the shiny user-facing website: what does a good API look like? How do modern distributed systems work? What are the challenges in serving cached content? Why is containerization such a big deal nowadays?

Why write about it?

There are a few reasons why I want to publicly blog about my experiences during that time. First, I want to hold myself accountable. Not being part of a larger cohort of students and without mentors and teachers, I need to rely on intrinsic motivation alone. Having one small public presence where I announce what I’m going to work on and how successful I’ve been with it, adds a controlling instance. And while there might not be many readers of this blog, I wouldn’t want to suffer the humiliation of a failed attempt.

I also think that there are a number of students at Launch School who will find themselves in my shoes. Capstone might not be an option for them, but they still want to go beyond what the Core Curriculum teaches in order to increase their chances of finding a better job. If my attempt at it is a success, they could model their approach after it. If it fails, it will at least be an example of how not to do it.

Finally, writing about all of this on a fixed schedule will help me with my written communication skills. I haven’t found much time for extensive blogging over the last two years of Launch School, so in order to improve on that, I want to write some technical articles about topics that I find interesting during my studies.

An outline for my approach

My preliminary schedule for that endeavour currently looks like this:

  • (starting now until mid-January) Fill some JavaScript gaps (modern ES6 features, asynchronous best practices), then learn about Node.js and Express.js as my backend language and framework of choice. Afterwards, read Artur Ejsmont’s Web Scalability for Startup Engineers and at least skim Martin Kleppmann’s Designing Data-Intensive Applications and Ilya Grogorik’s High Performance Browser Networking. This should give me a solid understanding of the problem space I’m going to deal with as well as enough knowledge to be able to write a backend system without tripping over syntax or basic features.
  • (mid-January until mid-to-end-February) Learning React as one of the ubiquitous frontend frameworks right now and building a practice full-stack project. This is going to be an opportunity to learn about real world requirements like authentification, security/validation, logging as well as deployment and testing needs. This is also going to serve as an exploratory phase where I try to identify specific topics in the backend/infrastructure sphere that I find interesting and worth digging deeper into for my real project. Which leads us to the final step:
  • (starting from mid-February/March until April) Conceptualize and build a backend/infrastructure-centric project, as well as creating a case study. I’m also going to create a presentation for potential meetups or a public recording.

The finer details might change until I actually start in January, but I don’t expect big deviations from that outline. I will write in detail about each step as I start, along with my reading/video/course material and any other external resources.