A love letter to Software Engineering

I’ve been making a career transition to software engineering for about a year and a half, starting first in a –gasp!– bootcamp and then eventually to Launch School. I’m at a good inflection point now to reflect on the journey so far, talk about the process, the challenges, the joys–and be grateful for everyone who has made this transition possible.

As you can imagine, the software engineering industry is always changing and highly competitive, but the software engineering educational space has become as competitive as the industry itself. From bootcamps to Udemy to freecodecamp and everything in between, there are hundreds or thousands of places and ways one can learn how to code–and many of them are free.

How to navigate and sort through all these options is itself a challenge, and of course there are many personal factors that make everyone’s path unique and different. This post will explain the decisions I made as appropriate to my own path. Your circumstances may require or nudge you towards another path that is more appropriate for you.

Background

Like many who enter the field, I’ve been coding from a very young age–and I’m well into my thirties. That means I’ve been writing code and using algorithms for over twenty years, starting from BASIC/Qbasic when I was twelve to Visual Basic and C in high school, and picking up HTML and JavaScript along the way since then.

I’ve built and hosted personal websites on Geocities and Angelfire as a teen in the late 90s, volunteered as the webmaster of a few student club associations during college, and have also professionally developed software solutions using VBA when I worked in local government.

I love writing code so much that when I was in law school, I taught myself Ruby and the Rails framework and built a fully functioning application over a summer, during the evenings after I would come home from my legal internship. I love the immediate and often explicit feedback you get when you run your code, and the process of gradually troubleshooting when it does not behave as you expected or wanted–because that allows me, us, to make rapid micro-leaps towards becoming better at our craft.

The computer is itself an excellent teacher in the sense that it gives us immediate and honest feedback every time we incrementally advance our work or try a new approach to a problem.

I also love the phenomenal community of software engineers, and the way people eagerly help each other solve problems and generally troubleshoot each other’s challenges. The ability to stand on the shoulders of giants by using open source code and libraries is such a remarkable aspect of the profession.

All this was a much welcomed change from the cut-throat world of law school.

I can’t think of any profession in which you get more valuable feedback than software engineering. The computer is itself an excellent teacher in the sense that it gives us immediate and honest feedback every time we incrementally advance our work or try a new approach to a problem. And it never gets mad, even if and when we fail repeatedly.

For someone who loves to learn, improve, and test out new ideas, this instantaneous and consistent feedback is like a blessing from above. It means more rapidly being able to grow, adapt, and mold yourself around the constraints of the language, paradigm, framework, and problem. It means being free to make many mistakes fast, knowing that the repercussions are minimal. It means rapidly iterating on and testing any new idea.

Defining Moment

One of my most memorable moments of graduate school was not related to law or even academics generally, but actually came about as a result of the educational application I was building that summer. After I spent a now seemingly abnormal amount of time hacking an algorithm together to randomly sort an array of questions for a quiz maker I was building, my working solution still felt inefficient and left me unsatisfied.

Yes, the sort was fully random and yes, it did ensure that every question was in the final sorted array (and in there only once). But I knew there had to be a better way, and I started reading and searching my way through Stack Overflow, Reddit, and various blogs.

When I finally came across the Fisher-Yates shuffle, I had what would probably best be described as a religious experience, as I marveled and stared in awe at the simplicity, brilliance, and elegance of its algorithm. Three lines of code did a much better job, both computationally and descriptively, of addressing and solving the challenge than the twenty or so lines I had written.

It was both a profoundly humbling and invigorating experience. I realized there was this vast, deep, unexplored ocean of learning open before me, in which I had only been swimming on the narrow, shallow shore. I also had to finish law school and, well, you know, become an attorney. Or something that could pay me enough to buy my sweetheart an engagement ring.

Deciding to Learn More

Fast forward a few years of working in local government, getting married, and not being serious about a legal career enough to take the bar exam, I found myself increasingly turning to software to solve problems at work, and also just to have fun.

Yes, you guessed it–I’ve been a gamer, also from a young age. Sid Meier’s Civilization and Microsoft’s Age of Empires series have both been staples of mine for a long time. I’m also a recent convert to Blizzard’s StarCraft series. It was fun to discover that even the CEO of Shopify plays StarCraft from time to time.

