I'm in my last year in a 4 year CS curriculum and I would very much like to contribute to a FOSS project. Unfortunately, I feel that there is no way I can do useful coding, whether it is bug fixing or feature developing. The C/C++/Java projects we undertake at school are trivial compared to coding for serious projects and when I read the source code of a FOSS project I'm completely at loss. Do you agree there is a gap between CS education and actually programming for a real life project? How big do you think that gap is and how does one overcome it?

  • 1
    Think of it as a new subject at school.The more you dig into it, the familiar it will seem and easier it will be to grasp things incrementally .
    – Aditya P
    Apr 23, 2011 at 8:03
  • 1
    Have you considered writing documentation? Requires less deep knowledge and is most likely a severely neglected area.
    – user1249
    Apr 23, 2011 at 12:32
  • Most CS programs DO NOT teach their students how to actually to develop a project the correct way. They teach them how to program and might exapand on some additional topics that MIGHT help them develop a good project most students have a hard enough time just understanding the programming concepts. Just add this comment to Andy's answer. In other words the only way you can learn is if you try.
    – Ramhound
    Apr 26, 2011 at 16:24
  • possible duplicate of What do you wish you had been taught in uni before moving to industry?
    – gnat
    May 16, 2015 at 20:06

5 Answers 5


There is a gap. The gap boils down to two factors: certainty and size.

  • The professor knows what he wants. The client does not know what he wants. This is often your biggest headache.

  • The professor knows you can do it. In the real world nobody knows if it can be done. YOu have to work with the client to constrain the task to be feasible.

  • The school task is fixed; the real world task must be modified to fit budget and technical constraints, but only if you speak up quickly.

  • The small school project means you don't have version control, design meetings, programmer cooperation, interface problems, etc. You never get lost in a classroom coding project; for sure you'll get lost in the real world and need the computer to keep track of the pieces for you.

  • 8
    I wish I could +10 for the first point alone. "Walking on water and developing software from a specification are easy if both are frozen." - Edward V. Berard Apr 23, 2011 at 10:45

I am a beginner myself. I just graduated about 6 months ago.

The gaps:

Time constraints: In uni, our lecturers usually design our assignments in such a way that it is possible for us to finish it on time and a bit more time 'polishing' things up. However at work, this is not the case. There are lots more time constraints at work. Some of them are probably late client sign-off of preceding deliverables, or a sudden unforeseen technical issue that was overlooked that is taking more time than estimated, or simply management who done a bad job allocating the time estimate/man hours required for your tasks.

SOFT skills: As a junior, there are always seniors to help you on the technical difficulties, but no one helps you on your soft skills!

In uni we rarely work in project teams that are larger than 6 ppl at most. At work, we collaborate with far more, and thus the significance of a whole lot of issues. One of the most important is definitely COMMUNICATION. I somehow for some sort of reason find that we weren't communicating with proper technical jargons in uni. Some thus struggle when communicating with more seasoned developers at work.

At work, we should also be more assertive, should back our statements with proper facts, and also, be wary of seniors who try to take advantage of your naiveness(Else you might get unnecessary extra workload)

However the above statements would widely vary, depending on the university's level of education given (I feel some unis give their students lots of hands-on, mimicking real-life project scenarios), some are heavily inclined to theory. And of course, the workplace culture plays a part in such a question as well.


There's also a major software engineering gap. Often graduates haven't been taught some key practices such as:

  • Source control / Version Control
  • IDEs (and in particular refactoring)
  • TDD and pals (ATDD, BDD)
  • Build and Continuous Integration/Deployment/Delivery
  • Static code analysis tools and debuggers
  • Agile techniques such as Kanban Boards, moder Issue Tracking etc

In London the Graduate Developers Community is working with the universities to address these gaps, trying to introduce low impact software engineering techniques to students to use with their course work.

I mean why not build that B* tree but put your code in source control, track bugs in an issue tracker and even write some tests first? :)

  • Most of these best practices have come from the trenches and not academia. Those things frequently take quite some time to enter the curriculum...
    – user1249
    Apr 23, 2011 at 12:34
  • 1
    True, but many of these practices have been around for ~10 years, there's really no excuse anymore :). Academic assignments and good software practices can go hand-in-hand (I believe). Apr 23, 2011 at 13:59
  • They can. Note however that the things taught at universities SHOULD be those that are important but not taught elsewhere, like lambda calculus and Turing Machines etc.
    – user1249
    Apr 23, 2011 at 14:14
  • I certainly wished I had pointers on this available (extracurriculair perhaps.) And it's perfectly good to research further on your own should you wish, but without starting point it is just very hard because you don't know what you're looking for. Also, version control should be introduced to any student (and available on all campus computers) because juggling versions of documents around is a problem everywhere, not just in CS. So many students struggled with it, lost work or turned in wrong versions, and solutions have been available for ages!
    – Inca
    Apr 23, 2011 at 16:34

I agree that the gap is pretty huge. A little big bigger or smaller depending upon what your real life project is and on you specific CS program, but big enough that I think that every company should invest in a serious mentoring program for new graduates starting with them.

You overcome it by working on real live projects. Be it as an intern in a company that actually takes internships serious, working on a FOSS project, creating your own project or starting your first job.

I agree that starting on a FOSS project can be daunting, especially if you try to get into a project where mentoring new people is limited to the advice "just read the source code". My recommendation is to start your own project, something that will make heavy use of a FOSS project that you find interesting, sooner or later you will stumble upon something weird and/or buggy or badly documented. Start to dive into the code of the FOSS project from there. Write a test case that documents the weird/buggy behavior, write some documentation and see how the community replies to a polite request to look over it.


Many programmers I know, me included, were taught electronics, not computing, in university. Ok, we work on embedded software.

Not the answer you're looking for? Browse other questions tagged or ask your own question.