My takeaway was this:

"The third lesson I learnt was that you don't need great code to make a great product."

I really believe this to be true. Coders are far too analytical for their own good. If a product works great, then the poor code can be fixed later.

You know, this is really true. My company has recently been making the slow switch from "over-designed and implemented, resulting in a very slow release cycle" to "minimally designed, quickly (but smartly) implemented, fast release cycles".

This comes from two lessons to us:

1) No matter how long you spend designing a feature, it'll probably not be 100% of what the user wants. Do a quicker "draft" of the feature, solicit feedback, and release fast to fulfill customer needs.

2) No matter how long you spend trying to write elegant code, the software will have bugs, and other kinds of problems. Do it quick, observe it in the field, take notes and do bug patches.

Getting the team on-board for these was hard due to the resistance of this being the perceived Microsoft way of doing things, but it has resulted in much higher customer satisfaction because they see continuous progress and feel like their feedback is turning into product (they feel part of the process) rather than tens of months of no progress followed by something they probably didn't want to begin with.

Games are somewhat of a special case, though - as long as it works enough for the vast majority of players to complete the game without hitting a roadblocker issue, it's good enough. It doesn't need to withstand longterm maintenance.

True as that may be, I've worked on far too many projects now that are burdened by this attitude. No tests, sloppy and unreadable code.

My attitude is simple: code like the person who will be working on the app next is standing behind you with a gun to your head. Be diligent in making sure your code is legible, maintainable and documented. If you can't get to one of these now, at least make a note to get back to it.

I think that this is horrible advice for someone new. But if you've been around for a while, and understand that what you're doing is a hack because you need to get a product released, it's more acceptable.

It's a case of making sure that you know you're doing the wrong thing, vs just assuming that it's the right thing. The latter causes all code to be bad, and the poor code never gets fixed.

I do admire the ability to ship.

But some of the ones with that ability would be better off a little bit less goal driven and spending just a few hours a month reading up on their tools. (And the rest of the world would be better off, too...)

Edit: (A bit clearer syntax.) I might add -- it is OK to do evil stuff if you are in a hurry, but at least isolate those part so they are easily replaceable. (Yes, most everyone should know this.)

I'd agree with those as a summary too. My zero-th problem was that I thought 10,000 pounds was a paycheck I could live on!

I did feel pretty terrible about leaving the project at the time, and I never left a half-finished game again. I'm not sure this attitude makes rational sense from a selfish point-of-view, but I knew I was leaving my colleagues with more work by quitting.

Been there with a paycheck like that also. It's really really hard to stay committed through a year of Ramen noodles and Taco Bell for those days when you want to treat you and your wife to something "special" once a month.

At any rate, I'm sure it was a good learning experience all around. There is something particularly unique about game development in the software field that isn't necessarily shared anywhere else. I've heard many of these sentiments echoed.