Hi there. I wanted to query the collective knowledge and experience of those who haunt these forums in an effort to find relief from something I can only describe as programmer's block.

I know what I want to make, but the knowledge about programming I've gained the past few years have only made it harder to get anything done without trying to do it 'right'. For some reason, doing it 'right' is taking precedent over getting it done. It becomes more of a chore, and less of a fun hobby.

Just getting into OpenGL 3+ has become a daunting task, trying to implement a highly versatile rendering system capable of everything I can't forsee.

That's just the issue though, the sense that I always code myself into a corner with projects, which has instilled a deep need to do everything as generalized, modular, and data-driven as possible. I feel I have taken certain programming tenets to extremes, yielding to nothing.

I have heard things such as YAGNI (you aren't gonna need it) and KISS (keep it simple stupid) and I'm still struggling. How do I surrender!? What should I focus on. I just want to switch off this awareness I have gained, or at least tone it down, to where I can actually knock stuff out and enjoy doing it.

Has anybody else struggled with knowing too much to be productive? I'm paralyzed!

Thanks

I know too much as well. But about optimization. I made a game and it ran rather poorly on an Android device. I now know what to do to make it run fast on an Android device. So every time I add a feature, I ask myself beforehand:

-How much performance will this take?

It doesn't make it any better that I'm trying to make one of the more demanding 2D games, one that is fast-paced with a lot of track.

But programming itself isn't what's weighing me down - it's design and optimization.

In your case, I might recommend trying to make anything. Making things will hopefully get you in the right groove.

I knew a guy with similar game making experience to me. We used the same tools, etc. But the one of us doing the most productive thing came down to who was "hot" at the time. "Hot" is a term I use for continually doing something and somehow, in some unexplainable way, doing something constantly can build your mind up for a time to do it even better.

This is where a paper notebook or a sorted spreadsheet are awesome.

You don't need to do everything. If you see something you want to do, write it down or add it to the list. Prioritize the list regularly. Cut things near the bottom of the list, you'll probably never get to the low priority things anyway.

For game designs, at work I view every design as a checklist, and my designers and our teems have had that work pretty well.

Do a single item, cross it off. Do the next item, cross it off. It is just a task to get done, like folding a load of laundry, feeding the pets, or doing homework problem 17. No stress in any of those, right?

When doing an item, you don't need to stress out. Most programmers are lazy (rightly so) and will just implement the minimum to get it done. Do just enough to check the task off the list. Don't aim for perfection. Don't worry too much about bugs. Don't worry about missing features. Don't worry about optimizations. You can find the obvious bugs by spot checking when done, just like you would verify your answers on a math quiz by working backwards; run the program, try the edge cases you can think of, and call it good enough. Instead of worrying about optimal, just think about minimally adequate; choose a single pass rather than nested passes, base implementation choices on how it will be used, but don't worry about optimization since if it is a problem QA will point it out. Just implement the first thing on the list, verify it works in the program, test around it, submit, cross it off. Repeat every day. Don't worry about the list ever getting empty.

Whenever someone sends you a request, write it on the list so it doesn't get lost. Someone might complain if you put the work off for several days as a lower priority item, but it won't get lost in the daily shuffle. Whenever you think of something to do or an improvement that needs to be made, put it on the list. Found a bug? Goes on the list. Thought of a crazy awesome optimization? Goes on the list. Idea for another great game? Goes on the list.

The list is awesome. Keep it on a notepad and put dates they were added and completed, and it doubles as evidence for your annual or semi-annual performance review.

I recommend getting into a game jam to forcefully push you in the 'productive' mind set, its really a revealing experience: no time for over thinking, only for vomiting working code as fast as you can ( you do with what you got, your current experience level, instead of thinking in the best way possible you do in the best way you can). Its good to show yourself how much you can pull of.

The scary part is that that "method", at least in my experience, is faster for progressing than the "over thinking till you got the handsome solution". I find that you learn more by trying more in short times with lots of mistakes and redoing than spending too much time trying doing it perfect in the first try. Its really a mind set thing, generally in the over thinking mindset you go slow, stop, analyse, you dont give another step before be sure, etc..

In the "vomiting way", you make shit work, than you realise what makes it shit, clean it, still working, figure out some bugs, redo it..its more experience, faster. And its more rewarding cause you actually get something to toy with (cause its already working even when its shit)

Radioteeth, your condition has been know even before I started programming and I'm old ^_^

In DonaldKnuth's paper "StructuredProgrammingWithGoToStatements", he wrote: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."

http://c2.com/cgi/wiki?PrematureOptimization

http://en.wikiquote.org/wiki/Donald_Knuth

So, learn to not worry too much and care about your code architecture and data handling at the start of a project.

Modern profilers do a great job of showing the real bottlenecks later on.

Cheers /Carsten

I actually just signed up to throw in a 'me too' post, as when I read your post Shane I immediately thought, "Hmm, that sounds familiar." as I have that exact issue. I wouldn't say I know all the answers, but I know enough to identify red-flags and see good approaches. So I often spend a lot of time stuck in design-land not really making meaningful progress, or, I implement some pattern or another and then change my mind and refactor it, only to revert it later. Either way, the end result is not much progress. Ironically when I was starting out I made 3 game prototypes, they are fairly diabolical from a code perspective, but hey, there they are, running, working, finished.

Just getting into OpenGL 3+ has become a daunting task, trying to implement a highly versatile rendering system capable of everything I can't forsee.

Analysis paralysis hits everyone eventually. If you can't forsee the need, don't worry about accounting for it. Worry about what needs to be done, or as ApochPIQ said, focus on the actual requirements of the project. If at a later date you need something done differently, make a note in your code, and return to it in a later revision.