I've recently realized that the skills you learn as a software engineer (SWE) are disjoint from the skills that you learn in school. Below are some of my findings.

1. Nobody knows the answer, but it's out there somewhere.

It's up to you and only you to figure it out. That's what the company is paying you to do. Problem-solve.

When my internship first started, I shot questions at my mentor, full-timers, and other interns what seemed like every hour. After a while, I realized that they didn't know the answers to my questions either. Either we would figure it out on the spot together or they would try to give me the most guidance they could (usually not much). Then, I had to figure out the rest.

We have a dichotomy here. In school, you are able to ask your professor anything about the class and get a straightforward answer. But, in the workplace, there's no such thing. This is because when you work, you are doing research. You're doing more than regurgitating facts.

2. Take it slow, but not too slow.

Learning takes time, debugging takes time, and detours are normal. It's a primary SWE skill to be able to determine how long the detour should be. As interns, we tend to try and decrease this detour as much as possible to get as much done as possible, but as I've recently learned, that isn't the most optimal plan. Instead, you should try to increase your time on detours to provide a more solid foundation for later.

What I mean by a detour is the path in which you take to solve a problem such as an error or bug. It usually requires a lot of googling, time on Stack Overflow, reading through the documentation, amongst other things. Spend more time actually learning why something works instead of copying and pasting code. At first, you will seem to make slower progress, but you will soon realize that you've actually created a better foundation for yourself that will benefit you in the long-run. It's more or less about investing your time in the right place now for long-term benefits.

As an example, instead of copying a Linux command from some website and running it, I now take apart each command and flag and learn what each one does. This means that in the future, I'll be able to use those commands in my own way instead of having to search online again and again for the similar commands or flags.

"In fact, investing in peer-driven learning environments can make your long-term work more effective, despite short-term costs in time", says Vincent Chen, a student at Stanford University.