;)
james.rambleOn(true);
Seven Years Later April 2, 2013 10:17pm
I just realized how much my coding has changed over the past seven years. I was writing some code for a new app, when I remembered I'd done pretty much the exact same thing for an old project back in 2006. I dug up the old code, but since I'm lazy I only copied the core functionality, not the fifty or sixty lines of support code that was also required. Earning the gold medal for laziness, I refused to dig up that old code again and just rewrote it. This time around it only took me three lines. To do the exact, same thing.
The Job June 26, 2012 5:58am
First off let me just say that I get a lot of interview requests every day, so I want to apologize to anyone I am unable to get back to. I realize the trend these days is to be "agile," but every time I see a posting with the terms "agile development" and "extreme programming" I tend to have a giggle and move on. For the uninitiated, in the really real world agile development and extreme programming mean they don't have specs, project managers, a realistic roadmap, comprehension of time, sense of direction, they have super short release cycles, a perpetually high burn rate, or all the above. This would all be fine, if only the company in question at least adhered to a process like Scrum. Unfortunately, most tend to adopt only the parts of Agile they like, while leaving out the checks and balances.

When I was with Nokia I was a scrum master and strictly enforced the complete Agile process. We got a lot of work done in a fairly short amount of time, but as the changes piled on work constantly came to a halt. As with every other agile company I've been with, that was when they broke the process. We kept the weekly releases, the stand-ups, the high pace, and the fluid spec, but we were no longer sprinting. We stopped freezing and resetting sprints when the changes rolled in. Instead we were still expected to meet the weekly releases, which of course was impossible.

It was then that some of us decided to switch to Waterfall. We sat with the product managers and business and defined a clear spec. We said goodbye to the meaningless incremental releases and instead set a fairly short two month deadline. In just under two months we were code complete and ready to ship version 1.0 of our product. Then along came the pm's with a laundry list of changes. As you may have noticed, I said I "was" with Nokia.
Let's Goto! December 14, 2011 6:09am
I've written code for a lot of companies. At last count it was well over thirty. Believe it or not, only a few of those companies used and enforced formal coding standards and best practices. Of those, all are now defunct. The point? A standard does not make a good product.

The curious thing is that at every single one of these companies there was at least one developer, usually some young buck fresh out of college, with genuine nerd rage over the code base or some other developer's code. All the seasoned devs - and that doesn't mean old so much as very experienced - would joke around about it, but weren't all that concerned. That's because a good coder is more interested in the content than the appearance. If the code works, and works well, I couldn't care less if all the equal signs line up. Readability is all well and good, but I'd much rather a developer was thinking about the algorithm than where to put a curly brace. Subjectivity has no place in code. Which brings me to the best practices portion of the phrase.

Let's analyze the term for a second: best practices. By definition, a "best" practice is subjective. In programming there's usually more than ten ways to do something. Which one is "best" depends on the context, therefore there can be no true best practice. To rule in advance that a particular way of handling a given problem is the only acceptable method can severely hinder future solutions.

Let's use my favorite example, our friend the goto statement. Easily the most hated artifact in the programming world. But why? Many will tell you because it causes spaghetti code. I would argue that it is the developer who cooked those noodles. Besides, millions of lines of spaghetti code is written on a daily basis using seemingly best practices of object oriented programming. Goto, like OOP, has its purpose, and also like OOP, can be easily abused. To blacklist any given statement, function, or design pattern in coding is akin to stripping a carpenter of his hammer for fear he might break something.
Programming Is Easy December 2, 2011 3:38pm
People are always telling me I must be really smart when they hear I'm a coder. I always tell them, "Not really. Any idiot can be a programmer." And it's true. All it takes is basic problem solving skills and memorizing some syntax. I was coding when I was seven years old, and I was smart for my age, but definitely not smarter than my non-coding parents.

So yes, programming is easy. Programming well, on the other hand, not so much. I know a lot of coders, but I can count the good ones on one hand. No joke. The joke is that some of the worst coders I know are the most educated ones. The ones who have a bachelor's or master's degree in computer science, yet somehow tank the entire codebase with a single check-in (often with some pompous commit message explaining how they fixed someone else's poorly designed code).

To be fair, the highest percentage of bad coders I've known were street coders. You know, that guy who read a book on PHP (cover to cover) and now he thinks he's a programmer. Or that nimrod who scored a copy of Dreamweaver on a warez disc and made his first "kick ass" website so he must be a programmer. Sorry to bust your bubble, but no matter what wikipedia told you, you're not a programmer until you ship your first app. Until you can look at some code you wrote five minutes ago and know exactly why it's crap. Until the amount of programming knowledge your wife has acquired through osmosis qualifies her as a junior developer. Until you've had to go back to the toilet to finish wiping because you got an epiphany on the commode but forgot to take the laptop with you. Oh what, like that never happened to you?
It's Not That Hard After All November 9, 2011 3:31pm
That's what she said? Ahem, right, so I'm back to work on porting Show & Spell via S3D plugin and things are going pretty smoothly. I've got most of the utility functionality working and just need to add the core behavior and state logic. After that I can add all the resources to the project and tie it all together with the Lua triggers and we're good to go. I was dreading this for a while, but somehow it's not too bad. Maybe it's just the simplicity of the project or maybe I suck a little less this year, who knows. Either way, I'll take it. I've got at least three more games on the drawing board, and if I don't know my stuff I do know they'll be the death of me.

I was thinking about doing a quick app with the C4 engine, but I highly doubt that's going to happen any time soon. At this point I don't have time to experiment on mere hobby apps. If I'm sitting in front of a keyboard instead of changing diapers or feeding kids I need to have a good reason. Somehow, "I'm learning a new framework," doesn't seem like something that's going to keep the Mrs. from putting a fist in my face.