When I started my first software development internship a few years ago, I was immediately overwhelmed by just how unprepared I was. There was a whole environment to set up with lots of tools I’d never heard of, a large unfamiliar codebase, and layers of abstraction in the code, not to mention SCRUM processes and meetings.

Sure, I’d learned a bit of version control (in class it was the rather outdated CVS, although I dabbled a bit with Git in my own time since I’d heard it was useful), and the concept of abstraction had maybe been mentioned by a teacher.

But a computer science program, especially ones that focus mostly on theoretical CS, like my school did, can leave you quite unprepared in many ways for the realities of software development in the professional workplace.

An internship is the perfect place to get a jumpstart on learning on all these new things before you graduate and start work, so if you’re still in school, I highly recommend snagging an internship.

Otherwise, it’s important to take the initiative to learn on your own. Go to tech meetups, read blogs and articles, talk to other students who have already done internships.

A few of the most important lessons I’ve learned about software development that I didn’t learn in school:

1. It is vital to think ahead when writing code. This is important in a few ways; for one, of course it’s good for error handling, scalability, etc. to plan for the future when developing a solution to something. But I also mean that you should think about maintainability. In school, we tend to work on a project once and never look at it again. In the workforce though, once your code goes into production it may be there for years to come, and not just you, but other people will usually end up maintaining it. Make sure that your code is clear and readable, and that you are proud of it.
2. Be familiar with Agile. Many companies follow some form of agile development. In my experience most places don’t follow it to the letter; they adapt it to their company’s or team’s needs, so your experience may vary, but you should at least be familiar with the basic concepts of sprints and daily standups.
3. Development is usually done by teams. Occasionally in school we do team projects, but at least for me, most development was done solo. And I’d grown accustomed to the stereotype of coding being a solitary activity. But in the workforce, development is usually done by teams, and many companies even have an “open floorplan” sort of design to encourage collaboration even more. You may not end up doing pair programming, but you will be usually be working with multiple other people on projects, and discussing problems/solutions with them. Also this is another great reason to get familiar now with source control: if you are working on the same codebase with multiple other people, you will often run into and need to resolve conflicts when checking in code. On that note,
4. Know how to use source control. Git is by far the most commonly used version control system these days so I would highly recommend learning some basic Git commands and concepts. You can get a free account on github.com and go through a basic tutorial there. Be sure you have some school or personal projects pushed to your profile, and put the link on your resume, because many employers want to see that you have a Github profile. As mentioned above, it’s also good to know how to do conflict resolution and merges which happens frequently when working with teams, so try contributing to an open source project or working on a project with some friends if you get a chance.

There are lots other lessons learned, but these are some of the ones I’ve found to be most helpful when first starting my career.

Here’s a blog post I read recently that inspired this topic: http://blog.newrelic.com/2014/06/03/10-secrets-learned-software-engineering-degree-probably-didnt/