Things I wish I knew before my first full-time software engineering job

I'm officially 5 months into my first full-time job as a software engineer! It has had it's ups and downs, but overall I've learned a lot and really enjoyed it. I wanted to do some reflecting on what I've learned and what I would have done differently to prepare for this software engineering role.

Huge disclaimer: This is my advice for starting a role at a larger software company. I've previously done part-time work at a smaller tech company where I don't think a lot of this would apply. So, take what I say with a grain of salt, but overall I think this information applies well to most software engineering roles.

Product Knowledge > Technical Knowledge

As I mentioned above, I previously worked at a smaller company. It was a consulting company focused on UI development, and we only had a hand-full of developers. We'd usually cycle through a new project every 6 months or so, and then we'd move on to the next thing. To make things interesting we'd always try new technologies for each project. During my time there I don't think I ever used the same React form management library more than once. This was a great way for the dev team to stay entertained and constantly challenged. You learn a lot when you do this, and it's a constant game of "keep-up" to stay technically literate in the field. This is a LOT different than my current job. My technical abilities are not exercised nearly as often. Don't get me wrong, the technical side of the projects I'm working on now is vast, and a lot of the time it goes over my head. BUT, it's already built. There is very little day-to-day technical challenge, or new library I need to learn, or some new methodology for how we do things. The thing I'm learning the most is the product itself. The product we're building is massive, and I don't know that I'll ever really understand the whole thing. The most valuable people on the team aren't the ones that can win at code golf, or know the newest framework forward and backwards - it's the people that know the product. How was it built? Who built it? Why was it done this way? I have to ask these questions constantly. The more experienced members of my team still ask them - they just ask them less than I do. So, my advice, learn to communicate with people better and learn how to take good notes on the product (do yourself a favor and organize them too). Your technical knowledge can be a great tool, but it's useless unless you know what you're building.

Cloud platform(AWS, Azure, etc.) knowledge is crucial

Before starting my job I hadn't so much as created an AWS account before. I've used cloud services to host side projects and personal websites, but I did this with smaller services like Heroku and Zeit Now. For my side projects, these services provided everything I could possibly want and more. They were easy to learn and use, and they could handle the tens of users flocking to my projects without blinking an eye. I'm a big believer in avoiding the use of a wrecking ball when all you need is a hammer, so I stand by using these platforms instead of reaching for something like AWS. That being said I WISH I would have learned a larger cloud platform during college. Knowing how to use even a few services inside a popular cloud computing platform can really help separate you from other new grads, and it is knowledge that almost every company will need you to have as a developer. I have been told by a few of my friends (from other companies) that they were put through AWS training before starting day to day work. I think that's awesome, but I don't think that's the case for most junior devs, or at least it wasn't for me. I've spent a lot of time outside work going through courses to learn about these cloud services so that I can do my job more effectively. In short, if you're a college student or newer developer looking to improve your chance of getting a job and being effective at that job early on, learn one of these cloud services.

The "best" programming solution may not actually be the best solution (snowflakes)

I consider myself a pretty opinionated programmer. I'm not opposed to learning new ways to do things, but generally speaking, I feel like I have a "way" or "style" I like doing things. I don't think this is necessarily a bad thing, but I've definitely learned to avoid my habits recently at work. A lead developer on my team pointed out that the code I had written inside one of my pull requests was introducing a "snowflake" to the project. In other words, I was using a code style or pattern that didn't show up anywhere else in the project. My co-worker was right. I hadn't seen this technique used anywhere else in the project, but to me it was the cleanest and simplest solution. Although it may have been the case that my solution was clean and simple, it was going against the grain of a code base that has been maintained for 4+ years. Ultimately, my "better" code was going to add another drop of complexity to the project. My code patterns saved me a little time in creating a solution to the problem, but may have caused future developers significantly more time and headaches to figure out. From now on I'll stick to adding snowflakes to my own side projects.