Developer Scope
One of the things that sets Computer Science apart from other fields, and allows for its exponential growth, is the ability to abstract functionality at the cost of performance. From the transistors to chips to OS to the code itself, libraries and functions galore. you don’t need to know how stuff works in order to make it work for you. But the point at which you draw the line between “this is the way things are” to “this is the way things should be” is a massive influence of the type of work you’ll be interested in doing, and the breadth of your effects.
Compared to this depth-oriented scope, which is interested in peeling away the layers of abstraction, there is another, breadth-oriented scope. This is the conceptual playing ground of each software developer, and this grows over time as smaller layers become trivial to you. If you’re working on a real project, all the levels are important, and you’ll be working with all of them —this is a matter of focus, not of comprehension ability,
The function level is where people entirely new to coding start. They may not know it’s a function, but it’s a single consecutive piece of code, that fulfills a purpose. At this level, you’re interested in what the code is currently doing, what the desired result is, and how you get there.
The class level is what results from functions calling other functions, and you find yourself needing to categorize these functions into containers for functions and data. “Is this class doing what it should” is a harder conceptual question than “is this function doing what it should”, which leans on defining what the class should be doing. There’s a reason that “naming things” is the hardest part of Computer Science, and that’s because the naming is the final stamp of defining purpose, whether that’s at the function, class, or project level. It’s usually at this level that the person gains an appreciation for how the code is changed over time, and starts appreciating source control, testing, and other concerns which are simply uninteresting at the function level.
The component level (call it what you will) is concerned with a single piece of runnable software (.sh file, exe, jar). As well as overall project integrity — “is this component doing what it should” — here concerns start leaking outside the code itself. Why, how, when and where is this run? How can these change over time? What process converts my code into a running piece of software somewhere real?Where is the data stored for long-term usage, if the component restarts? If CI is appreciated once you’re working with classes, then here is where CD starts being essential.
The project level is concerned with how the various components work to meet business requirements. Interfaces, architecture, business demands, project maintenance, etc. At the component level you may always want to upgrade to the latest version of whatever you’re using — at the project level, it may not be worth it.
The multi-project level is one that I’m just touching on, and so I lack the required sight to see all the ways in which it is expressed. This can be in large companies, defining project lifecycle management; By creating libraries or frameworks, that will enable multiple projects; or by creating solution archetypes, that can be implemented in a variety of ways and languages.
What to me appears to be the final level — though in truth it may be many, but I’m not close enough to separate them — is what I’ll call the domain level. This means changing the paradigms of how people in your domain work. It could be build tooling, library repositories, architectural concepts, or even the code concepts themselves. Enums, nullable types, extension functions, lambdas — creating these in the first language where they appeared boggles the mind, but even “just” adding type decorations to a previously untyped language is a change with ripples for decades.
Very few of us are coding the next language, or changing fundamental concepts. The point isn’t “bigger is better, therefore get out there”. The point is, “it’s possible”. All of these domain-altering changes were done by people, and by having a scope scale as a map, we can see if we’re interested in heading in a particular way — whether that’s down, out, or up, as it may be.
