After months of nerves, interviews and one too many LeetCode questions, you’ve done it. You’ve landed an internship, you’re free from the dread of a long, empty summer and your brain is filled with vague notions of what your internship might be like.

I’m here to gather up your brain clay and sculpt it into solid ideas of what things will be like. Before we start, it needs to be said that your internship experience will differ from mine (even if you come to FreeAgent), but don’t click away. From discussing with friends, reading online, and my own experience there are commonalities between all software engineering internships. After all, you’re working as a software engineer, albeit with the stabilisers on.

The things you learn in your internship, by their very nature, are fundamental. Reviewing code, working in a scrum environment, deploying to production, technical writing and using Git are all skills you will use if you pursue a career in software engineering.

So let’s dive in…

You’re going to be useless for a little while

Your first couple of days or even your first week will be spent onboarding. This is true of almost all companies that will be offering internships (unless you’re working at a small start-up). You’re going to have to get used to a lot of different systems. On a typical day of writing code, I use a couple of systems without really thinking about them. The first is FreeAgent’s Devkit, which is a system that allows us to develop our application locally. By running Devkit I can launch a version of our website locally. I can make up crazy data and no one will know! Having local development tools is extremely important because you can change the code and see how it affects the app on your own computer like it’s your own personal playground.

However, they can be a pain to set up. Do not feel stupid when setting them up. Even the guide you might be given (or god forbid, some terse documentation) won’t be 100% clear. You’re going to encounter bugs that aren’t in the guide, and you’ll have to sift through extra documentation or ask for help.

Overall you’ll spend a lot of the first week setting things up. It can be frustrating, but once it’s done, it’s done and you’ll never have to look at the stuff again and will be off writing code. Someone’s probably going to have to help you with that…

You’ll probably have a buddy 

Yes, a buddy (possibly a friend). Most companies will assign you a buddy. This person is usually a senior engineer who has either volunteered or been coerced into helping you get going. Jokes aside, you’ll hopefully find that your buddy is extremely knowledgeable, affable, and infinitely patient – or at least mine was (thanks Chris!). Your buddy will be the one-stop shop for stuff you can’t google.

Things like: “why doesn’t this piece of company-specific software work?”, “sorry but what exactly is a ….?”, and of course, “I think I messed up a rebase”. Don’t worry if you don’t know what a rebase is yet. We’ll get to those later and – trust me – you’ll become familiar with them. 

At the beginning you may feel extremely clingy. Don’t worry, this is normal. You’re being inundated with lots and lots of information and are spending hours each day setting up company-specific applications and learning about other applications you’ve never really used before. At this stage I think it’s helpful to set up a few rules about asking for help. You should have a certain amount of “struggle time” before you ask for help. But when it comes to setting things up and getting the lowdown on new technologies there’s no need to bash your head against a wall, googling for hours when your buddy could tell you how something works in five minutes. Similarly, if you think you can probably google it, try that first.

Your buddy’s ultimate goal is to get you writing code, I suspect that’s what you want too. Brilliant – let’s get to it.

Writing your first line of code

You’re finally here. After several days of setup, two broken mice, and your buddy muting you on Slack, you’re ready to write your first lines of code. There’s just one thing in your way – the codebase. At first the codebase is an indistinct endless sea. White waves roll violently, shaking your boat and you’re a little bit daunted. Yet your buddy stands tall, manning the sail and staring into the distance like they can see something you can’t. They can.

Chances are that the codebase you’ll be working on is huge. FreeAgent in all its various forms comprises around a million lines, let’s just say that it’s going to be a lot. Hundreds of times larger than anything you’ve ever worked on before. I’m sure this will be true of whatever company you’re working at. 

Your first change will be something small. Mine was updating the text on a page. But that took me longer than expected. The first hurdle was finding the corresponding code file. The problem was twofold; one, I barely knew ruby, let alone rails. Two, I had no idea how to navigate the codebase. Both of these things come with time.

However, you can learn to navigate the codebase much faster if you take some time to get to grips with it. I’d suggest picking an area of the application at random and trying to find the corresponding file. You could do this by searching for the filename, or searching for text that is on the page. Code editor tools are your friends. Once you’ve found the file, and made the change, things are far from over. Unlike most university or personal projects, solving the problem isn’t the end of it, it’s only the beginning…

You’re going to need to test

You’ve done the work but there’s so much more to do. Universities rightly foist testing onto their students and turn a blind eye when the unit-testing gang claims another victim, but they never really go into why testing is so important. “Yeah yeah yeah, to test my code for things that I won’t notice,” you regurgitate, as you roll your eyes. The problem is that we’re never really given scenarios where testing is truly useful. Projects that involve testing are often contrived or don’t lend themselves to testing. It’s no surprise that being given a hammer when you don’t actually have a nail makes you question the need for a hammer. However, internships involve nails, lots of nails.

