Writers and software engineers have more in common than they realize. That they’re both slaves to the rules and exceptions-to-the-rule of a language is the more obvious commonality. But, beyond that, they both endure a sort of emotional trauma everyday when they open their laptop and stare at a blank page, perfectly empty but for a cursor taunting them to hurry up and fill the void.

Little do they know that the overwhelm of not knowing where to begin, or how to bleed their brain onto canvas, has a common cure. The antidote is structure. In English, they call it the outline, and in engineering, they call it architecture or ‘design patterns.’

How many high schoolers has the five-paragraph persuasive essay, with its thesis introductory paragraph, three supporting middle paragraphs, and the final conclusion, saved? Would we have ever known how to argue for affirmative action without it?

Structure is dogma in our early linguistic education, but, for some reason, the same allegiance to order and predictability does not extend to programming. Aspiring coders are routinely told not to worry about writing clean, structured code in the beginning, and instead, to focus on just making it work. The topic of software architecture is either put off as something more advanced, or dismissed as theoretical or academic. But, I’d argue, that even knowing one simple design pattern is crucial for a budding programmer. How else will they know how many modules to make? How to effectively use classes and inheritance? What order to write their functions? Where to call things, how to name their variables?

In the unforgiving ecosystem of programming, where literally everything is connected and a single extra semicolon will sink the whole ship, organization is an absolute necessity. Even more, for a newbie, it can be a matter of existence. It breaks down the intimidation and dread that comes with inexperience by asking the junior programmer to fill in the blank spaces instead of the awful entirety of the blank page.

Model View Controller (MVC)

If you’re stuck on how to start building a web app, a good, basic design pattern to use is Model View Controller (MVC). The MVC design pattern essentially breaks your app down into three distinct and interconnected components, thereby creating a strict separation of concerns. As the name suggests, those three components are Model, View and Controller.
Image Name
The Model module, or file directory really, deals specifically and exclusively with the creation of Classes, their Properties and Methods. Said more simply, it’s where you write your definitions. What is a Shopping List? What traits does it have? How does it behave? On its own, the Model module doesn’t do anything. It’s literally a static Object dictionary that, without being called or used, has no functionality and simply observes.

The Model feeds into a separate module called the Controller. This central file, which, by convention, is always called index, is a meeting point of sorts for all of the app’s Models and Views. It’s where new Object instances are created and where nearly every function is called. If your app has a state variable, this is where it will live. If you’re fetching data from an API, this is where you’d write the code. Need to write event handlers? The Controller is where you’d do it. Index is where you write the conditions and permissions that allow passive Objects to become active. It’s often the longest, most important file because it’s where the app essentially comes alive. If you like cars, it’s the engine.

View hooks into the Controller in much the same way as the Model module, and is best thought of as the User Interface (UI) module. Its only concern is the visual display of the definitions and commands it is fed from its sister Modules. In Front-End Development, View is where you write HTML markup that changes dynamically with user inputs and behaviors. Without View, no dynamic functionality is visible to the user, even if it’s running behind the scenes in the app’s Controller engine. But that doesn’t make View shallow and devoid of programming logic. If you don’t like the way a row, a word or a number looks on the screen, View is where you’d write the functions and operators you’d need to fix it.

Per MVC architectural guidelines, each of these three modules is strictly limited to its specific role. The engine can’t mix with the paint, and vice versa. But, practically, how the modules interact and create a fully-functional app is actually quite simple. All you have to do is make sure all of the files are connected through import and export commands. Once the parts are attached, you just weave them together through parameters and inter-Module property pulls and function calls.
And just like that, you have an engineered product built on sound architecture: one that won’t break into a million bugs if a single letter changes in the code, and one that will spare any peer programmer or code reviewer a few WTF-moments.

If we saved our sixth-grade English teacher from the horror of reading a rambling wall of text, why not do the same favor to ourselves and our fellow programmers?