That sounds very recognizable. For me, in the end, it comes down to what makes programming fun for you, which is often not the same as what is most effective ("gets the job done"). You could give up your senseless "code polishing", but frankly, that would make programming from "fun" into "work", and you might as well choose a different career.
I have some bad habits that cause me to take longer to produce the same programs. For example, I abuse macros excessively, because I derive pleasure from "perfect factoring", even if it hurts readability. I violate "premature optimization is the root of all evil". I don't care. the feeling that my code is doing something retardedly slow reduces my enjoyment of working on that program, so it has to go. Illogical, but its the only way I want to be a programmer.
Yeah, I realize now that a lot of my coding style is not really for efficiency (though I think it is efficienct) but also largely because it's simply the way that I enjoy. And that's reason enough for it.
Obviously that applies to what you choose to work on each day too. The fact is for 99% of game developers, they should stop working on fancy graphics technology and spend more time on controls and UI and load times and gameplay and AI and such. I try to not be quite so narcissistic and illogical as that, I've always tried to work on the stuff that I think is actually important even if it's not "sexy", but of course I do have to let myself work on some things that are fun even if they're not really the best use of my time. You can't just be doing the "right" thing all the time, it would be hell.
You can't sell load times - not to your boss, not to your publisher, and certainly not to the end user, judging by the abundance of games with really horrendous loads.
If you go really bad with it, one in ten reviewers will complain. If you make a stellar job, no one will notice.
Now, of course, I don't mean we shouldn't work on load times - just that it's half for ourselves, similar to the "code polishing", and half for the rest of the team during development, for faster iterations. But for the latter, live reloading of everything beats even the fastest loading times.
February 20, 2009 at 3:19 AM
Anonymous said...
Jon Blow put a lot of effort into the load time on Braid (and I put a smaller amount of time into it).
It's true that nobody commented on that, but I don't think it's necessarily true that it made no difference on the critical perception of it. We obviously can't actually determine whether it made any difference, but near-zero-load times could certain be one of many factors that lends the game an air of quality.
If you can't sell that to your boss, fuck your boss.
"We should work on load times, which, if accompanied with many other things, may lend the game an air of quality" vs. "We should try to fix as many of the 200 open bugs as humanly possible before release"? My boss is OK. Fuck the status quo in which shipping with bugs in the three digits is not only happening, it's virtually guaranteed for 99% of studios.
We spend a lot of time working on load times at Harmonix (also on making sure that the frame rate doesn't spike during loading).
To return to the original post, one of the things I like about pair programming (in moderation) is that it way reduces my sense of investment with my code and thus my defensiveness.
"We should try to fix as many of the 200 open bugs as humanly possible before release"? My boss is OK. Fuck the status quo in which shipping with bugs in the three digits is not only happening, it's virtually guaranteed for 99% of studios.
Well yes fixing bugs is a very important non-sexy thing to do ;)
Fallout 3 has fantastic load times, its almost instant, even on first starting the game. I guess they have a really well thought out streaming system. Which is suprising, as the rest of the engine (renderer etc) is quite bad in places.
February 20, 2009 at 9:26 AM
I think every good programmer is defensive about their code. It's like a good chef or any good artist, if you find
someone who doesn't care and doesn't stick up for themselves and doesn't get hurt by criticism - then they probably
just suck. Of course this is also a dangerous and negative trait to some extent, you don't want to create walls
around your code, you can be made much better with some outside help and pressure. (I've worked with people who would literally yell at you if you touched their code at all, and
I've also worked with people who *intentionally* obfuscated the hell out of their code so that nobody else would want
to touch it.)
I think I'm slightly more defensive than average. I'm happy to let people dig in my code, but it makese me let my
attachment to it go. I guess I'm the same way about cooking or anything, like if I'm doing it the way I love to do it,
and somebody else wants to do it some other way, okay, fine, do it your way, that's cool, but I no longer really care
about this food that we're making and I'm not going to be really passionately involved anymore. I detach.
I almost have a love affair with code that I have written for my own devices. Code that is uncluttered by all the ugly
practicalities of error checking and multiple platforms and compilers; code that is clean and pure and simple and elegant.
It makes me happy just to think about certain snippets, and sometimes I like to just go and "carress" them by changing a
variable name or slightly cleaning up things, it's just a little visit to let the code know I still care. If someone
else starts digging their dirty hands in my beautiful code, I feel like she has betrayed me. You slutty code, fooling
around with other programmers, fine, fuck you, I'm leaving you, I no longer care about you. I might still use you but
I will no longer tend and carress you, and over time you will get hacky and bloated and buggy and krufty because many
hands are in you and no one is refactoring you.
I was thinking this morning about two of the horror story bosses that I had long ago. They shall remain anonymous to
protect their privacy. At the time they drove me fucking batty insane, and I was too young and green to just quit or
yell at them, but now I find it very amusing actually.
The first one was at this little company in one of my first jobs. The boss man was actually super nice, I liked him,
but he was older and not really doing much coding any more, which was fine. The problem was he liked to hang out at the
office really late and night and drink beers in his office and talk to people on the phone and watch movies and such.
And he would go dig around the source code during these late night drunken office sessions. Often I would come in in the
morning and find a bunch of changes in the code that were just like "WTF !?". It really drove me nuts until I figured out
what was going on, and then after that I knew just to do a diff every morning when I got in and revert most of the changes
that happened in the night. (I was actually a pretty terrible coder then and was writing tons of bugs, so some of his
changes actually were fixes to my work).
The second was probably worse. You've surely had bosses who are "code style nazis" ; well I had a boss who was literally
on the IEEE committee for code formatting style standards. When I started working he gave me like a 20 page document on
how to format your code correctly, the number of tabs that should go here, how this should be aligned to that, etc. I
was like "umm, okay" , skimmed it and threw it in the bin. Little did I know he expected exact compliance to every single
rule on every line of code. He would review every check in that I made and send me lists of formatting errors. This was
not even like code style safety issues or "defensive programming" or anything like that, it was entirely about variable
naming conventions, number of tabs, spaces, etc. I quit after 3 months.
"02-19-09 - Of Code and Old Boss Stories"
9 Comments -
That sounds very recognizable. For me, in the end, it comes down to what makes programming fun for you, which is often not the same as what is most effective ("gets the job done"). You could give up your senseless "code polishing", but frankly, that would make programming from "fun" into "work", and you might as well choose a different career.
I have some bad habits that cause me to take longer to produce the same programs. For example, I abuse macros excessively, because I derive pleasure from "perfect factoring", even if it hurts readability. I violate "premature optimization is the root of all evil". I don't care. the feeling that my code is doing something retardedly slow reduces my enjoyment of working on that program, so it has to go. Illogical, but its the only way I want to be a programmer.
February 19, 2009 at 12:36 PM
Yeah, I realize now that a lot of my coding style is not really for efficiency (though I think it is efficienct) but also largely because it's simply the way that I enjoy. And that's reason enough for it.
Obviously that applies to what you choose to work on each day too. The fact is for 99% of game developers, they should stop working on fancy graphics technology and spend more time on controls and UI and load times and gameplay and AI and such. I try to not be quite so narcissistic and illogical as that, I've always tried to work on the stuff that I think is actually important even if it's not "sexy", but of course I do have to let myself work on some things that are fun even if they're not really the best use of my time. You can't just be doing the "right" thing all the time, it would be hell.
February 19, 2009 at 1:44 PM
You can't sell load times - not to your boss, not to your publisher, and certainly not to the end user, judging by the abundance of games with really horrendous loads.
If you go really bad with it, one in ten reviewers will complain. If you make a stellar job, no one will notice.
February 20, 2009 at 3:15 AM
Now, of course, I don't mean we shouldn't work on load times - just that it's half for ourselves, similar to the "code polishing", and half for the rest of the team during development, for faster iterations. But for the latter, live reloading of everything beats even the fastest loading times.
February 20, 2009 at 3:19 AM
Jon Blow put a lot of effort into the load time on Braid (and I put a smaller amount of time into it).
It's true that nobody commented on that, but I don't think it's necessarily true that it made no difference on the critical perception of it. We obviously can't actually determine whether it made any difference, but near-zero-load times could certain be one of many factors that lends the game an air of quality.
If you can't sell that to your boss, fuck your boss.
February 20, 2009 at 3:23 AM
"We should work on load times, which, if accompanied with many other things, may lend the game an air of quality" vs. "We should try to fix as many of the 200 open bugs as humanly possible before release"? My boss is OK. Fuck the status quo in which shipping with bugs in the three digits is not only happening, it's virtually guaranteed for 99% of studios.
February 20, 2009 at 3:28 AM
We spend a lot of time working on load times at Harmonix (also on making sure that the frame rate doesn't spike during loading).
To return to the original post, one of the things I like about pair programming (in moderation) is that it way reduces my sense of investment with my code and thus my defensiveness.
February 20, 2009 at 6:07 AM
"We should try to fix as many of the 200 open bugs as humanly possible before release"? My boss is OK. Fuck the status quo in which shipping with bugs in the three digits is not only happening, it's virtually guaranteed for 99% of studios.
Well yes fixing bugs is a very important non-sexy thing to do ;)
February 20, 2009 at 8:31 AM
Fallout 3 has fantastic load times, its almost instant, even on first starting the game. I guess they have a really well thought out streaming system. Which is suprising, as the rest of the engine (renderer etc) is quite bad in places.
February 20, 2009 at 9:26 AM