As Jtsummers says, once you're talking about small programs working to form a system, they're not independent small programs anymore -- they're modules in a larger system. My point is, if you design the modules well, you don't usually have to think about the internal structure of each module when you're trying to think about the behavior of the entire system. Such design is exactly software engineering, in my view.

> Should "ability to program" be measured by how large a program one can write?

Yes, absolutely: that's a very important measure of programming ability. As I think Fred Brooks pointed out in The Mythical Man-Month, each order of magnitude in program scale requires new techniques and a new way of thinking.

I wouldn't say it's the only measure of programming ability; there is a place for finely crafted small modules. But on any project that's setting out to build a substantial piece of software, you need at least a certain number of people who know how to do that (then they can teach the rest). If nobody knows how to do it, the project is likely to fail.

> if you design the modules well, you don't usually have to think about the internal structure of each module when you're trying to think about the behavior of the entire system. Such design is exactly software engineering, in my view.

I've been trying to find the right way to phrase this, as it's more of an inkling but touches on my current academic (self-study) interests but also is something I've observed over the past decade or so as a professional developer and tester in the industry.

The engineering component of software engineering needs to study systems engineering. There's a great deal of overlap. My conjecture is that we move from "programming" to "software engineering" when we are more interested in the connections between components rather than the components themselves. Much like how systems engineers aren't doing the work of designing the new car engine, but are overseeing that work and the work for the production line itself and coordinating with the glass manufacturer for the new windows. They care about how different parts of the final system (at the level of the car, or the level of the whole assembly process) will function between each other. Systems engineering (as a discipline) has the tools to handle this sort of division of labor and abstraction and responsibility.

And it's not really that we don't care about internal behaviors. But that's not the primary concern of the overall system engineer. It's the component's engineer who's primarily responsible for that, while the system engineer needs to focus on how that portion fits into the overall architecture.

No program is small, as it must include the operating system.

Now - you could go down to machine code, or work on embedded systems, etc etc - but the point remains. It's not just the software you are writing that's part your program, it's also all the other, existing software (and physical designs) it makes use of, or interacts with.

Edit: Might be called "software systems engineering", or maybe "dev ops"?

That's not really accurate. I can write a small program that does not include the OS, but rather assumes it. Just as a vehicle designer doesn't have to include the gas or electric distribution infrastructure in their design, they can assume it.

If I'm conforming to someone else's interface (say the C standard library), that's equivalent to an electrical engineer assuming various standard interfaces for the equipment they're designing. It's a design consideration, but not a design task. So the project itself may still remain quite small.

When I'm designing the interfaces that others are using, or designing the interfaces between 100 [0] smaller programs so they can interact effectively with each other and their environment, then it's a larger engineering task.

[0] Arbitrary number.

And likewise, the OS relies on the ISA, not having to know about chip design.