Hacker Newsnew | past | comments | ask | show | jobs | submit | aowen's commentslogin

I do! I'm a server software engineer at a video game company. Here are some highlights:

- I get to work on a game that I enjoy playing. I've worked on some games that I didn't care for (or I was not the target audience), and it's still fun work, but when you genuinely like the game, and play it in your free time, ah! It's such a joy.

- At my current company, I'm working with some of the most skilled people I've ever met. To be surrounded by awesome people is inspiring. Just by being themselves, they push me to be a better engineer, because I want to be able to stand alongside them and call them colleagues.

- I'm paid well! I'm certainly not in the FAANG salary range, but to be honest, I'm making more than nearly everyone I know outside of work. I count myself extraordinarily lucky, my salary is certainly outside the norm for my age group.

- In terms of the work itself: I enjoy problem solving and helping people out. I get to do a little bit of both every day. Those are the day-to-day fulfillments that I really appreciate.


Do you mind me asking how you got into server software engineering for a video game? Also, how is the work-life balance. I feel like I shy away from game dev because of the horror stories, but working on backend servers for an online multiplayer game sounds like a fun challenge.


> Do you mind me asking how you got into server software engineering for a video game?

Honestly, it was just chance. My first job out of university was at a smaller studio, and they needed a junior to help out on the backend. That being said..."be lucky" isn't very useful.

Some more useful info: there are a few different things one can do on the backend of a multiplayer game. There's the core game replication logic, there's web server/matchmaking/database work, or just infrastructure management type of work.

I think core game server work is the most specialized. For an authoritative server, it's the kind of work where you write the game server's simulation of the game and replicate it to all the clients. Games can also be peer-to-peer, but I don't have any experience in that area. The people I know who excel in this area have strong math and computer network skills. A book like "Multiplayer Game Programming: Architecting Networked Games" is an example of problems in this space.

Web server application work is what I do. Includes work like writing matchmaking services, authn & authz, robust purchasing flows (both in game and real money transactions), retrieving/storing database state. I think someone could break into video games if they have previous experience doing web server development, even if they haven't necessarily solved the same types of problems. I've worked with people who had web server experience outside of games.

Infrastructure work is exactly that. Involves the usual sort of work like IaC, CI/CD, cloud providers like AWS, Azure, GCP. Sometimes they're called dev ops engineers.

> how is the work-life balance.

It really depends on the company & the team. The places I've worked highly value work life balance and reject crunch culture. There have been some late nights to solve an outage or hit a deadline, but those have been far and few between.

I think probing about it at the interview stage and reading reviews about the company on sites like glassdoor are the best way to avoid the hellscapes.


Depending on engine it's mostly YAML hell unless you work with Unreal and get tricked into building custom netdrivers... then it's PF_RING hell instead.


Ugh, I was not happy reading the email this morning. At least you can say they're being transparent with the FAQ, 'yeah, this will increase your bill'.

We already had logging disabled, but changing the default behavior in their favor is shady.

New Relic is already one of the most expensive items in our budget. Last year, I had to tell a producer "yeah, our SaaS that monitors our servers is more expensive than the servers themselves". That changed this year (started ramping up for scale), but it's still in the among the top of services we pay for.


Agree, I figure this is a significant factor.

An anecdote from my studio: My studio is work for hire with mostly Unity devs. The "big ticket" contracts are in Unreal, so the studio is starting to push for devs to learn Unreal, so we can start landing those contracts. In this case, the publisher perception of Unity/Unreal is creating a business need in our company to move away from Unity and into Unreal.


100% I have seen the same thing. Big publicly traded publisher. If your pitch has "Unity" in it their interest sinks.


Yikes! That'd drive me crazy.

I'm reminded of the YAGNI ("you aren't gonna need it") principle. Sounds like your coworker could apply it more.


I used C#'s async/await on a project in 2017, and I took to it. I appreciated being able to follow the "relevant" parts of a method, without having to jump around to different callbacks. That being said, I think I was the only one on the project that understood it _well_. Over the course of two years, I learned lots of the same gotchas.

Avoid "async void" was one of the catchy mnemonics I learned the hard way, because one day our production server crashed because it threw an exception in an async void.

I'm working on Java web services now, and it's written using synchronous Java servlet framework (Spring/Jetty). My hidden fear is that one day we'll discover that our synchronous APIs will have to be completely re-written in the async model.


You won't need to rewrite into async model, because project Loom will introduce virtual threads. That means your sync code will look exactly the same, but will have scalability of async.


Given that you understand it well -- do you know why the compiler accepts async void in the first place?


I think it made sense for UI integrations. From a synchronous OnClick delegate you could start an async void function - which essentially starts a background task that lives even after the click handler returns. Returning a Task here would not have made sense since nothing awaits it. But arguably the use-case could also have been fulfilled by calling `Task.Run` in the handler to spawn a background task.


Without knowing what the underlying method does, the async method may block the UI thread because until the first await which doesn't immediately continue it runs on the UI thread.


I think it was for backwards compatibility with event handlers (which need to return void)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: