Capstone Week 6.5: A balance of research, learning new technology, and learning how to learn

Here are a few of the many lessons I’ve learned over the past week and a half of capstone. I plan to keep this post short and sweet because, well, capstone doesn’t leave much time for writing…

The importance of working on a pre-existing code base

When you build an application from the ground up, you are present for all the design decisions. You are not just a part of the building of the structure (the actual code) but the planning of the architecture (the design patterns and diagrams). The code you and your team ends up writing is a natural corollary of the architectural decisions you already made.

None of this is true when you come into a project that’s already been developed.

When you are presented with a monolith of code, you have to understand what it’s doing before producing any meaningful work in that codebase (obviously). Instead of being in a position of writing code from a pre-existing understanding of the architecture, purpose, and stories behind the code, you are in a position of looking at a massive structure without any background knowledge. As an engineer, an important part of your duty is to reverse engineer these principles and design decisions from the code itself. You have to digest the code and understand the stylistic preferences of the developers who came before you (and who may still be working on the project). You have to reverse engineer the design decisions, the intentions, and the way all the components of the code are supposed to interact.

This is also why making good design decisions is important: when other developers work on your code base, the way you design your code will inform them about the way they should design their code. If you do not design with the right principles in mind, minor design flaws can proliferate until your code-base evolves into a mass of brittle, fragile code.

Prioritize high-level understanding over understanding a specific tool for rapid learning

I work with a team of two other developers for almost 12 hours a day, six days a week. All of that time is being dedicated to software development, but only a small fraction of that time is being dedicated to actually writing code. That’s because writing code is the easy part. Software development is so much more: it truly is a thinking-person’s profession and that’s why I love it. As I’ve said in the past, my morning routine starts with 3 hours of studying before capstone officially begins, and those three hours are not only crucial to my success in capstone (because there is so much to study), but they are also crucial to my fulfillment. To fall in love with your craft as your skill grows is a gift, and also a key to a satisfying career according to Cal Newport.

Languages are a dime-a-dozen and so are frameworks. In fact, most people in our cohort had never touched back-end PHP frameworks until last week, when we we learned a “mental framework” for rapidly learning frameworks. After learning this “framework for learning frameworks”, we were appropriately tasked with learning a new framework in a language we were unfamiliar with in the span of two hours… and then we had to give a presentation on the fruits of our learning. We ended up going with Laravel.

I don’t identify myself as an <insert language name here> developer. That’s because I am not attached to any specific language, nor am I attached to any specific tool. The language only matters in so far that it is appropriate for the problem domain in question. The same is true for any framework or tool. They all exist to solve one problem or another. Therefore, to understand them requires understanding the problem that exists in their absence as well as the effects of their presence. To evaluate/critique them requires understanding other potential solutions to the same problem as well as what tradeoffs are introduced by each potential solution.

Always attack a problem at its foundation. For example, when learning about Laravel, my team did not start our search by figuring out how to download the necessary packages and start configure everything properly. Those are low-priority details. Instead, we began by understanding how it fulfills each of the fundamental requirements that any back-end framework needs to fulfill. Then we looked into the history of PHP development to understand how web apps built in PHP were built *before* Laravel was introduced. This gave us a historical context about what problems existed in the PHP ecosystem, better-enabling us to hone in on the core features of Laravel.

Well, my lunch break is over… I hope to finish the OO Design Part 2 article this weekend, so stay tuned!