I like to brag about my work, for the simple reason that I like, well, my work. But it usually results in people taking me for a much better programmer than I am. Then again, that might have something to do with the decent number of completed personal projects on my website: working software, complete tutorials, playable games... Although they are small stuff (after all, there are people out there who write operating systems for fun), they obviously count as accomplishments.

Now, if even such limited success seems to elude you, you may think people like me have some secret ingredient. But all I have is a number of common sense rules derived from (sometimes bitter) experience.

Be flexible!

I cannot stress this enough. In my professional experience, the vast majority of failed projects can be attributed to inflexible decision making. From clients insisting that minor, but fiddly features be implemented before launch regardless of any complications — thus causing extremely expensive delays — to senior programmers insisting that a coding convention be followed blindly, there are countless ways to stall, delay and postpone until everyone runs out of patience and money. At least when you're making the decisions, do yourself a favor and be flexible.

This goes double if you're making a complex project such as a game. Your dream design might turn out to be way beyond your abilities or resources, or simply to not be so good in practice. If you cling to the initial plan, you're only going to end up with no game and much frustration. Instead, go with the flow and remember your true goal, which is to create something fun.

Be patient

Rome wasn't built in a day, and it sure didn't spring into existence as a fully formed metropolis. It's the same with software. If you try to build it all at once, you're only going to run out of patience (and funding, where applicable) long before your dream product is ready to take on the world. Dreaming is easy; building is much harder. Learn to walk one step at a time.

As an example, suppose you want to launch a GameSpot clone. (Never mind the obvious question of why you would want to clone them instead of forging your own path). Do you try to achieve feature parity before launch? But GameSpot has been launched 15 years ago! That's how much of a head start they have. The original incarnation was a static website with eye-bleeding colors and a few newsflashes for content. Note, I'm not saying that would be acceptable nowadays. But you can start with a simple blog, maybe record a series of "let's play" videos, add a Flash game portal... When and if your site starts to be popular, it's easy enough to add a forum, make it into a social networking service or whatever. And if it never does become popular, (it happens) well, you've just spared yourself a ton of useless work.

Yes, the above example is based on a real story. They went the "hur hur, me clone GameSpot" route. It took at least two years, a complete rebranding midway, and possibly a complete rewrite of the code. More than a year after launch, it was still bleeding money. And the parent company wasn't the size of Microsoft, I assure you.

Code smartly

Reuse existing software

I know what you're going to ask. "If I don't write my own code, what am I going to bill my clients for?"

Um, for the fact that you can put together a software solution and they can't? Programming is just means to an end after all. Keep your objectives in mind, and rest assured that most visitors of the website (or players of the game) won't know what you used to build it, and the rest won't care as long as it's good. And it's much easier to make a good product if you're not reinventing the wheel time after time.

There is no one true way

Remember when people thought object-oriented programming was going to be the ultimate solution? Look how it turned out. Nowadays, Haskell fans say the same about functional programming. You'd think we've learned our lesson: programming is a ton of work anyway and fighting your tools is the last thing you need. So use a language that allows you to apply objects where it makes sense, and FP where it makes sense, but doesn't force you into either. Luckily, most popular programming languages nowadays are like that.

Similarly, relational databases (think SQL) are being grossly overused nowadays. But they do have their place. Use whatever makes most sense at any one point.

Code for clarity

Flame wars have been fought over coding style, but the truth is, it doesn't matter too much as long as the code is readable. Of course, some choices have consequences. If you write code like this: 

	this.step_right =
	function ()
	{
	
		if (this.player_x < 5)
		
			this.player_x += 1;
	
	}

you'll spend most of your time scrolling through your source files. Whereas if you code like this: 

	this.sr=function(){if(this.px<5)this.px+=1;}

you're going to need stronger diopters very soon. And in both cases, the workings of the code needs to be understandable without comments. In other words, don't do this: 

	this.player_x += 1; // Increment player_x.

You're just insulting the intelligence of whoever else is reading the code. Instead, explain to me why the code is doing whatever it's doing: 

	this.player_x += 1; // Step 1 meter to the right.

Better yet, turn the magic numbers into constants: 

	this.step_right = function () {
		if (this.player_x < RIGHT_EDGE_OF_PLAYFIELD)
			this.player_x += PLAYER_SIDE_STEP;
	}

Voila! No comments needed at all.

Anything else is a detail. Tabs versus spaces? Who cares, just pick one. CamelCase versus words_with_underscores? Both have advantages. Python versus Perl? Ahem... Let's not even go there.

Bottom line

These are some of the tricks that work for me. I'm not saying they will work for you, or that they'll mean automatic success (however you define it: completed projects, popularity, money...) But at least you'll be avoiding some big, nasty traps. And that's your best hope for getting somewhere.

Comments

Reuse existing software <<<

i've learnt that the hard way.

when i started using a good stable and powerful library it released me from working on stuff that wasn't my own program.

nande