About Oliver Smith Home Blog About

June 2014

Name:Oliver Smith Born:Germany, 1971
Nationality:British Living:California, USA
Occupation:Software Engineer Fields:C++, Linux, Game Servers,
Performance, Cross-Platform


I'm a self-taught software engineer. My first program left/read messages on a ZX81's cassette, had to wait 6 months to transfer it from my piece of paper to a ZX81. Taught myself SAS C to write a MUD language in '84. Left UK college (after the first year having gotten 100% on the mock exam) to work for a bespoke business systems company.

Discovered IP networking via KA9Q in '87 but had to wait 5 years for Demon Internet to pop into existence and provide me something to network with, at which point I became employee #13. Wore many, many hats there over 7 years: dumping bits of code on Alan Cox to squirrel into the Net/2 stack, Perl scripts that wound up running the .UK registry, end-to-end business automation for configuring routing/dns/you-name-it for dial-up and commercial customers.

Outside work I was one of those "we should hire that guy" types in game communities; heck I built community sites before that's what they were called. For WarBirds ('97) I built "warbirds.org" providing gamename@warbirds.org and guild-name email aliases; "Dark Age of Camelot Player Wishlist" (a bug/feature list with voting and nested comments); a house-layout editor for EverQuest 2...

Then, after thinking I'd breached a Source NDA I didn't have by revealing details of source code I'd never seen, Playnet decided they wanted me on-board. WWIIOL had been launched a year before and they were in Chapter 11. I started fixing stability, persistence and performance on the back-end, but I also started spinning out game management and reporting tools, anti-cheat systems, unit-tests, automation for builds/qa/deployment, performance tools, code generators. Basically: Many hats.

I stepped out of being a back-end team of 1 to joining WoW's server team, girlfriend move to Cali with me and we got engaged. Things at Bliz went well and things at Bliz went bad. They rectified the bad and tried to give me a do-over but - time to move on.

I'm not a front-end guy. My passion is empowering others. At Demon I built infrastructure tools and servers, at Playnet I empowered the client guys and the producers, reduced operational costs. My time working on bespoke systems tends to make me consider what people are trying to do as much as what they are asking for.

My specialty areas recently have been C++/Linux/cross-platform/performance, but I've also done much Perl, Lua, JavaScript, even a little C#.

Reliable Software

I'm particularly proud of the longevity and stability of some of the whole systems I've developed. One system ran for 20 years without maintenance, despite the warehouse being struck by lightning and later someone stealing the server. The virtual web-server system I rolled out at Demon ran for nearly 7 years before I got the first "the server has been restarted" email from it. I'd been gone for 4 years, but it was still running the original binary.

And, despite being down to only 3 full-time staff, none of whom are engineers, the Playnet servers continue to run WWII Online nearly four years after the last code changes were made to the branch they are in.


Early on, I taught myself to use bookmarked/referential memory. E.g. I know the functional ins and outs of 'select()'. As important as it is to the function of a program, it's something you rarely actually have to write as a developer. So, I choose not to remember the Perl-specific syntax, just that it has quirks. Should I need to write a Perl script using select, I'll "perldoc select" when I get to that line.

I tend to be a very practical learner; since I doubt I'm ever going to need to bust a ghost, I would never be able to memorize the number to call, but after moving to a new area, I've usually memorized the number for Pappa Johns by the 3rd pizza.

In development, I want to understand why someone is asking for a feature, I want to know what the code is for or what value a product is going to provide. The answers don't have to be complex or philosophical blockbusters. Knowing these things help you share a page with the customer/user/designer, aides in normalizing the descriptive language. It helps avoid code and feature bloat.

For example, at Granada Media, realizing requirements placed on a voting engine were artificial, I was able to replace a complex compute cluster solution with a CGI script little more than 'echo >vote.${parentPid}.${vote}' and achieve all the real goals of the project, get the solution stress tested and deployed, all in a little less than 2 hours.

Personal Life

When I step away from the computer I tend to be a fairly simple guy and enjoy the small things in life; I draw great pleasure from spending time with our pets. I come from a musical background, so I love all kinds of music. We also ate food, and I definitely inherited that, along with the genetic resistance to calories. Muahaha.

Science and sci-fi fascinate me, especially anything space related.

*1 I looked it up: Perl double-purposes 'select', with the equivalent to 'select(2) taking 4 arguments instead of 5 (no numfds)