During my internship I’ve gone from seeing testing as a necessary (but often superfluous) evil to the thread that holds my sanity together. It boils down to this. Usually when working on a smaller project, you’re the one making all the changes. Even if you aren’t, the codebase is small enough that if someone else makes a change you can see it quickly through your normal use of the application, or it affects what you’re working on. Neither of these things are true when you’re working at scale. Someone else’s work probably won’t affect the area of the application you’re working on, and you certainly won’t find all the new bugs they’ve introduced by clicking through every possible path in the application. 

As I see it, tests are there for two reasons; to check what you’ve done is right and to make sure that if someone breaks your code they’ll know about it. In web development the former often seems redundant, that is until things become complex enough. Time and time again I am caught out by my own tests. You don’t necessarily need to follow test driven-development, but you will find that thinking about what could go wrong helps you solidify your mental model of the code and what it ought to do.

So write your tests. It may feel like pulling teeth when making small changes but tests will soon become your greatest allies, helping you stay on top of everything. In fact, if you’re good enough at testing you won’t need to look at the application. This was one of the most surprising aspects of my internship. It seems natural to check that all your changes work as expected in the application, and this is done, but not by you. We’ll get into this later when we talk about publishing your code. In theory your goal should be that your tests are so comprehensive that you never need to look at the application itself. So, you’ve written your magnificent code and changed that text. Your tests are looking great. Surely someone is ready to present you with a medal now? No, it’s time for some feedback.

Looks good to me

The next step is to have your code reviewed. At this stage the senior engineers descend from their hallowed environs to assess your efforts. They’ll take out their heavenly weighing devices and prod your code with their tridents until it falls apart. This is good, even though it may be embarrassing. When you’re starting out, even on the most basic changes there will be things that even experienced engineers would miss, such as company code style decisions, new language idiosyncrasies or code structure.

You’ll have to take it on the chin, code reviews don’t just stop you polluting the codebase, they are also extremely effective learning opportunities. As you progress you’ll be working on larger, more complicated changes, and getting even more feedback. Don’t be alarmed if there are 15 comments on a change and three rounds of changes – these things happen. Sometimes the feedback won’t quite make sense, or even be incorrect. It’s okay to ask clarifying questions! To figure that out you had to know what you were doing well enough to explain and justify your decisions; an extremely important ability to have.

Git good

Git is a version control system that you’ve probably encountered before. It allows multiple developers to work on several different parts of a codebase at once without catastrophe. You’ve probably used basic Git commands before: push, pull, perhaps even merge. But there’s a whole new world out there. The one you’ll use the most is rebase. Rebasing allows you to squash together commits, change which commit your branch is based on, edit commit messages etc. It’s essentially a big Git sledgehammer; extremely powerful if you know what you’re doing, disastrous if you don’t.

For example, say you have 10 commits for a disgustingly minor change, you could rebase and squash all these commits together into a single commit. Your commit history probably isn’t something you’ve thought too much about before, but when working on a commercial codebase it’s important that you don’t pollute the codebase with a thousand commits, and that your commits have descriptive messages. A personal favourite commit message: “Stops evil behaviour”. Git rebasing can be dangerous though. It feels more like bomb disposal than managing how your code is stored. You have the power to delete commits. You can also stick your branch onto the wrong branch and create a nightmare of merge conflicts, so be careful. Once your code is up on GitHub as one nice commit (with the several hundred others needed to make the requested changes bulging underneath it) you have only one step left…

Manual testing and malaise 

Once your code has been reviewed and passed all other automated tests, someone has to take a look at how it performs in the app. For my first deployment, I did this myself without thinking. It was only when I was told to write the ‘PPT steps’ ( pre-production testing) that I realised that I’d done someone’s work for them. It’s best to have someone else look at how your changes affect the app to reduce errors. They haven’t been working on the problem and they’ll probably be able to spot things you missed out.

Furthermore, they’ll be following your instructions to the letter. If they can’t, then how you’ve implemented the functionality is probably incorrect, or you don’t understand the changes well enough to describe their functionality! It’s unusual to find too many errors at this stage, but it’s quite common to be told that your changes don’t quite match the design specification or that things aren’t reloading how they should be. 

Fin

That’s it, you’ve done it and you’re ready to deploy your code. It was quite the journey and will probably be a bit underwhelming and tedious for your first deployment. It gets better. In this post I’ve tried to give a brief overview of the parts of my internship that I didn’t find immediately obvious, but that are likely to be common to most software engineering internships. 

An internship is like a three-month interview; for you and for the company. Naturally, you want to produce your best work and appear in the best light. Don’t let this burden you. Ask questions and be open. If you truly weren’t competent you’d have been weeded out in the application process or someone would be letting you know by now. Take time to consider the company. Would you want to work there if they blessed you with a grad offer? Why? As your first experience in the industry an internship can let you know what you do and don’t like. Everyone’s internship is different, and every company is different. You should think about what the company does well and what it doesn’t. I know this is difficult to do when you’re forever knee-deep in a code swamp. Every so often you should come back onto solid land and assess. 

In the end you should just try and enjoy it. You’ll only ever be completely green once, and no one expects you to know everything. Make use of that, you’re being moulded by your experiences whether you like it or not. So go out and seek good ones, spend days debugging and hours failing. That’s where you’ll learn the most.