But I still had no formal training in computer science, and I did not want to go back for another bachelor’s degree, especially not after having gone through four years of a draining law and master of public policy dual degree.

I also wanted more practical training rather than exposure to the theories underpinning computer science. I wanted to be able to quickly build a fullstack application from the ground up, connect it to a database and any needed APIs, set up user authentication, and ship it off through Heroku.

Yes, I had already done all of that with the couple Rails applications I had built. But I wanted to understand not just how to use a framework, but why the framework worked, and how it worked. I wanted to be able to build a framework myself.

I also wanted to be employable and build someone else’s specs, in a team setting. That required a whole different set of skills.

Bootcamp Experience

I enrolled in a bootcamp which shall remain unnamed. It was supposed to be one of the most rigorous and difficult bootcamps to get into, preparing graduates for senior engineering roles through a curriculum based on the MERN stack (MongoDB, Express, React, Node.js).

We did lots of pair programming, which was great and very useful. We had weekly algorithm problems to solve, and we were also exposed to some testing libraries like Mocha, and state-management libraries like Redux.

But the nature of having to get through such a wide breadth of material in such a condensed, small amount of time meant that many of us were not understanding how any of it worked under the hood.

It was like being thrown at the wheel of a car blindfolded, and told to drive to a destination we had never been to before

We were using advanced JavaScript libraries without first having intermediate-level fluency in JavaScript. We were using complex data structures without first having a solid understanding of classes and object oriented programming (OOP).

We were using callbacks and closures without first appreciating first-class functions, scope, encapsulation, and what pass-by-reference v.s. pass-by-value means. We were using this without first understanding the JS runtime environment, webAPIs, and how execution contexts impact the value of this.

We were extending a React Component without ever having first created our own class and our own data types. We were using React’s page lifecycle methods and event listeners without first understanding the basics of the DOM, nodes, nor vanilla JavaScript’s native methods for DOM manipulation and event handling.

And just as we were beginning to wrap our minds around React, we were already moving on to Redux. It was like being thrown at the wheel of a car blindfolded, and told to drive to a destination we had never been to before–a destination that also kept changing along the way.

I left the bootcamp feeling less confident about my abilities than I felt when I entered the bootcamp. Forget about being job ready.

I wanted to spend the time to understand the fundamentals well first–and spend whatever time was necessary. Thankfully, my amazing, loving, and patient wife was not only supportive, but also able to cover our bills.

As a final note on this chapter, I should add that while this was my experience and that of at least several others in the bootcamp, there were some for whom the pace was great, and who did end up leveraging the experience towards a position.

Launch School

When I came across Launch School, an online school whose focus is exclusively on learning and mastering the fundamentals, I knew I had found something that was worthwhile for me.

But it was Launch School’s emphasis on mastery-based learning (MBL) that actually made it stand out from other options.

The gist of the MBL pedagogy is this: everyone takes a different amount of time to learn something well, and if you want everyone to learn something well, then you can’t constrain and bind the learning to a specific timeframe–especially not the same timeframe for everyone. You’ve got to let everybody progress at their own pace.

When I came across Launch School, an online school whose focus is exclusively on learning and mastering the fundamentals, I knew I had found something that was worthwhile

My recent experience with the bootcamp made me appreciate the truth and wisdom of this approach even more.

How do you get twenty-five students, all coming from different experience levels and backgrounds, through the same curriculum in the same amount of time, and have them graduate with the same skillsets?

Launch School’s simple and honest answer is, “You can’t.” Instead, let students go through the curriculum at their own pace, without any time pressure. You cannot learn well under pressure. Your brain needs that diffuse time to cogitate and make sense of the material while you do other things or just take a break.

The Launch School approach is itself broken down into three main phases:

1. Prep Phase
2. Core curriculum
3. Capstone.

1. Prep Phase

The Launch School (LS) journey begins with a required, free, preparatory phase. The first step of that Prep Phase is actually to complete Dr. Barbara Oakley’s excellent, free Learning How To Learn course on Coursera.

This course sets up the tone and the fundamentals you’ll need in order to tackle LS’s mastery-based, online curriculum that is not easy: patience, perseverance, and love for the process of learning itself.

A required book to read to further appreciate and understand LS’s mastery-based approach is George Leonard’s Mastery. (I also personally recommend Dr. Cal Newport’s So Good They Can’t Ignore You).

