Mau:
This is a very nice list for keeping an open mind and trying to grow. I have a few comments to the specific points below:
3. Process is more important than outcome. When the outcome drives the process we will only ever go to where we’ve already been. If process drives outcome we may not know where we’re going, but we will know we want to be there.
This strikes me as a good tip for growing, but not necessarily a good tip for building software. I'm attempting to find cross-cutting applications for many of the points we make in the class (quotes and whatnot), so saying that is not an attempt at harsh criticism, just an observation. I think, for example, both the Agile process and Waterfall process are driven by goals (here, an "outcome," I think), and if you tried to do it without an attempt at a desired outcome, it'd be rather haphazard. Many of the other points apply very well across industries, so it's at least good to note this, I think.
4. Love your experiments (as you would an ugly child). Joy is the engine of growth. Exploit the liberty in casting your work as beautiful experiments, iterations, attempts, trials, and errors. Take the long view and allow yourself the fun of failure every day.
This point, to me, applies to comp. sci., "sometimes." While writing software, it may be good to avoid "broken windows," but if you inadvertently create a broken window, it's better not to hate yourself for it and dwell on the mistake, but to try to fully recognize the problem so that it can be fixed later. Sometimes you might be learning about a piece of bad code from somebody else, so there's no use kicking yourself while you're down, but keep an open mind and potentially fix it.
5. Go deep. The deeper you go the more likely you will discover something of value.
This applies 100% to software design, but not really implementation. Don't go with just the first idea for software design. At least try to come up with several other designs that can range from god awful, to good, to great, to best idea ever. I've seen plenty of guys who thought they knew the best way to design the code from the start, and it's impossible to get them to change their mind. At the same time, you can't "go deep," and try everything while implementing a software system, because you'll run out of time.
16 Collaborate. The space between people working together is filled with conflict, friction, strife, exhilaration, delight, and vast creative potential.
Applies 100% to both software design and implementation, since I regard this as "communication." Here's a study that cites, "breakdown of communication," as the leading cause of software project failure during its lifecycle: http://www.it-cortex.com/Stat_Failure_Cause.htm. It's good to keep open communication channels during all phases of a software project.
This is a very good list, I think. Of some note, "avoid software," I think applies to, e.g., the phenomenon that every resume written in MS Word looks essentially the same, or everyone has a stained glass Photoshop filter (I think). That's a very good point to make, but perhaps it could've been explained a little better.
In any case, I cannot access the Hargrove piece, unfortunately, so I can't comment on that right now. I think there's been taken down or something. I will ask later.