Splitting Code Into Modules

日本語はこちら。

I had an occasion to chat with an old friend from my computer science class in university who's now an associate professor in information science. As part of his job, he teaches programming.
Both being engineers and are in a position to educate or grow junior engineers, we naturally started talking about programming education.

I made the claim that there are engineers who can kind of get things done by looking at the surrounding code, mimicking it, fix any errors or bugs that come up. I once interviewed a mobile app engineer who told me he doesn't know how the views and view models worked and that he gets by by copying other screens and making the minimal changes to make it work.
Then there's the engineers that can not only do that, but also come up with solutions to problems that they haven't seen before.
Most engineers probably start from the former camp and then gradually move to latter camp as they gain experience. So the question is, what are the steps to get from the former to the latter? One would say it's experience, but I want to stay away from that answer as it's hard to replicate (i.e. teach to others).

One interesting point the friend brought up was that he notices that one of the early steps is the ability to split code into "modules". "Modules" have different meanings depending on the technology stack and what he meant was the ability to split code into separate files.

We both agreed and kept on talking about this for a while and came up with a few reasons why this is important.

1. Forces you to split the code meaningfully

When all your code is in one file, it's easy to refer to various parts of the code as it is all in scope and you just need to type the name of the variable, function, class etc.
Once you have to split the code into multiple files, you need to think about which parts go in which file and how things should be grouped to together. No one will inherently try to split it at random place (e.g. every 100 lines) as that would be meaningless. You need to think about the meaning of every part of your code and split it in ways that make most sense to you.
As any experienced engineer knows, this is a very important skill to have and is at the core of designing software.

2. Forces you to think about the interface

As part of splitting up the code, it forces you to think about how one file should refer to in another file. This means you need to think about the "interface" the file provides to the outside world.

• Do you need to expose all the functions and variables in the file?

• Do you need to expose the class or just the functions?

• What parameters makes most sense to the caller? etc...

This is essentially what you do when you design anything that others will use (e.g. Web APIs, libraries, etc...) and is crucial skill to have.

3. You need to know how to use multiple files

This is a more practical one. In order to use multiple files in your program, you need to know how the your programming language actually works. For example, in C, you need to know how to compile multiple files and link them together. In Python, you need to know how to import modules and packages. With the prevalence of feature-rich IDEs, starter projects and project templates, many engineers get by without knowing how their files are actually being stitched together.
95% of the time, this is fine, but there are times when knowledge around how your code is being executed becomes crucial. For example, if you're building a mobile app (iOS or Android), you would usually be using Xcode or Android Studio to code and run your app. However, when you need to build the code in a CI/CD environment, you will most likely be using some other tools which will require you to know how they pick up your files and build them.

Extends further than files

After talking about these points, I've come to realize that this is essentially what us, engineers, do when we design software. We have a grand vision of what we're trying to build, but we need to break it down into smaller pieces that we can work on. We need to think about how these pieces interact with each other and how they should be used by others. We need to know how the pieces are put together and how they are executed. The pieces I described in this post were files but it extends further into things like packages, libraries, microservices, etc.
Splitting code into separate files is one of the first ways we put those skills into practice and thus is a very important early step in learning how to program.

I think I'll be using this as a way to evaluate skill levels. Hope this helps someone out there as well.