To a first approximation, "software engineering" refers to all of the things you need to know when you take "programming" and try to scale it up - more code, more people, more time. You don't need an a civil engineer to dig a latrine, but you'd better have one to design a sewer system for an entire city. Likewise, you don't need a software engineer to write a small one-off script, but you will if you're designing a distributed filesystem. Many of the discussions about "everybody should learn to program" seem to go in circles because the participants don't acknowledge this distinction. Applying even a common skill often requires a new level of professional rigor when done at a larger scale.
One of the things you learn about as a software engineer, and not "just" a programmer, is technical debt. To boil a complex idea down a bit, this is the idea that, as code evolves, it accumulates flaws. I don't mean flaws in the sense of things that behave incorrectly, but flaws that make the code harder to work on - messy (often duplicated) code paths and data structures, "impedance mismatches" that force one piece of code to compensate for another's strangeness (with the effects usually rippling ever outward), and so on. Over time, you end up with code that does what it does pretty well, but can barely be persuaded or coerced to do anything else and ultimately becomes obsolete.
If technical debt is stuff that slows you down, technical credit is stuff that speeds you up. Just as technical debt often consists of things forced into a release for the sake of expediency (with an intent to go back and "do it right" later), technical credit consists of things that are left out of a release for the sake of caution (often it's the "do it right" but wasn't ready in time). Specifically, it's a library of solved problems in the form of prototypes, code snippets, or designs in various stages of completion. As a project progresses, these previously isolated bits of hard-won knowledge can be pressed into immediate service, instead of having to wait for solutions to be developed from scratch. Technical credit is thus primarily a risk reduction or mitigation strategy. If you have ten solutions for various hard problems "on the shelf" and you only need five, the benefit in development velocity might far outweigh the cost of having developed another five solutions you don't need (yet). Developing technical credit can also be considered a career-development strategy, or even a perk. (This post was inspired by a discussion of Google's "20% time" which fits this description.) Increasing technical credit is fun. It usually means solving technical problems that are much more interesting than those in the current version, in relative isolation and without the time pressure of having to fix the bug du jour.
The reason I'm writing this is because it seems like a lot of people never think about technical credit - let alone have a structured way to think about it. Both traditional and new-age development processes focus entirely on a direct line from writing code to releasing it. The idea of writing code and then letting it sit for a while has no place in either model. (This same problem shows up in synchronizing separate "upstream" and "downstream" projects with open source.) As a result, many projects go to battle each release cycle with an empty arsenal. Organizations that recognize the existence of technical credit and assign it a proper value will - over time - outperform those that don't.