Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
A lot of students when they graduate and get their first job, feel like they don't really know how to program even though they may have been good programmers in college.
What are some of the differences between programming in an academic setting and programming in the 'real world'?
In a traditional undergraduate computer science program you learn just programming. But the real world doesn't want people who are just programmers. The real world wants real software engineers. I know many job descriptions don't seem to express this distinction, which only confuses the matter. In the real world you need to be able to:
Oh yeah, and you also have to be able to write code too, though that takes, on average, only 40 - 60% of a software engineer's time.
So, it's not that freshly minted computer science undergrads don't know how to program (many are in fact, very good programmers). It's that many of them don't know how to do anything else.
Oh yeah, and you also have to be able to write code too, but that's, on average, only 40 - 60% of a software engineer's time. - Or even 0-20% at really bad and really large corporate shops.
Nov 13, 2011 at 21:56
Your teacher gives you:
Programming in school and programming in the real world are so inherently different to the point where there's actually very little overlap. CS will prepare you for "real world" software development like athletics training would prepare an army for battle.
They face a different aspect of the problem:
Academia is mainly focused on the "science of programming" thus studying the way to make efficient particular algorithm or developing languages tailored to make certain paradigms more expressive. Industry is mainly focused in producing things that have to be sold. It has to rely on "tools" that are not only the languages and the algorithms, but also the libraries, the frameworks etc.
This difference in "focus" is what makes a academic master in C practically unable to write a windows application (since we windows API are not in the C99 standard!), thus feeling as it is "unable to program". But, in fact, he has all the capabilities to learn itself what he's missing. Something that -without proper academic studies (not necessarily made in Academia)- is quite hard to find.
Good answers. Let me just add, academic programming tends to be almost toy-like in scale. This is good for teaching. As a teacher, you are trying to convey ideas most efficiently. The downside is realistic programming is so qualitatively different, it's hard to bridge the gap.
One area of difference is in performance analysis. I've written many posts trying to point this out. Performance analysis is only superficially about algorithms and measuring. To do it really effectively, you have to approach it as a process of debugging.
Another area of difference is maintainability. This encompasses everything from style to domain-specific language design. You can't do it effectively unless you actually know what you're trying to minimize.
These things are not taught, and they make an enormous difference in productivity.
In the academic world, most people study computer science or related courses. Dijkstra once observed that "Computer science is no more about computers than astronomy is about telescopes." A person studying computer science is first and foremost learning to become a scientist, and not a programmer. As a programmer, he'll stay an amateur, and the transition to a professional programmer is accordingly hard.
Update: As if someone was reading my mind: Graduate expectations versus reality...
My take, two other factors:
Problem size: In academia, I mostly had to develop software "from scratch", which meant that most of the time, the largest program I had encountered was the largest one I wrote. This de-emphasises the necessary capability to handle and cope with complexity that emerges from different pieces of software interacting together. If I was aware of the effort needed to comprehend with complexity, I might have chosen not to be in the industry at all.
Reading VS Writing: Another side effect of problem size is that often, in the "real world" we are exposed to work that has been written by others, either for maintenance purposes (I did no maintenance in academia anywhere), extension, or simply division of labour. Therefore reading code becomes many times more important than writing it.
A proposal for improved programming education: Academia should expose us more to real-world situations without regressing to vocational training. Doctors have to face a corpse at some point to see if they are "made for it" (I've heard stories of people dropping the course after this experience). If I had seen in my early twenties a 20K LOC project comprised of different programming styles, which I had to understand in one day and amend a bug in three, I might have considered other career options -- though probably not.
The biggest difference I have found between academic vs industrial programming is regarding robustness. Most everyone has experienced the "it works for me" paradox in their career, and this is an extension of this condition. In academia, the focus is on the algorithms and functions and little regard is placed on the usability and stability of the software under everyday conditions.
For example, at my office we have an engineer that will take the software and is a master at causing crashes from corner conditions. He will click on a button as fast as he can until something crashes...if an operation takes too long, he will just start clicking randomly around the screen (out of frustration? IDK....)
Changing our programming philosophies so that we make things "Steve proof" has in general improved the stability of our application.
I have zero personal experience with programming training in school--I was an English major. Ask me about Keats and Byron!--but I have received several new grads and brought them up and mentored them in the world of professional software development. So I can speak from that perspective.
My experience is that really ALL they got from their schooling was an interest in programming. Their skills varied from zero to negligible. Their ability to self-direct was nonexistent even in the highest-skilled of them. Their thinking wasn't just small-scale; they actually thought in miniature. A system comprising more than a couple dozen lines of code made them fall entirely to pieces.
But you know what? They acquired an interest, and that's a big deal. An interest is plenty. I can work with someone who's interested. I can turn them into a developer, provided they come to me with an interest in being one. Hell, that's all I started with. That and an appreciation for post-modern American novelists.
In academia,
DRAWBACKS
PLUSes
In the industry,
Check this out:
http://www.dodgycoder.net/2011/10/how-to-become-better-programmer.html
Academic programming is more about code it yourself. This is important in learning how it works. Code quality and revision control don't count for much. With notable exceptions, code doesn't have a lifetime beyond the assignment. The scope of projects tends to be quite constrained, and unlikely to creep.
In the real world, you should have as little original code as possible. A lot of code is developed by teams. It is better to use library routines than to code it yourself. Code quality and revision control become more important. Code tends to have a lifetime far beyond what was originally expected. Project scope is usually quite broad and tends to creep significantly if not managed.
Actually,
it is impossible to fully distinguish between academic level programming and real world programming.
I'd say the biggest difference might be this: in real world programming - you have to know more than programming, and should be able to adapt fast.
Depending for which sector you are doing work, you have to be in compliance with its laws.
Michael only touched the tip of the iceberg by stating programming related tasks, which I would classify as the easy stuff (if you are worth the dough you are being paid).
In general you'll face at least a couple of challenges per subject in an industry:
If you compare a research phd level programming project vs. a real world one, chances are they are very similar in difficulty, entrance level know-how and such.
The only real difference then is that the real world project
It's different ball game when someone else makes the rules :)
If you look at the subjects studied in IT in academia, you will find about half of the time wasted in math, science, electives, etc. and the other half on academic subjects such as: Compiler design, Theory of algorithms, Computer Architecture, Optimization, Operating Systems, Digital Electronics, and few other courses related to industry such as C programming and Web Programming.
Most of the above mentioned subjects are nice-to-know but will not either directly provide a strong background in what is required in day-to-day IT.
Take the Microsoft Web Programming requirements (that is, areas required by someone to be a productive team member in an organization):
1- C#.NET or VB.NET
2- ASP.NET
3- HTML and CSS
4- SQL Server (or another database)
5- OO application programming and design
6- Java Script
7- MVC framework
8- Some exposure to source control tools
9- Some exposure to automated testing tools
10-Bug tracking tool
11-E-Commerce Concepts (optional)
12-ORM
13-Some business analysis skills
14-Some communication skills
15-Probably, some cloud computing fundamentals
As you can see that most of the requirements above are rarely focused on (you may get 1 course in some at the most) during college/university.
One can't fully blame institutions since there are many such stacks of technology and they keep on changing.
Most of the above from Microsoft will not help someone who wants to develop applications in Java.
The real problem is that not one of the technology stacks that are needed by the business today is ever covered in full.
The above covers the question of suitability of graduates to business jobs like programming in business environment. The needs to research labs, etc. is not covered by this answer. Also other areas require more skills than the above, such as Game Development, Embedded Development, Real-Time Systems Development, etc.
Scale & Focus
From my experiences, in an academic setting, generally the scale of the application you are working on is much smaller, something that can be completed in a day or week, or perhaps as long as the semester by one or two progammers--typically everything you write will be throw-away code that is discarded after the term. In the real world, you may find yourself working on an application that a larger team has taken months, if not years, to fully develop. You spend a lot more time and debugging other people's code, and trying to understand a codebase's infastructure, juggling not breaking the existing parts to add some new or modified requirement.
Requirements, Integration, Customers
Also, there are aspects to developing code, such as requirements analysis, integration testing, etc. that tend to be less represented in academic projects. For the sake of fair grading, typically the requirements are already established for you by the instructor, and it's not collaboratively decided in meetings. You don't tend to have to "sell the customer" on a particular approach that isn't quite what they wanted, but unlike their desires is actually feasible from a techical standpoint. In an academic setting your customer (the grader or instructor) tends to have a pretty concrete idea what they want, in the real world, you may encounter customers who don't really know what they want and have to pick their brain to understand what should be built.
Maintenance & Maintainability
In academia (at least at the undergraduate level), software is built with short-term goals in mind, usually to complete some homework assignment or term project. Once the assignment is completed, the code is thrown away and never seen again.
In a professional setting, most software is written with long-term use in mind; software is intended to be used for at least a few years and needs to be built to be easily maintained and updated over time.
Related to this is the work of maintenance. The majority of professional programming work involves updating or maintaining existing software. So-called "green-field" projects are the exception, rather than the norm.