I'm done with 10 chapters of my new book so far. There's some good stuff in there. I'm always glad when I get a book that makes me realize how little I actually know about something, because it's probably a good sign I'm learning something.
Stroustrup makes some nice comments about interfaces. He wrote a little lexer/parser program and then showed how he would break up the code into logical chunks and organize it. He split the "user interface" and the "implementer's interface" into two different pieces in the process. I'd never seen a problem laid out in quite that way done before. But it made me think about a lot of problems I have at work. When I think of "interface" I think of what the end-user sees when running the program. But the code a programmer sees when dealing with code you wrote is also an interface. In the interests of expediency at work I often find myself thinking "I have no time to clean up the backend. I'm smart enough to figure this out anyways, who cares if it's a bit clunky?" I'm pretty sure that comes back to haunt me more often than it should.
As a novice programmer, it's an effort just to get something that solves a problem at all. As you learn more, you start to think about how to solve it well: efficiently and cleanly. I think the next step is when you take it for granted that all the little parts of your program will work as they should; the new problem is getting all the little solutions to play well with solutions to other problems. I wonder sometimes how much of that part of it can be learned and how much of it is having a proper aesthetic taste and a proper way of thinking about problems.
It always amazes me just how easy it is to write horribly crappy code. Computer programming is like trying to shoot a target with a gun that has a nearly overwhelming tendency to want to point at your own foot.