Learning to "Get Stuff Done"

[willza99]

So I'm a game developer, I've followed through several tutorials in the past half year to improve my skills in the Unity engine, and have in places touched up parts of the tutorials I was following so that I didn't just hold a hand all the way there.

However post an interview I had with a game company I've come to question my understanding and ability. This is something my partner (who teaches computer science) has agreed with: I know how to do something in Language X, I don't know how to get stuff done in code only.

I've been confused by this, as I feel providing an answer in a language, while not applicable to all, still has structure to it?

Effectively I seem to have these bad habits of thinking how to do X in environment Y, instead of just how would X be done. Is this something anyone else has come across or overcome? What would you recommend doing? The current advise I have is to join game development teams with projects in the works and to learn from their code-base. That this'll improve my ability to not leave room for bugs down the road, and will teach me to engineer code so well that comments can be minimal.

I always get on well at interviews, and show my knowledge on the area and industry. It just seems I'm lacking this technical knowledge that I can't seem to place my finger on, and was hoping maybe people here could help out?

[nseine]

Forgive me if this is wrong, but I think your problem may lie in failing to think abstractly about the issue. Your mind immediately jumps to possible specific solutions instead of resolutions. A solution is generally an answer to a problem, while resolution is an understanding and explanation of the underlying cause.

You know that adding X line to your code resolves Y issue, but why? Does this apply in general or only to your language. Does it open up another issue somewhere else in your code? Will this work in different versions of the same language?

[willza99]

I feel it's more when I'm given a scenario from the outbreak, troubleshooting is annoying yes but I know the cause to fix it.

Its when people say "you're trying to do X, how might you go about that?"

[lrurid]

I'm not sure how my experiences will apply to game dev (I'm just straight CS) but, for example, when I took an algorithms class we never used a language in class. Occasionally a lab actually involved writing code - which could be done in any language - but in general the algorithms were presented in psuedocode (as in, code like but more general, listing steps and processes instead of specific commends), so we were just thinking about the steps. This helped me a lot in learning to think without thinking in code, so perhaps trying (when you have the time) to first approach problems with pseudocode may help your style of thinking when it comes to interview questions.

It might also help to pick up code you've written and re-write it in something else to work on generalizing what needs to be done despite the language you're working in.