I was going to say “me too,” but really what I like is starting with simple solutions, which is actually a different animal.
Real-life programming projects tend to be very big. I’ve worked on lots of projects which have been hundreds of thousands of lines of code each. I’ve got the source to Heroes IV here, for example, and it consists of 330,000 lines in 1500 files. You don’t optimize projects like that to start, since it’s both time consuming and error-prone.
Rather, you write something that’s logical and straightforward first. Reliability, readability, and ease of maintenance are where your initial priority. Later, you measure to see what code is using the most time, and focus your efforts on that.
Not only that, speed is the only thing you optimize for. “Least number of lines of code” isn’t ever a goal, though it can be a side effect, since you want to re-use code as much as possible since it both reduces effort and minimizes the number of places you need to make fixes.
That tends to carry over into how I view TIS-100. And Infinifactory and SpaceChem as well, though those are not really programming puzzles, they’re more programming-adjacent. They’re mechanical, rather than abstract, and when logic gets involved it’s more gate-level logic like AND, OR, and R/S gates, rather than programming.
I think the last time I focused on number of instructions, I was working on a computer with 256 bytes (bytes, not K) of RAM. Once I started working with the Atari 800, I had 48K of RAM, code size wasn’t a priority.