Five unexpected lessons from my first two months as an intern at incident.io

In April, I began my six-month placement at incident.io as a Product Engineering intern. Before joining, I was simultaneously excited and nervous: what if I hated it, and what if I had made the wrong choice in coming here?

Well, after only two months here, I’m extremely confident that I’ll always look back at joining the team as a pivotal moment in my life and, quite literally, one of the most amazing opportunities I’ve ever experienced.

So, as I get closer to the halfway mark, I wanted to share some unexpected lessons from my first few months that I feel would be beneficial to any future engineering interns: whether that’s at incident.io or elsewhere.

Generally, these are all things that I didn’t quite realize would be as important as I’ve found them to be and are actually less technical than I would have otherwise thought.

What does being an intern at incident.io actually mean?

Before I jump into what I’ve learned, I’d first like to touch on what being a Product Engineering intern here looks like:

You’re not just making cups of tea

As an intern here, you’re expected and encouraged to make a real and visible impact every day.

I push changes into production multiple times a day, talk directly to customers who are super excited to use what I’m building, and constantly get looped in on deals that have closed because of features I built.

There’s a very real and visible connection between the work you do every day and the success of the business. This is impact I could have only dreamt of having as an intern.

You’ll be expected to take on a lot of responsibility

incident.io made it very clear that they were going to treat interns as if they were full-time Product Engineers: I remember this being mentioned in the job description, during interviews and also on my first day.

At the time I don’t think I understood quite how serious they were about this.

If I’m not careful, I could cause a serious problem.

However, at some point, you need to take the first step to get over the fear of breaking things—otherwise, nothing will get done.

You’re not doing this all on your own

At first, it seemed daunting that I’d be expected to take on so much responsibility and have an impact, but it quickly became clear to me that I was not in this alone.

The entire team constantly went out of their way to make sure I was given all of the necessary support and tools to handle the responsibility. I can’t express how much I appreciate this and how it has accelerated my learning and confidence.

As an example, at the beginning of the internship we sat down with a Senior Engineer who made sure we were all comfortable with what having production access meant, how we could avoid doing anything damaging, and more generally answered all questions and concerns we had.

The main point here is this: you’re not just thrown into the deep end and expected to thrive, you’ll have extremely intelligent and hard working people to lean on all the time who will constantly make sure you’re okay.

My five unexpected lessons

As I said above, at every stage of the application process the team at incident.io deliberately shouted about the fact that they’d expect interns to take on lots of responsibility and have a big impact.

I came in expecting to be pushed and learn lots of new technical skills. This has definitely been the case, but I’ve also learned so many other important lessons that are less technical.

Lesson #1: Go out of your way to spend 1:1 time with your colleagues

During my first week, my manager told me I should ask other people if they’d like to go for 30-minute, 1:1 coffee chats. I didn’t say anything, but my initial reaction was something along the lines of 'That feels pretty weird. Not sure how I feel about doing that.'

This is something very common and encouraged at incident.io. After my first few 1:1s, I realized how valuable they were and just how wrong my initial reaction was. Nobody found me asking for a 1:1 weird, and actually, everyone seemed excited by it.

The value of them is also instantly clear because you start to feel super comfortable approaching people in the office since you’ve already broken the ice and begun to develop a relationship with them. This is something I’d love to keep up throughout my entire career going forward and something I’d highly recommend to any intern.

Lesson #2: Don’t be scared to break stuff

Initially, I spent too much time worrying about how my approach to adding a new feature or updating an existing one would impact the rest of the codebase. This is definitely important, but I’ve also learned to start thinking in terms of “one-way doors and two-way doors.”

Here’s something one of our senior engineers taught me:

For me, an obvious example of this is making changes to the codebase locally. It really doesn’t matter what I do and how much I break stuff because that has no impact on customers and I can revert all of the changes with one git command. Importantly, though, this can just as easily apply to changes in production.

Equally, it’s important to realize when you’re doing something that’s a one-way door: something that’s difficult and painful to undo. In these cases, it’s really important to slow down and think, and then propose a solution to your team to get their thoughts first.

Lesson #3: Trust your instincts

Interning at a company with so many great engineers definitely felt daunting, and I found that I began second-guessing my instincts and ignoring some of my concerns rather than raising them with the team. Doing otherwise felt strange because I felt that their judgment was better than mine.

I slowly started testing the waters and also spoke to my manager about this feeling. He assured me that the right thing to do was to raise my concerns, even if I ended up being wrong. There are two outcomes of doing this:

• My concerns are valid and make the other engineer(s) reevaluate the situation, and everybody wins
• I’m wrong, but I end up having a productive conversation and actually understand why I’m wrong, and get to retune my instincts.

More often than not, I’ve found that my instincts were correct. When discussing them with others, they agreed, and we adjusted course based on that conversation.

My advice based on this experience would be to realize that even as an intern you were hired for a reason. The interviewers genuinely believed that you would be able to provide value to the team and that you’ve got good fundamental instincts that you should rely on and trust.

Lesson #4: Don’t be afraid to ask questions

Pace is one of the most important values at incident.io: we need to ship quickly to close deals and delight customers. It’s really easy to think that you should spend lots of time trying to figure out a solution to a problem, but in many cases it’s much better to just ask someone because more often than not there’s a super simple solution that they’ll know instantly off the top of their head.

For example, I recently couldn’t figure out why the ‘border-1’ style class didn’t seem to be applying any border, even though ‘border-2’ and ‘border-3’ both seemed to be working.

It turned out that the ‘border-1’ class is actually just called ‘border,’ and one of the other engineers told me this in less than five seconds after I asked. It would have been no benefit to me to spend any longer trying to figure that out myself.

I’ve found that when you don’t quite understand the solution proposed by someone else when you’ve asked a question, it’s helpful to attempt to go through the pain of figuring out that solution yourself. It’ll take a bit more time in the short run, but it’s likely you’ll rely on that knowledge again soon and will be able to use it to raise the pace in the long run.

Lesson #5: Actively set aside time for learning

In my first few weeks, I felt quite an obligation to “prove” myself and show that I was able to provide lots of value.

This obligation manifested itself in my aim to, for example, get through as many tickets as I could in as short a space of time as possible. Although this is a good way to show your value, I think there’s a case to be made that it can be damaging in the long run if taken too far.

There’s some complicated code behind On-call, and it’s not something I think can just be quickly picked up on the fly while needing to make a change.

So many decisions have been consciously made that are important to understand, and the implications of accidentally making a change with detrimental and unintended side effects are very high, meaning it’s important to have a good working knowledge of the system as a whole before making significant contributions.

Since I’ve realized this, I’ve began spending around an hour each morning diving deep into the internals of our core On-Call codebase. This has allowed me to slowly piece together the system as a whole, and also meant I can start to speak intelligently about major changes with the rest of the team, whereas previously these conversations felt super overwhelming.

This is something I’d really recommend for any intern:

It’ll almost always pay dividends in the long run, and is the best way to supercharge your learning and growth.

I really hope that future interns, both at incident.io and elsewhere, find this post helpful and can relate to many of the experiences I’ve written about here. Finally, I’d like to say a massive thank you to the team at incident.io for making the first two months here unforgettable. I couldn’t have asked for anything more, and I’ve had such an amazing time!

I can’t wait to see how the next four months unfold!