You should feel like that for game programming as well, at least for stuff that isn't being done on a per-frame basis. Big O notation is interesting, but I think people get really caught up in it. When N is small, and only being done on startup or once or whatever, then yeah, don't bother optimizing it. You can find out of it's a problem later once your startup time becomes an issue.

I've done both. Games paid less, tended to be less professionally run, and had much longer hours. OS development on the other hand, sane hours, professionally run (if a bit corporate at times), and better pay and benefits. Granted the latter is way more boring most of the time. If you have the fortitude to do non-games and work on hobby game projects as leisure, then go for it. Though it can be hard to spend 8 hours coding, and then go home and spend several more hours coding.

Funny quirk though, OS development, because the turnover is so low, the onboarding process for new people was terrible. I was used to the games industry, where it's much easier to get ramped up to work, with step-by-step instructions on how to get machines set up, sync to projects, build the necessary bits, etc.

Thank you everyone for sharing your experiences.

I prefer to keep game development as a hobby and engineer enterprise applications/web services by day. I rarely work late which affords me some time to work on a game. This gets tricky though. I spend nights with the wife and kids so I'm usually up anywhere from about 3:30am to 5:30am. I'm at work by 7. I bring my laptop so I can work on the game during lunch. Sometimes, I get some time in at night on the weekdays and I usually knock out a good 8-10 hour day on the weekend. It's tough but I get the best of both worlds: professionally engineered solutions vs. crazy-fun game stuffs.

My two cents on keeping game dev sane:

- Learn to refactor and keep doing so until you have a solid, comfortable-to-work-within(TM) game framework

- Make time for the non-gamey stuff: tools, menu systems, etc.

- Make time for the cool stuff: I used to put all my time into the big tasks but have started maintaining a list of really cool, easy(-ish) to implement features and tackle those whenever things get stale. A lot of great gameplay and unexpected features have come out of this.

I've dealt with some pretty hairy UI code in business apps and websites. On the web now especially, you have to worry about optimization to get a bunch of bloated javascript to run smoothly on smartphones. It's not exactly well-engineered; I only get a chance to do that in games. Grass is greener on the other side.

Have to chime in on this.

I was working as a tool dev for a couple of years (and slowly migrated to an r&d position), and building tools / UIs are definitely not a simpler tasks than working on more lower level problems (like rendering). It's even harder, because you not only have to create a pleasing UI but also a very efficient / optimized workflow. Both performance and pipeline wise, move the least amount of data and do the least amount of calculations, because users (artists) want to have the fastest possible feedback from all their tools. Also, most of the times you have to do this inside a closed source environment (maya, unity, unreal whatever), and not only deal with the actual problem but the bugs and sometimes inconvenient inside your host application.

The guy in the second picture isn't a programmer. Dead give away: programmers don't wear suits! :-D