Gettin Things Done

I went to a meeting for my university's local game dev group yesterday. The discussed topic was "What To Do Break Into The Game Industry." There were some helpful hints as to languages, networking events and the like, but one point that the speakers drove home (and I felt was VERY important) was this:

Make Games

It's so simple, but a lot of people, and not just those in the game development field, have a problem with it. Not just games, but all sorts of programs. In school, we usually just make some throwaway scripts that we use once for an assigment, and never look at again. Knowing how to do stuff is very important. Actually doing stuff, that's a whole nother level. If you go into an interview and say "I know how to do X,Y, and Z," they might be relatively impressed. However, if you can say "I did A, using X and Y, but I didn't get a chance to implement Z yet," that is umpteen times better than the first one. Companies don't care if you know how to do stuff. I know the basics of how to play baseball, that doesn't mean that the Phillies manager is going to be beating my door down trying to get me to join the team.

The problem with this is: making stuff can be tedious, and boring. For every cool bit, there are probably ten times that much of boring stuff that you have to slog through before you get there. It's hard to strike a balance, especially if you're like me and hate doing work in your free time. It's boring, but everything's boring if you do it enough. Try to add new stuff to the boring bits wherever possible, and you'll be okay.

Most importantly, though, do stuff, don't just learn stuff.

Randall Monroe Is A Wise Man

"When designing an interface, imagine that your program is all that stands between the user and hot, sweaty, tangled-bedsheets-fingertips-digging-into-the-back sex."

Yes, it's a little more than we'd actually want to think about our users, but replace the more graphic bit with "leaving work on-time", "playing with their children", or "having the information they need before the big meeting", and it does make a person realize an important fact. Unless you're making a game (and sometimes even if you are), your user could care less about your program. They want to interact with their data, or someone else's data, or data in the "cloud." Your program? They could take it or leave it, depending on the feature set, speed etc.

Your program will often actually be getting in the user's way.

Think about how much crap Microsoft took when they had Clippit, the annoying talking paperclip. Some people still make jokes about that goof, but when you think about it, it's a feature that kind of makes sense. An intelligent help section that assisted you with whatever task you were attempting to complete. Users don't like it when you meddle with them. They might be doing something horribly wrong, (or possibly just differently from how you'd do it) but don't meddle with them. They want to be left alone. If they want help, they'll find it.

That being said, I'm not trying to make a case against unobtrusive guides. If there is a somewhat confusing section of your program, it might make sense to include simple instructions on how to use it, or what type of input format is best, etc.

Remember, your users have better things to do. ;-P