I consider everything I do, "engineering." Been doing that, all my adult life.
Feel free to look at the stuff I do (I link to it in my HN profile). The app I'm working on isn't there (yet), but a number of its components are. It's still "under wraps."
I witness on a daily basis PRs that have no body getting merged with absolutely zero comments and a blanket approval as long as it passes our (broken) CI pipeline. I witness obvious poor quality in the code, but engineers want to seem like they are working and will just blanket approve PRs, while i'm in the middle of writing up my code review denying the PR.
If you are a developer on a team and want your codebase to be high quality, you end up no longer writing the code and instead spend all of your time gatekeeping via code reviews. This leads to burn out.
The obvious answer, is to hire experienced, skilled, capable engineers, and instill in them, the same reverence for Quality that you have.
Like I said, Quality is expensive. Very few companies like to pay the premium.
So I would say engineer is a poor term, but also the only one we've got for now.
So it is not exactly like you've said:
> You can't design it first and then go and build it.
You can design, but you cannot build.
A process of building by a design can be paralleled with deploying software -- suddenly there is a hairy real world, not all the hair was considered at the design phase, and either we hack around existing software (i.e. design plans), or call a programmer to redesign.
You can't design it in full in one go, but you can design it and then incrementally update said design. Sadly many (companies) do not. But you can define the problem(s), the scope, the scale, and then design a solution appropriately to meet those needs (for a defined period of time). That's what distinguishes software engineering from hacking. They both have their place. Many companies claim to do the former but are mostly doing the latter. Software is still early in its life and as various kinds of system designs stabilize, so will the formalizations around what it means to be a software developer. Reading a book like Designing Data Intensive Application's you can't help but see those formalized topics budding.
It's not exactly a "one-man show," but I'm the chief architect, and the only one developing one of the three servers the app uses (I was also the original architect for another server, that is now being run by a different open-source team), I am also the only one developing the native iOS application. I may be writing some adjunct apps, once the main one has been released (like Watch, Mac and TV apps).
But we're a team. It's a 501(c)(3), with a mission to Serve a specific demographic. We have the advantage of being intimately familiar with the demographic. So far, we haven't had to shell out much. If they decide to write an Android version, then it may take some extra dosh. The good news is, the app is in "constant ship" state, so asking for funding is fairly straightforward. We just need to loop the person into the TestFlight group, and Bjørn Stronginthearm is your uncle.
When I do stuff for myself I apply the same principles I apply at work. It's insane how easy it is to change stuff later on. Didn't think about this use case before but now you do? Because I have properly maintainable code that is readable its very easy to change and changes are only needed in one place instead of all over the place. Knowledge of the right thing is kept in the right place instead of implicit knowledge all over the code etc.
It also helps to have 'one team be responsible for each service' instead of 'everyone can work on everything'. It's insane how fast you can move if you know the code well and it's maintainable.
I also pretty much never get questions about the code that I pass on to others.
I write about my process here: https://littlegreenviper.com/miscellany/leaving-a-legacy/
(Long screed. Few read it).
As a designer I’m a bit embarrassed by the trend to describe ourselves as product designers. To me a product designer makes chairs and coffee tables.
Apple also displays extremely high quality code, in the areas that are exposed to the public.
I have not seen too much Adobe code, but I’m told you can eat off the Photoshop codebase.
For myself, I need to keep my scope fairly humble, but I get great joy from it.
It sounds like a gratifying environment. Good show!
The only reason you can design a bridge beforehand is because (millions?) bridges have been built before so you can apply the lessons learned. Even if your bridge is "unusual", it will still be similar enough to older bridges so you don't have to invent the vast majority from scratch.
Other kinds of engineering don't have the luxory of leaning on the prior experience so much, simply because there is less of it. SpaceX's reusable rocket could not have been be fully designed before built, simply because nobody built a reusable rocket before. But it could be done through iteration, which is just another name for experimentation.
Software tends to be less like bridges and more like rockets... all of which falls within the spectrum of "engineering".