Archive for December, 2005

Moorgard has a blog. I just discovered it after checking up on Aggro Me and his latest thoughts on the announced changes to Everquest II. I thought it was neat when I checked the dates on his first posts, and they read 12/16/2005. Very cool.

If you don’t know who Moorgard is, let me explain: he’s a developer for Everquest II, the MMORPG that currently consumes my computer time at home. Moorgard was the Community Relations Manager for EQ2 for the first couple of years, and now he’s moved up the chain to do real work in game design (something that was a dream of mine as an undergraduate CS student).

I’ve always admired the job Moorgard did as Community Relations Manager. It was his job to talk to the gaming community, interact with them, gather their opinions, disseminate information, and try – somehow – to keep the peace. He had a job that I classify as the Kobayashi Maru of game design jobs, meaning: the No-Win Scenario. There’s simply no way anything he could ever say would please the community as a whole. There are too many whiners, bitchers and complainers. But he did his job professionally and with restraint. He did his best to explain to people what the developers were doing, what they had in mind, why changes were made, and what direction they were trying to go in. He did it through all the flames and beratings.

It will be neat to see how his blog turns out.

Meanwhile, I Agree With Aggro

Scott Hartsman’s Producer’s Letter for December spelled out some really great changes for Everquest II, namely a really solid PvP framework and an overhaul of the way class selection is handled for levels 1-20. Personally, I love the changes and applaud them. The class changes seem really good to me, and every reason for them is covered in Aggro’s post. Same goes for the PvP stuff. Aggro covered the reasons well. I totally agree with him.

It’s a promising time to be an Everquest 2 subscriber.

The past couple of days, Dooce’s hubby (John) has been blogging about their inability to get health care coverage now that they are both self employed. They were denied again. The premiums they’re going to have to pay on a “state plan” make you think that burying money in the backyard might be a more effective health care plan.

The really intersting part is reading the comments from the folks who live in other countries, like Canada, where health coverage is paid for by the government, and everyone is assured coverage. They simply can’t believe the US operates like this. Frankly, neither can I.

Best quote from John’s posts:

Here’s the freedom and peace of mind I think every person deserves: if one is sick or has a health-related problem, one finds the nearest or most favorite physician and makes an appointment or walks in and gets help. Every person alive deserves this. That we don’t live this way is hypocritical and inexcusable. We have the technology.

Couldn’t agree more.

There’s been a pretty neat discussion on Paul Gielen’s blog about refactoring, which drew the attention of Frans Bouma, the brains behind LLBLGenPro (an O/R Mapper that we use and love here at NPC). Frans’s comments are pretty interesting; he doesn’t seem to ‘get’ Agile development, and if you read between the lines it seems pretty clear that a large reason for this is because Frans has come at Agile from a really oblique angle.

I started thinking about that and it makes sense; Agile is new. So new that colleges aren’t teaching it as a design methodology. Even my own alma mater, The University of Idaho, is still teaching it’s CS381 and CS382 design courses using waterfall.

That fact made me realize two things: (1) Agile Development is a really big subject – much bigger than can be fitted into a blog post or a feedback form, and (2) when you’re dealing with something that big, there needs to be an entry point so that people can come into the builiding through a common doorway.

Frans has snuck in the back door, and now he’s in a huge building with a giant party going on, and none of it makes any sense to him. Well, it’s because he didn’t enter through the front door. He didn’t receive the orientation package that everyone else did. He missed out on the information packet. And I’m sure, due to the proliferation of the blogosphere, he won’t be the only one introduced to Agile this way.

So let’s do folks a favor right here and now, and point them to the door :)

If you’re new to Agile – if you’ve ever heard of it – then some of the design philosophies you discover piecemeal on the web might not make a whole lot of sense, and in fact might seem rather absurd! Do yourself a favor and enter this party through the front door.

And that front door is Kent Beck. He’s one of the godfather’s of this party, and his books will really help you get a hold on this new paradigm called Agile Development. Now, I know what you’re thinking; “God, I’ve got to read a book?” Hey, they’re easy reads. I got through each of them in a day. Kent does a great job of getting to the point, and not wasting a lot of time. There’s some repitition in there, but it helps to drive home the major points. This is a major paradigm shift for a lot of people, and paradigm shifts are hard. It pays to get drilled.

The best place to start is probaby Extreme Programming Explained. From there you can move to Extreme Programming Applied and then Test Driven Development.

Without a good entry point, Agile is going to seem like directionless hacking. With a good entry point, you’ll see the focused, disciplined style of development that Agile really is, and you’ll begin to understand how these new methodologies can produce better code, and higher business value to the customer.

Get ‘em now. Don’t wait!

I just now found out (courtesy of edjez’s blog) that MS finally pulled their TDD article from MSDN. I don’t know what’s funnier: that Microsoft got slapped by the bloggers when they published bad advice for Test-Driven Development, or the message on the webpage when they took that advice offline:

This topic is obsolete and has been removed from the MSDN documentation.

