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?
closed as primarily opinion-based by durron597, Thomas Owens♦ May 18 '15 at 13:31
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
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.
I am a beginner myself. I just graduated about 6 months ago.
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? :)
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.