Sponsored By
James Steele, Blogger

January 13, 2012

3 Min Read

For a just over one and a half years, I've been working as a Software Engineer in a support capacity for my employer.  My job, is to support game developers on our hardware platforms.  Now, before my current job I was an actual game developer for almost 12 years, and my boss felt that this experience would make me a valuable asset to the company.

While I can't go into day-to-day details of what I do; I do want to write a little about one of the things that has come to light as I've adjusted from a pure development background, to a support role.


Letting go.  It's probably the first lesson that I should learned 19 or so months ago.  There has to be a point where you let go of a support request, as you're not the guy who's writing the code.  You're not ultimately responsible for them hitting their schedule milestones.  They are.

Sure, there are cases where you will be writing code or looking at a test case they've prepared for you. So then, you can investigate what they're doing and help them find the cause and solution.  However, these cases are rare.  I don't often send fixed code with a note saying "Fixed it for you. Should work like a charm now".

Mostly my job is to advise developers.  I'm there to ensure that they have the correct information and tools at hand, so they can get the job done.  


But this is a difficult thing to do, especially after spending so much of my career "in the trenches" and being one of those guys who is responsible for writing code on time and to the spec.  So when I receive a support request, all to often, my first instinct is to act as if it's ultimately my responsibility to get the code finished. Because that's what software engineers do; we solve problems by writing code.

But this is no longer how I solve problems.  And in fact, I really don't solve any problems,  My job, is to help the guys writing the code, solve the problems on their own. 

It's a hard thing to adjust to, esepcially when you're still very passionate about game development.  And of course, it goes without saying; my company wants developers to succeed on our platforms, and so do I.  So natualy, I'm very enthusiastic about playing a part in making that goal a reality.

There are other aspects to this adjustment process, and learning to let go.  There are times when developers will state that they have no interest in using platform-specific features to achieve something (typically better performance).  And this is usually because the guys above them, have set out a schedule that doesn't allow the time for them to use these features. 

My first reaction is...well...dissapointment and perhaps a little anger.  I find myself asking "How can anybody think like that?  If it makes the game perform better, surely you want to invest that time!" or something along those lines, and usually with added expletives. Because I'm passionate about game development, and obviously, passionate about my companys hardware, my view is "use these features. They're cool and will help make your game great!"

The harsh reality is that I don't know everything that is happening with a particular developer. And while my job is to make as great a case as possible for using any cool hardware features to achieve something on our platforms; it's ultimately up to the developer.  I can't force them.  And I shouldn't take it too personaly...if they choose not to follow my advice, then that doesn't mean I've failed.  It could just mean that their concerns outweight everything else.

In short; there's a point where I just have to let go. And it's not easy.

Read more about:

2012Featured Blogs

About the Author(s)

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like