4 ms·

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

by Flankk 17y ago

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.

berntb 17y ago
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.)
barrkel 17y ago
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.
elblanco 17y ago
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.
jherdman 17y ago
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.
shelfoo 17y ago
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.

by Flankk 17y ago

berntb 17y ago

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.)

barrkel 17y ago

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.

elblanco 17y ago

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.

jherdman 17y ago

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.

shelfoo 17y ago

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.