Capstone Week 5: Know-how is useless without ‘know-why’ and How to Learn Frameworks like an Engineer

Learning how to use a framework is itself not software engineering. Learning the problems the framework solves in its problem domain(s) is closer to software engineering. If the project you’re working on poses challenges that are far beyond what a mere framework can fix, that’s software engineering. Facebook uses React and so does the practice shopping cart app I built in a day or two. Facebook is an incredible feat of engineering; my shopping cart app is not.

There are some aspects of learning a new tool or framework that I enjoy and some that I do not. I enjoy learning about the problems frameworks solve or the tradeoffs posed by different methods of structuring code. For example, I find the Flux design pattern simply genius. Building an app without Flux becomes incredibly messy as you have to pass the application’s state down through a multitude of components, only for those child components to call a long chain of ancestor functions until the component that owns the state is notified of the event in one of its children, grand-children, great-grand children, etc. Flux makes it astronomically easier to think about what an app is doing, how it’s state is being managed, and what components are responsible for even when the codebase grows.

This is what to focus on when learning a new framework: what problems does it solve and how? What is the philosophy out of which the solution was born? What is the general architecture and what pain-points does this architecture introduce? What prescriptive beliefs about how a problem should be solved informed the creation of this particular solution, and do you share these beliefs? If you do not share them, should you? A framework is far more than a tool: it is a declaration about the way a fundamental problem, or many fundamental problems, should be solved. When I am tasked with learning a new tool or framework, these are the questions I ask. I don’t care about memorizing the exact nuances of configuring webpack: that will come with time, and if it doesn’t, it’s something I can easily research in minutes. I can ask google what an error message means. I can’t ask google if the design decisions of a framework and the tradeoffs they introduce are ones that I agree with.

Learning a framework well and learning it quickly are not mutually exclusive if you are armed with knowledge of the fundamentals of the domain you are working in. You also have to prioritize your knowledge according to a pre-conceived agenda. My agenda is almost always: “Understand the ‘why’ just as much as the ‘how’. The reason is this: You will always be more proficient with a tool if you know its reason for existing and the reason(s) for the decisions behind its design. “How?” and “Why?” are not unrelated questions, and in fact, having a strong grasp of the “Why” will fortify your ability to use the “How”. This is because if you understand why the tool has the specific features that it has, then you don’t just have a grasp of the tool itself: you have a grasp of the reasoning processes, of which the tool is a manifestation. That means that when you inevitably encounter a technical challenge that is not amenable to a memorized set of commands and how-to’s, you can apply the reasoning behind the tool itself and navigate your way to a solution. That is the difference between a framework user and an engineer.

So we learned reactJS as a team this week. Give us another week and we could probably ship production quality code (and in fact we will be given another week). This is because we understand the problem domain enough to know what mistakes to look out for (and we know how to test to prevent these mistakes). We won’t, in other words, do something like build a crypto exchange that relies entirely on client-side validation.