During the Prep phase, you’ll also get that initial high boost of confidence that comes from mastering the basics of Ruby and/or JavaScript. However, you may also soon thereafter discover what is best captured by Ygritte’s favorite thing to say to Jon Snow:

“You know nothing.”

2. Core Curriculum

The meat and potatoes of LS’s core curriculum is a set of courses taken progressively along one of two possible tracks: a Ruby track with Sinatra as the backend framework, and a JavaScript track with Node+Express as the backend framework.

Regardless of the track, however, the Core curriculum hammers in the fundamentals of OOP, slowing down to truly understand what is happening under the hood of even native methods like reduce and filter, and re-building those methods from scratch.

…the more important lessons of the Core curriculum phase actually are building up the confidence to learn anything, respecting the difficulty of the material, being compassionate and patient with ourselves and others in this process, forming good study habits, developing good technical communication, and being able to break down a complex problem into smaller, digestible parts.

There is a general rhythm to the Core phase of exploring the course content, doing the quizzes and exercises, studying and reviewing the content, deciding when you are ready for the assessment(s), taking the assessment(s), getting feedback, and moving on to the next course. There is a high bar for what is considered a passing grade, and sufficiently heavy penalties for not passing an assessment that students generally err on the side of being over-prepared before they decide to sit for the assessment.

It’s only natural to wonder how long the Core curriculum takes. But the nature of MBL, and perhaps its main drawback, is that time is the unknown component and varies by student. Some spend as many as three, maybe even four years in Core. Others are able to move through the courses and pass all the assessments in less than a year.

Along the way, however, everyone in Core covers a lot of material, including networking fundamentals that are critical to understanding sockets, TLS, and other security-related concepts. In the graph above, I’ve tried to capture some of the main technical areas covered.

But the more important lessons of the Core curriculum phase actually are building up the confidence to learn anything, respecting the difficulty of the material, being compassionate and patient with ourselves and others in this process, forming good study habits, developing good technical communication, and being able to break down a complex problem into smaller, digestible parts.

As trite as it sounds, you do end up with a lot more appreciation for the process of learning itself, and being less worried about the results.

3. Capstone

I’ve now finished the Core curriculum and am about to start the Capstone phase.

Many who go through Core do not finish, and many who do finish do not do Capstone–so there certainly isn’t any requirement to do so. In fact, there’s a long list of Core students and graduates who learned enough of the fundamentals to get a job or a promotion without going through Capstone.

But the opportunity to spend just a few more months polishing our skillsets, getting deeper into system design, and both understanding and participating in the industry-wide shift towards microservices-based architectures in the cloud, with a team-based, researched, and implemented solution of our own, was too great for me to pass up.

If Core was about taking however long one needs to master the fundamentals, Capstone is instead about quickly picking up any framework or library, exploring the documentation, and start using the framework within a short period of time. This is known as Just-in-time (JIT) learning.

While this may seem like a repeat of the bootcamp experience, the key difference is that having spent enough time mastering the fundamentals, we can now actually go at the fire hose pace that the bootcamp expected of all students.

We already know JS-flavored OOP. We understand the browser environment, webAPIs, DOM Nodes, and the place of AJAX and APIs within a larger framework. We know how DNS works, and the TCP/IP layers of an HTTP request/response cycle. We know how to intelligently read and use documentation.

We’ve gotten under the hood and rebuilt even native methods from scratch.

There is a certain baseline level of competency I can expect from all fellow participants in Capstone, because one of the requirements is to have completed the Core curriculum. So there isn’t as much variance between individual skillsets as there was in the bootcamp.

We’ll cover and do many things in Capstone, but I’m most excited about the opportunity to work on a research problem and solution together with three other smart, compassionate, and dedicated people. Looking at you, Leena, Austin, and Sophie!

I’m excited about officially entering this amazing field. I’m excited about what’s to come. I’m grateful for what has led me to this point–the good, the bad, and the ugly–and all the people who’ve been and are a part of this story.

Thank you.

I appreciate any comments, questions, feedback, project ideas, tips, personal experiences, or thoughts you are moved to share. If you think others might also enjoy reading about my journey, we’d be grateful if you could share this post within your network.