Michael TharringtonIn this series, we shine a spotlight 🔦 on the different DEV moderators — Trusted Members and Tag Mods — who help to make DEV a kind, helpful place. Aside from spreading good vibes and helping fellow community members, these folks also assist us with removing spam and keeping posts well organized by adding and removing tags as necessary amongst other things.
If you want to learn more about what these awesome folks do, I recommend checking out our Trusted Member and Tag Moderation guides. There is information about how to apply in both guides if you're interested in joining up as a moderator.
Introducing Phil Ashby 🙌
I'm pleased to feature Phil Ashby (@phlash) as our Mod of the Month for April. Phil has been a long-time DEV member and moderator; he's been a part of our community for longer than I have! And as a developer, he has decades of experience under his belt with a wide variety of interests and expertise — from game dev to building out an operating system from scratch. Along with being a skilled dev, Phil is thoughtful and funny, regularly chiming into conversations to help out new members or just to make us laugh. Thanks for the help, Phil!
The Interview
Michael Tharrington: How did ya first get started as a developer, when did it become a career, and how did that career lead you to where you are today?
Phil Ashby: Oh boy, how long have you got :)
The first computer I touched was a Commodore PET in maths lessons at school, age ~14 in 1979. Then at a 'gifted students weekend' (yeah, privilege, I know!) organised by the local council in the summer holiday we had open access to a PET, so my twin brother, myself and a few others spent the evenings writing a space invaders clone (in Commodore BASIC :), taking turns to hold the broken fuse holder in the back of the machine to keep the power on! At the same event we also got to play Colossal Cave Adventure on a Research Machines 380Z (a Z80 running CP/M).
By Sixth form (age 17+, college in US I think) we were helping run the lunchtime computer club with Sinclair ZX81s and teaching ourselves C programming on the clubs RM380Z in the store room.
Then at university ('85-'89) my electronics degree included ~30% software engineering, mostly using Sun Microsystems 3/50 machines (Motorola 68k running SunOS). I was fascinated by the 'proper' operating system and was taught some computer science (but not much) using C, Modula2, Ada (York Uni where I was studying were part of the Ada development group) and even Prolog. This was when I started acquiring books such as Maurice Bachs Design of the Unix Operating System, and Comer & Stevens TCP/IP Internals & Implementation... both still worth reading!
Straight out of Uni, my first job was almost entirely software development, with some natural language modeling thrown in - I worked on interactive speech systems, using voice recognition and dialogue design patterns to help create a telephone banking service (that would never get used by actual customers - ask me why!) and the UKs first voicemail system (CallMinder). This led to an interest in the embedded software doing the fun stuff in the voice cards, real-time operating systems (VxWorks in particular), and modems (related digital signal processing bits).
At home I now had a 386PC (yay!) and spent my evenings tinkering with device drivers for MS-DOS or playing video games, occasionally writing some graphics code and at one point my own kernel (see the post on dev.to about that one :).
Things continued in this vein for a few years (while my wife & I brought multiple children into the world!), then in 1995, almost out of nowhere, I was asked to join a team creating the UKs first online video gaming service, Wireplay - I guess word got out about my hobbies! There is also a post on dev.to covering that in detail.
Wireplay became Gameplay, a startup company, and I took a risk (aged 32, in 1999) to stay in rather than return to the large telco I'd been in for 10 years. Gameplay failed, however, I got experience of work outside a large org and rather liked some of it, especially the autonomy and the responsibility that comes with it, and even though the startup crashed, my career did not.
I joined a consultancy, which had been created by the large telco while I was away to retain their best people (by moving them outside the standard reward framework), taking on a variety of development and architecture roles both within the old org, and for new customers elsewhere. Some of the things I worked on in that period: autonomous self-healing network routers; mobile device games; an internet hosting service's customer self-care system (more fun than you might think!); Windows-based network content filtering device driver (stay away from this stuff!).
In 2007 the large telco made me an offer I couldn't refuse (financially) to join a team of experts (carefully hand-picked I later learned) working on risk mitigation around untrusted vendor equipment in the UKs core network. It turns out I was picked for my earlier VxWorks experience and general curiosity of all things computery, plus my electronics background was useful given the level to which we investigated things! More info about this was made public in 2019 here.
I have been interested in all things information security / assurance since, which turned out to be quite handy in my next role.
In 2013 a friend asked if I was interested in working for a smaller org again (yes I was) as they had an opening for their first official technical architect, job description: keep everything together while we scale out in multiple directions, acquiring other businesses, growing products, increasing supplier counts (x10 in one case!)... how could I resist :) I joined GBG when they had 4 offices, 320 people and everyone could meet annually in one room. It was nice, it also grew at quite a rate, reaching 40 offices around the globe, 1100 people and rotating all hands meetings in all those timezones. I started by discovering what they had, how it provided value and what the risks were (see above), fitting the ever-increasing portfolio of products and capabilities into an evolving enterprise, technology and business architecture that thankfully I was documenting as it evolved. By 2019 I was starting to feel like I was working in a large org again, the management had all changed (some of them coming from my old telco!) and the travel was starting to wear me out so I took stock of my finances and planned my retirement, in July 2020.
Almost four years later, I find myself working part-time again (to top up my income thanks to inflation / brexit and the increasing wealth gap still affecting my children), for another large org (WTW), filling a more limited architecture role, but with similar challenges of constant change, global technology needs, shifting suppliers, demanding customers... right now I'm 5 weeks in and busy absorbing new terminology every day, sifting out the patterns from the noise, finding the people who understand stuff and trying to help herd the cats into a common world view - fun!
Michael: What’s a particularly proud programming moment you remember? Cool to go macro with this one and talk about a project you really enjoyed working on, OR if you’d prefer to zoom in on something more specific like a difficult problem you solved or nifty bit of code you cooked up, that’d be cool too!
Phil: I'm going to go back a while for this one: to the online video gaming service. We had a goal to support as many games as we could on the platform, all of them MS-DOS applications of course, with proprietary communication protocols often operating over serial links (yes, modems again). However, a significant number of games used the Novell IPX network stack if it was installed… could we pretend to be IPX and get all these games working in one hit? Challenge accepted! :)
Luckily for us the IPX protocol and the MS-DOS API to the stack were well-documented, so I was able to write an emulator that resided in low memory, launching the desired game as a child process (not that MS-DOS really had that concept, but I could keep my code in memory!) and implementing the API according to the docs. Behind this facade the emulator used our existing communication stack (serial port + modem, or win/386 vxd + tcp/ip stack) to exchange packets across a wide area network, while faking a LAN between the players.
The proud moment came not when it worked (although that was cool, as it always is!), but when a visiting Novell engineer from the US, who was on site to meet a completely different group of people, sought me out to look at my code! Because nobody outside Novell had ever implemented the protocol side of the stack, and he was familiar with their codebase, he wanted to see how I had done things - declaring that my implementation was 'cleaner than ours'. :D
Michael: If your developer knowledge was wiped clean and you had to start fresh as a programmer, which programming language which you try to learn first and why? And after that, which would you learn next?
Phil: Unfair question! However, with that caveat: I would start again with a game scripting language, most likely Lua, as the immediate feedback (and dopamine hits!) would keep me going through the difficult bits, while I worked towards a concrete goal (I'm rarely inspired by abstract things!)
After that, with the basics of software engineering understood, I would move on to a wider use language, with a bigger ecosystem to employ, most likely Python. This would expose me to large system design / distributed systems and architectural challenges...
FYI I just came across the Standard Model of Languages (SMoL) project from Shriram Krishnamurthi at Brown University, which seems appropriate here and a really good idea (tm). Here's a link!
Michael: You’ve been a long-time member of DEV and seen us in many forms. Any tips or advice for new DEV members and/or any particular authors you’d recommend?
Phil: Definitely read / search for topics before you post something - lots of little fragmented repeats of conversations are not great - fewer, more commented threads provide more learning opportunities and you will discover more interesting people you can follow. If you do post and get comments: read them twice, stay calm and remember there are tools to help you manage unhelpful responses, you are not alone!
After that - use the hashtags, Luke! On a large and busy platform like DEV tags are a great way to group like-minded people together, increasing their signal-to-noise ratio. I would also recommend a regular dive into the tags page to see what's new / trending that you might have missed - look outside your bubble occasionally. :)
I really cannot point to any specific authors, although I follow a few - do keep an eye on the weekly round ups, as the DEV team try to ensure new and interesting authors and topics get visibility through this mechanism, outside the ranking algorithm of course.
Michael: I’ve seen you write on #gamedev a couple of times, do you have any advice for folks looking to learn about game development?
Phil: I'd like to address both the learning aspect and the career aspect of game development if I may...
Learning first:
Game development encompasses many of the same domains as enterprise or consumer software: having a well understood requirements process (games can do well here with the feedback gained in forums!); working with a development methodology that the team (maybe just you) agree on; releasing as often as possible to get good feedback; choosing technology (language, libraries, content formats, etc.) wisely; managing your time to get things done (beware of burnout especially in the gamedev world). This means you will get transferable skills whichever world you enter first, so it's not an either or decision to take up game development or other software, quite the opposite.
There are many forums dedicated to game development, some busier than others, some focused on early learners, others deeply technical, plus the #gamedev tag here of course. :) Definitely use these to engage with other game developers, discover where your curiosity / interests lie and validate your ideas. You will also find out which technologies are common / popular / complained about(!), which are used to deliver games rapidly, which may be required to achieve higher performance...
Follow developers you admire, especially those shipping regularly, particularly those that blog about their progress — we all share the same challenges! :)
As with most things in learning, work in small steps (smaller than you think!), reward finishing things and don't be afraid to repeat something if it didn't stick the first time - another good use of forums is to get a different view on the same thing, we all learn in different ways, try them! Game development is good for providing rewards (which is why I would choose it to start learning software development, see above), game jams and demoscene discussions can be excellent to see how other people view the same challenges, also great fun! Try finding that in enterprise development...
Now, the career bits:
See above regarding Wireplay/Gameplay - it's bumpy out there in a gamedev career, since lots of games are being created by smaller, less stable orgs. While huge studios can offer more stable income you may not get to do what you really want to and competition is high to get in. By all means go for it, but have a backup plan for if things don't work out! Actually, always have a backup plan whatever you do. :)
Long gone are the days when the software was the bulk of the work in creating a game, it's all about content now, with large open worlds, complex environments, extensive lighting schemes... that said, the demoscene still turns out amazing examples of software art that I get great joy from discovering; little nuggets of genius to balance the 20 person-years of artwork in Half-Life:Alyx (which is also amazing!)
Beware of egos getting in the way of clear thought - even your own. :) Also beware of get-rich-quick schemes, they usually aren't. Look for an organisation or group of people that focus on the players, where people are having fun — so you will too! — and with luck an income can follow.
Publishing on platforms like itch.io are a great way to get feedback (but see comments about comments earlier!) and to see if an idea is worth pursuing. Self-published mini-games are also a good way to scratch that gamedev itch when it isn't your day job too - I should push a couple myself actually!
Wrap up
Thanks so much for reading. We appreciate you taking the time to learn about another one of our amazing moderators. 💚
Stay tuned for future mod interviews in this series!
