Transition from College to Career

Hi Brian. I'm not sure how well I'll be able to answer your question, but having left university about three years ago to join the games industry, I can at least remember pretty well what the transition is like.

Clearly as a software developer, you will need a basic level of programming skill, and of course I'm in no position to judge you on that. That said, the application process itself should give you a good sense of your readiness programming wise. Most companies will require code samples or set programming challenges before or during interview, and the entire purpose of these is to weed out candidates without the requisite programming knowledge, so if you get past these hurdles, I think you can feel confident that you're in the right league. If you do struggle with those tests, it's also probably fairly easy to rectify, as there are plenty of resources available online and in print to help you.

That said, from what you've said about yourself, I don't imagine the programming itself is likely to be the issue, given that you're already doing well in your programming courses at uni. I think the biggest shock for me leaving education and independent development behind to join a large studio was the shift in mindset required. I noticed this in a couple of areas.

First, I've on several occasions made mistakes in my work because my experience as a solo developer taught me a set of "best practises" which didn't apply when working with a team. To give an example of this, when working on a solo project, I'm a big believer in letting the game crash when there's a bug. As such, I make liberal use of asserts, and expect those asserts to crash the game. I rarely bounds check arrays or null check pointers, because I actively want the game to crash if there is a usage error so that I can quickly discover and fix the problem. Working in a large team, this doesn't apply. If you introduce a crash, that could interfere with the work of the entire rest of the team (which could be hundreds of people) as they are forced to role back their version of the game or wait for a fix. As such, the "best practise" I had developed working solo actively worked against me in a studio environment.

Second, my experience of programming in an academic and/or student setting was that there was a awful lot of talk about "code quality", and a lot of funny ideas about what is "right" and "wrong". As I hope the example above has illustrated, the reality is very rarely that clear cut. The right and wrong solutions are dependent upon so many factors, including of course time constraints. There are numerous times when I've come across horrible bits of code, and have caught myself thinking "idiots! who wrote this?!", before realising that the code is not as it is because the author was an idiot, but rather because of some other factors or considerations that I wasn't aware of. Learning to shake off my fixed ideas about good and bad code, and to approach unfamiliar code with an eye to understanding why it is as it is, has been area area I've had to work hard to develop.

Without knowing you personally, I can't know how much of this is relevant to you, or whether these ideas are all familiar to you already. However to finally get around to answering your question about how to smooth the transition, I think the step you've already taken of engaging with this community is a great place to start. Whilst I feel there is a tendency around here to perhaps pass judgement on code/software a little too quickly, nonetheless, I think one of the great strengths of this community it its emphasis on achieving a real and deep understanding of programming based on evidence and logic, rather than by following inflexible rules that invariable work as badly in some situations as they work well in others.

I hope some of that is useful, and if you have any follow up questions, or just think I totally missed the point, please let me know!