So you've made it past the whiteboard interview, met most of the team, and accepted an offer for your first engineering job. Congratulations! It may feel like your ordeal is over, but in fact, your journey has just begun.
Whether you're self-taught, coming from a four-year degree or fresh out of an immersive development program, you'll quickly learn that day-to-day professional software development is a completely different animal from learning in a controlled environment.
Here are some of the things I've learned through my first engineering job that should help make for a smoother transition from student to pro developer.
One of the biggest challenges you'll have is getting acclimated to a legacy codebase. If this is your first time encountering a real production codebase, resist the urge to feel overwhelmed - you won't need to know how everything works at first (possibly ever), and no one will expect you to as a new hire.
Instead, focus on understanding the common patterns and conventions being used to get a sense of how things operate. If there are multiple applications involved, concentrate on getting a good bead on how one of them works as opposed to jumping back and forth too much.
My former classmate Kyle Doherty recommends close reading code in his own blog post on this subject. Close reading - reading along with the code, while commenting every line to explicitly spell out to yourself what's going on - is an excellent way to gain a meaningful understanding of what's going on behind the scenes.
Looking at the database structure will also help speed your comprehension along. Even better, once you've got a decent grasp on its high-level workings, ask your coworkers about any 'gotchas' that tend to trip people up when interacting with the database.
If you want to be a real hero, document these things (if they haven't been already) and make them available to the team - you'll be bringing yourself up to speed, plus making it easier for future newbies to get up and running.
Once you've grown comfortable with the learning process - it'll take quite a while to feel like you have a handle on everything - there are some everyday activities you can work into your routine to help smooth the process along.
One thing that I found extremely helpful was taking detailed notes. Whatever I was working on - tracing an obscure error message, diagramming out a better pattern, debugging my environment - having a running text log I could refer back to whenever a similar issue came up quickly proved to be invaluable. Referencing the specific ticket number for the issue in the log can also help with locating relevant information fast.
Even better, once you've resolved an issue, this log instantly becomes the history of how you found the solution. Including this play-by-play into Jira or whatever issue-tracking software your team uses helps add to the team's institutional knowledge for the next time something similar pops up.
Also, when working in the code on tickets, adding a comment with the corresponding ticket number when appropriate can help point future developers to relevant existing issues, and can make things easier for anyone who might pick up the task in the future.
Knowing when to ask for help is critical, especially as a junior. A good rule of thumb would be to give yourself 45 minutes to find a solution. If you aren't able to make meaningful progress by that point, definitely ask for help.
At that point you'll be able to walk your coworker through everything you tried, and you'll be extra-receptive to the solution for next time.
When you're in the weeds, it can be hard to get the impression that you're improving. Two regular practices can help yourself realize how much you really are learning on the job: Daily postmortems and weekly summaries.
At the end of every day, simply write down 3-5 new things that you learned that day. Having trouble figuring out what they are? Guess what - if you've been keeping a running log, just read back through that!
At the end of every week, write a simple summary of how it went, what you learned, and what's on the horizon. I prefer a few bulleted sentences, but whatever works for you is great. If you're having trouble thinking of things, just refer to that week's daily postmortems!
More than anything else, becoming a professional developer (like most things) is all about incremental improvements. The more mechanisms you create for yourself to retain and acknowledge your steady improvement, the faster you'll learn - and the more fun you'll have doing it.