I am entering the final week of my second technical internship. I've spent approximately 3 months working as a Backend Developer intern. This has been another excellent opportunity for me to learn more about the industry, grow my technical and soft-skills, and learn about the day-to-day work of a Backend Developer.

In keeping with the theme that I started last year, below are some of the biggest lessons and pieces of advice (in no particular order) that I will bring with me to future professional opportunities. I hope this can help those interested in perusing a post-secondary education in the computer science (CS) field or for those who are entering the professional job market.
 

We are more connected as a word than ever before. Dates and timestamps are everywhere - from an end user's browser all the way down to the logs of an application or microservice. Different regions have different date and time formats. How does your code handle those locale idiosyncrasies? Does your code account for time zone differences and daylight savings changes?

You don't have to wait until you're in industry to get experience with dates! Grab your favorite programming language, grab an open-source date library for that language, and do some experimenting!

In a typical college or post-secondary setting, you might often find yourself working alone on your programming project or with one other person. In industry, you will (more likely than not) find yourself working on a team with 5, 6, 7, or more people. This is substantially different than working alone or with one other person. It's a great way to bounce ideas and get more work done. Each person on the team might be working on individual pieces of the puzzle, but at some point each piece of the puzzle has to come together.

Data drives decision making. Thus, people always want more of it. Often, people want to see data from two independent sources presented together. Developing a skill to connect previously disconnected sources of data will take you anywhere you want to go. 

Once you have data - how do you present it in a way to make it actionable? You can have all the data in the world, but unless you can take data and turn it into an action plan - it's worthless. 

Making data easy to understand is critical. Often times you'll find yourself presenting data to decision makers that don't always know the ins and outs of your problem. Your data needs to do that for them.

Everyone is busy. Too busy. There are more items to get done than we have hours in the day. 

So, when raising an issue, asking a question, or conducting a presentation - cut to the chase. What are you sharing? Why is it important (why are you sharing this information and not something else)?  What's blocking you? What do people need to do (or more importantly - what should they not do)?

Everyone wants to grow their new career, but where do you start? Simple. Start by expanding your influence. How do you expand your influence? You do it in stages. First, expand your influence on your team. Do good work. Be consistent. Become the "go-to" person for something on your team. Then repeat. Eventually become the "go-to" person for something larger, outside of your team. Get in front of people outside of your own team. Show them the work that you're doing. 

Most importantly - it takes time. 

Becoming the "go-to" person for a topic or issue doesn't mean you have all the answers. It doesn't mean that you're perfect. It means that you have some of the most experience with a topic, are consistent in your work, and get back to people with answers to their questions.

Your team members, boss, or manager won't know everything that you're doing on a day-to-day basis. So, don't be afraid to highlight the work you're doing. 

Each week make a list of the big, important things you completed. Some weeks the list might be shorter than others. Did you help with an urgent big fix or hot fix? Did you address a customer issue? Did you present information to upper-level managers or executives? This will help you demonstrate your worth to the team and the company during one-on-one meetings, team meetings, and annual reviews.

Listening is key. Think about how much you can learn by simply sitting in on and listening to meetings or office hours. Take advantage. Silence isn't a bad thing.

Often, code bases for existing tools and services are large and don't use the absolute latest and greatest. When you join a new team, you'll be spending a ton of time trying to get familiar with a new code base(s). That takes practice and time. 

Find your favorite open-source project on GitHub and dive into a random file. Try to understand what the code is accomplishing and why it was designed the way it was. What tradeoffs does it have? You probably won't be able to perfectly understand every single line - and that's fine. Understanding the broad strokes of different pieces of code before you can physically run it will make the process of learning large code bases smoother.

Some days you'll make a ton of progress. And other days it'll feel like you took 10 steps backwards. Get comfortable with that feeling. It happens more than you think it will. Remember that even on days that you didn't make any progress you still learned something. You learned a bunch of ways that don't accomplish your problem. That's something.

Get away from your desk. Do something different. Take a break. You'll get it figured out. You were probably making things too complicated. 

When all else fails - attack your problem from the exact opposite direction. Some of the hardest problems can be solved trivially by attacking them from a different direction.

--

All of the thoughts discussed above are solely my opinions and do not represent the position(s) or opinion(s) of my former employer or my former colleagues.