Going into this, I expected a Software Engineering course to be mostly about learning to code — picking up a language, writing methods, building features. I’ve done a lot of that already, so I’ll admit I expected most of week 1 to be review.

In a lot of ways it was, but the framing was sharper than I expected. The thing that actually stuck was the emphasis that software engineering isn’t the same as programming — it’s programming integrated over time, where maintainability and the fact that code outlives its author matter more than getting it working once. The clearest version of that was testing: the idea that you’ll write more test code than application code, and that the test suite is a big part of the deliverable, not a chore you do afterward. Lab 1 was a few lines of controller logic; lab 2 was testing those lines, and the testing was the bigger piece of work. That tracks with my own projects, where the things that broke were never the code I wrote once — they were the parts nothing was guarding.

So my opinion didn’t really go up or down — it moved sideways. The material wasn’t above my level, but it put names and structure on things I’d half-figured out on my own: technical debt, shifting left, testing as a first-class part of the work rather than an afterthought. Useful review more than revelation, but the vocabulary alone makes it easier to reason about why some of my past projects aged well and others didn’t.