I wanted to know if anyone had any tips for transitioning from small personal projects and coursework, to a large enterprise scale project?

Im in my second year at university and have attained a placement with a large tech company, to work on a pretty large project, I'm just a little apprehensive about 'finding my way around' such a large project.

closed as too broad by durron597, user22815, user53019, Ixrec, user40980 Apr 28 '15 at 1:44

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.


Learn about source control, and how to follow 'house style' if there is one, i.e. don't fight the man if the man wants you to use tabs over spaces, put in or leave out semicolons, and so on.


Take your time, learning a new code base takes lots of time. Get familiar with the language the code is written in, and the style used to write that code, if you aren't already familiar with it. Learn about the code before learning the code, with large code bases its nearly impossible to remember exactly what every piece of code does, and its pointless because the code is always there to show you what it does, if you can find it, so learn how to find the code you want.

You have to start small, and your employer will probably help with this by only assigning small tasks at first that only require localized changes and gradually work towards bigger changes. Also never be afraid to ask your team members questions, especially early on you need to build relationships with them just as much as you need to learn the code.


The most important thing I see lacking in my company for new hires that came right from university is the habit of documenting the code comprehensively. Unfortunately, most courses teach you how to express what you want to do to the machine (the progam) but not to the poor soul that has to mantain the code later.

I'm not talking that much about things like UML. That usually is covered. I mean Javadoc, Doxygen and the like; code review; specs and contracts; clarity when writing the description for a commit to the VCS; clarity when creating new issues in the issue tracker. The more experienced you get, the bigger the projects you handle, these things tend to become even more important than the code itself.


I was in the same boat last year. I'd suggest brushing up on your SQL skills, you'll be using those quite a bit. In my experience in University, SQL wasn't taught too thorough if at all, and with any large project in a large tech company, expect to have exposure to it.

Another thing that really helped transition to the workforce was networking. Meet as many of your coworkers as you can, most of them came to me and offered help and/or advice, and I'd be behind where I am now without it.

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