How to snap out of the 'premature optimization' mindset?

[WombatTurkey]

Hey gus! I made this post yesterday and someone commented that it seems like I have a premature mindset and I totally agree. 

 

I actually had no idea what premature optimization was so I googled and found this:

http://programmers.stackexchange.com/questions/80084/is-premature-optimization-really-the-root-of-all-evil/80092#80092

 

I feel like I spend more time worrying about performance at this point in my game than actually getting anything DONE. And it's really irritating. It's like a lingering devil that's on your shoulder saying "don't add too many features, or send too many packets to the server through the Websocket pipe, or you'll harm the server".

 

So if anyone else here has struggled with this, what are some tips to stop thinking about optimization all the time and just code away worry free?

[ekeimaja]

I am now working on project, where other team wants to make the game on mobile. And I know that it is so heavy that it will never run on mobile, but I still make that game for love of creating games.

 

I think that you think things at wrong order. Which is more pleasant to you, creating game, or getting positive feedback from ready product? Ask this from yourself, what is reason why you make games?

[chg]

I struggle with this (I suspect even more than you)... and I think you're actually talking about several issues, that conspire together.

 

On one hand "premature optimisation" is not just a productivity killer, I'm pretty sure it's considered harmful. But that's partly, I feel, because it's often used to refer to what someone else thinks is misguided attempts at optimisation (where the coder puts effort into writing clever code that is not much more preformant than the simple code would have been or is actually worse - there's also the question of the extent that the coder's time may be wasted but I think that's more a consideration for coders not doing game projects).

 

Assuming you are not really young, it might help to remind yourself that even a lowly cheap, several year old powered smartphone is a supercomputer with more compute power than you used to be able to imagine, and that half of your intuition and bag of tricks may not even actually apply. So all your gut feelings about packing something say to send "down the wire" might lead you wrong say because the gzip done for you might do more say for your uncompressed data than your attempts.

 

In other way, I think some coders (sadly not all) really want to write code that they feel proud of good about less shame for having written, even if it doesn't show.

 

In a way these might be somewhat cathartic funny videos to watch (note: not all of it these will apply, but try and stick with them I think they will ultimately resonate):

 

 

 

Or just try to think of years of development hell that afflicted Duke Nukem Forever. You code will never be perfect, but shipping matters, alot.

 

Then again, if you are investigating these issues for fun or as part of a hobby... well it's nobody's business to tell you how to enjoy your time. I know people that enjoy writing 6502 assembler, to me it seems pointless, but they enjoy it... so do what you feel 

[mattstyles]

Oh man, I feel your pain, I spent 45 minutes of an already tight deadline optimising a few loops and feeling very pleased with myself for doing so but ultimately shaving mere ms off of a non-hot code branch.

 

I guess its the deadline thing, if you are working in a team and next week part of your team are blocked behind your stuff, but they dont need it to be perfect (maybe they need the API defined, or something fairly high level), then you'd probably defer optimisation so that your buddies can get cracking next week knowing that you can optimise (if necessary) at a later point.

 

Or maybe you need to get into the startup mentality: get it out there and working, worry about tidying up later. I hate this, I worry that the tidying up later will become extremely difficult but there are strategies to mitigate this and, frequently, you find that your code (whilst you know there are some horrors) is achieving its goals perfectly well. This does not mean you put in some horrible stuff, if parts of your code are rubbish then you'll know its there and be likely to take shortcuts next time, it just means that your code has to be good enough for now and you can revisit the little details later. When I say I hate this, I mean, I find it hard to adopt this mindset, but, when I have stuff working then I get a big encouraging boost which helps me through dealing with the little details that have been bugging me, all the while other people can be playing or looking at my stuff and the next phase of growth can be developing.

 

Or maybe, if its your project and you dont want the stress, dont change your mindset. If a client is paying you and needs it by the end of the month then your mindset has to be different from approaching a personal project that you'd like out by the end of the month but it doesnt matter if it goes out the month after that.

[permith]

The easiest way to stop is to get screwed by it.

 

If you like comparing yourself to others you can keep the mindset "an artist/animator/musician, that uses programming now has a higher useable output than me".   There are some really good games that are programmed by non-programmers, don't let their output be highers than yours

 

(bigger insult to injury if they consider themselves more a animator than programmer after making something like Dust  https://steamcommunity.com/app/236090 )