|
I have worked for the past 4 years as a programmer and research assistant. It is my second major job out of college(CS degree). It was a good position at the time, but I grew frustrated at the slow pace and decided to enter the private sector. My question: what skills are academic programmers lacking compared to those that have been in the general workforce? I want to minimize any deficiencies while I search for new work. |
|||||||||
|
|
It isn't always fun. Sometimes it is, but not always. In academia, the measure of success is often the published paper, with just enough software behind it to be believable. In industry, the software has to work, when it's in the hands of from tens to thousands of brutal users who don't know or care how wonderful it is. They only want to get a job done, maybe or maybe not read the manual, and call you when they have any kind of problem. And if they needed it tomorrow, they would have called you tomorrow. Also in industry, you work with a team. They have different skills from you. The job doesn't get done unless you and they all pull together. Over the short haul and the long. If fact, that's where much of the satisfaction comes from. |
|||
|
|
One thing you will probably find is that commercial software work is results-oriented to a fault. Except for certain kinds of hardcore R&D roles that operate similarly to an academic environment, most commercial software work is all about delivering software, service and support to clients. "Proper" academically-correct process tends to take a back seat. I hope this doesn't sound condescending if you're already generally aware of it, but this is something that I think is the biggest general difference between typical commercial software work, and typical academic software work. Academic work is more about doing things correctly (theory translating into practice, extrinsic constraints be damned), while commercial work is more about just getting things done on budget and on time - even if you sometimes have to take horrible shortcuts. And indeed - most software companies entire methodologies are horrible shortcuts. Otherwise, BlackJack is correct - there are no particular "hard skills" that will be very different between the two environments overall. |
|||
|
|
|
I don't think there are any general skills that all "academic programmers" have because this is a profession where you can be a good programmer but have a very different skill set from other good programmers. Any programming job will require you to have good problem solving skills and the ability to pick up new languages/technologies. Beyond that, there are two broad "fields" where programmers can go into: tech companies and non-tech companies. Most non-tech companies hire IT people to either maintain their current systems or work on projects for the company. In these environments, the programmer is not the focus of the company but instead is more of a support role. They'll want you to have knowledge of whatever technologies they use, and to have the flexibility to work on different projects depending on what's going on. On the other hand, programmers are the bread and butter of most tech companies. They're looking for people who know their technology stack or are willing to learn, and for people who are good programmers. Oftentimes, tech company interviews involve brain teaser or programming challenges that involve concepts like recursion, dynamic programming, etc. It's generally understood that you have to be an above average coder to work at a good tech company. So in the end, there are no specific "skills" per se. Someone who's been coding in Java for 10 years and nothing else will certainly be lacking in Ruby on Rails "skills," but that doesn't make him or her a deficient programmer. To get a good job, you need to make sure you're a competent coder, a good problem solver, and someone who can learn new things at a quick pace. |
|||
|
|