Obsolete. That’s too funny. About the only thing obsolete there is Microsoft’s relevence to the whole TDD paradigm. Scott Bellware has an awesome writeup about how MS screwed the pooch, and what TDD really should be. I love these snippits:

TDD is a software design methodology. It’s not a software testing methodology.

And then later:

Testing is a side effect. Design is the goal of TDD, design for testability flows naturally from there, followed by de-coupling, and reusability. TDD is the king of contemporary software design practices. It delivers on every major measure of software development goodness.

Scott gets it. Now, how long before Microsoft does?

This week we concluded interviews for our Network Administrator position, and as promised I’ve compiled this small list of mistakes. The things people do at job interviews can be truly amazing… Without further delay:

Don’t Burn Bridges

This one surprises me, but people still do it. They don’t get the job, so they say something spiteful or vindictive as a parting shot. Stupid move. You could have been #2 on our list – we may actually call you in the future because we liked you so much in the interview. We might call you down the road and say, “Hey, a new position opened up and we remembered you, and wanted to know if you’re interested in joining our team.” But no, you have to get that final shot in, thus blowing any chance of us ever wanting to hire you. And you know what’s worse? We’re going to tell anyone who asks us that you’re an ass. So not only did you just screw yourself for any future employment with us, you might have just screwed yourself for your next job interview as well. The world is a small place. You can never be sure who someone might know.

Word to the wise: if you don’t get the job, accept it gracefully and then let us know you really wanted to work here. We might think of you next time something opens up. Don’t be an ass.

Don’t Try And Spin Answers

I hate spin. I mean, I really hate it. It’s a pet peeve of mine. If we ask you what you think your biggest weakness is, it’s because we honestly want to know. We’re looking for people who can be honest with themselves, and honest with us. If you can’t be honest, then we know you’ll try and cover your ass when something goes wrong, and we’re not interested in that type of employee or teammate. Honesty – at all times. It’s paramount. Don’t try and spin your weakness to look like a strength. Don’t say, “Well, my coworkers say I work too hard.” Screw that – you’re spinning, and you’re not really giving us a weakness. This isn’t the Spin Room after a Presidential Debate. This is a job interview.

Don’t Evade Questions, Even If You Don’t Like Them

You know that weakness question I just mentioned? Don’t give me crap like, “Well, I can’t really think of anything offhand.” Balony. Don’t evade the question. Don’t sidestep. Answer the freaking question, and answer it directly. Same thing with any other question we’re asking you – don’t evade, even if it seems difficult or uncomfortable to answer. Guess what? We’re interviewing you, and we might actually be trying to fluster you on purpose to see how you handle an uncomfortable situation. So dive in, head first, and work it out. Evasion is a sure-fire way to eliminate any interest we have in hiring you.

Be Specific When Answering Questions

One of the things we’re trying to determine in an interview is how knowledgable you are. Don’t fear that you might be talking over our heads – we want smart people. If you can’t answer in specifics, with details, then we’re going to think you lack the knowledge to do the job. Really generic answers don’t help us, and they hurt you. Be specific. This is the single-biggest problem I saw with most of the people we interviewed. They simply couldn’t be specific.

Take Deep Breaths – Don’t Be Nervous

Your nerves aren’t going to lose you the interview. This point is more for your benefit. Hey, we’ve all interviewed for jobs, and we know it’s stressful. But do your best to relax and take your time. Go slow, think things through, articulate your thoughts, and for heaven’s sake breath. If you relax a bit more, and just be yourself, it won’t seem nearly as stressful. Remember, if you get the job you’re going to be working with us every day. So think about us as your team members already.

Don’t Rush It – Sell Us

Also remember that this is your time to sell us on you. You are your own best infomercial. So don’t rush it. Make sure you get everything across that you think is important. We’re open-minded people. The whole reason we’re interviewing you is because we think you could actually be the right person. If we didn’t think you had a shot in hell of doing the job, we wouldn’t have interviewed you. So sell us. Make it so that only an idiot wouldn’t hire you.

Do Research On Your Potential Employer

Check the website, see who we are and what we do. Ask colleagues if they know about us, or what we do. Get a picture in your head before you come to the interview, because we are probably going to quizz you just to see if you’ve done your homework. After all, we don’t want to hire someone who just wants to pickup a paycheck – we want to hire people who are enthusiastic about what we’re doing. If you don’t know what we’re doing, how can you be excited about it? And if you can’t find that information in trade journals, the website, or other sources of information then call us before the interview and ask (preferably ask us during the phone interviews). It show us that you are interested in our company and our team. Take interest in us, and we’ll take a lot of interest in you.

Show Us Your Passion

As I said in the first post, you can’t fake enthusiasm. But if you have it, don’t hide it. Passion, enthusiasm, and genuine excitement for your field of expertise can do more to sell us than 100 pages of resume qualifications. We want enthusiastic people who are excited to come to work every day. We work hard to make our work environment fun, friendly, and productive. We’re not going to hire a curmugeon. Show us your passion – be excited! Don’t be afraid to be animated when describing things to us.