Regardless of how good you think you are as a programmer, there is a good chance that you are not prepared for your first big programming job. Mentally and physically. Physically? You bet. And I will discuss that in depth further down below.
I'm here to tell you that while you should have some trepidation going into your first big coding job as that is a normal human response, it might not be as difficult as you might think. But there are a few things that you can do to make the most of this time, so that you don't crash and burn so early on.
Let's discuss what you can expect (and maybe not expect) as you begin your steady climb into this new territory.
It's easier than you think
This one throws everyone off when I mention it. You read dozens of books and watched hundreds of YouTube videos online and you are prepared to architect the software on moon-landers as far as you are concerned. Kudos to you for the confidence on this one. But there's one big challenge in the way. You have no idea what the company that you will be working for is doing or how they are doing it.
Think of it like having built a Moon rover but instead of it going to the Moon, it goes to Mars. Sure, you made a car-like vehicle that can move in many directions and measure dirt samples while sending data back. But you have no idea what the Mars terrain is like. Maybe the entire planet is made of jelly. Or maybe the dirt on Mars is the size of boulders. We just don't know until we see it. This is same principle. And all of this to say that as the Mars Rover project lead (one day), I would not give you the heavy burden of designing our new vehicle on your first day of work.
Most companies will give you at a minimum 1 month to learn the lay of the land before any big task is handed off to you. You'll read through documentation, stare at someone elses's code for days on end, go to meetings (many), get introduced as the 'new programmer', find your lunch group, and more importantly wait while the system admin cautiously gives you permission to the many different environments, but only after investigating who you are. Similar to your first day at school when you were a kid. And you thought those days were behind you.
But more importantly, you won't really be given any highly complex project just yet. You probably won't have deadlines either. This all comes down to building up trust within your group. Your team and project manager can't give you much, because they really don't know what you are capable of just yet.
There are two routes that you can take here. You can either lay low and do minimal work while you get paid relatively well and slowly build up corporate knowledge through the months. Or you can ask as many questions as you can about the projects and best practices day 1. Both get you to the same place. You will eventually learn how everything is setup as far as the tech stack is concerned. But they get you there at different times.
Don't delete the database
This happens. Alot. If you don't know how to do something, you should probably ask someone in the vicinity that has done it before. Don't copy and paste that SQL query you found from 2012 on an old forum and run it. Particularly not on a production server. That's what a Dev environment is for. But really that's what you own test copy of the database is for also.
I made this mistake at some point. Except I didn't technically "delete" anything. I simply ran an UPDATE query without specifying which record to update. UPDATE everything you say? Sure, why not. In the blink of an eye 100,000 records all became the same. On the production server no less. The electrical charge that ran up my spine as I realized what had happened was felt for months after.
Luckily we had data backups (as every company should) and reverting the data took our lead developer no more than 10 minutes. And took 10 years off my life. As mentioned above, this happens alot. At this same job, I heard stories of another Jr. Developer doing the same thing just months before. Although on a more important database table and causing some downtime to the website.
Going back to that "It's easier than you think" approach, don't make things difficult on yourself. Ask questions if you aren't 100% sure how something is working, or if you have that nagging feeling that you are about to do something wrong.
Ask to shadow a developer
It sounds odd in our current society of giant sound-proof headphones where we want to be left alone, but people do in fact enjoy sharing knowledge and teaching, even if they don't know it. When I set up a team of interns for my startup, most would sit there for hours without a word if no one approached them. And the rare few asked if they could get a run-down of the system. I was of course more than happy to share the knowledge, even if just to cut through the tedium of answering countless emails in the day.
You can either sit there for days straight struggling to make sense of someone else's logic, or you can ask that someone else to just tell you. The interns that had asked to shadow me ended up building some very complex components and working together in teams that they themselves set up and managed.
Do this early on in your new career. Spending the first 2 weeks in quiet solitude reading dozens of pages on a spec sheet can quickly lead you to wonder if this job is right for you.
Don't rush the process
Don't try to be a hero here. Not only do you have less years of experience than anyone working at this company, but there's no way that day 1, week 1 or even month 1, you understand the many different business dealings that are happening all around you. I jumped the gun early on in many projects because I wanted to showcase my skills and because I assumed that I could build anything. And so I stayed late and typed away like crazy day after day feeling like I could own this company.
It's a humbling experience when you sit down for a code review and someone points out all of the many different areas that you missed the mark on and that could be improved. Much of the time due to lack of business knowledge and also real-world experience. Real code in the real world isn't at all like the examples you see online or the notes that you take in class. They represent hundreds of meetings, dozens of developers and thousands of days of work.
It's physically demanding
Yes. Programming has a physical demand, particularly when you are expected to do it for years at a time many hours per day. In college, you had the luxury of only having to sit for 1-2 hours on average before you walked across campus to your next class. The first time that you have to sit for 6-8 hours straight at work, your mind will begin to wonder if you are still alive, or if you subtly slipped into some type of non-living state.
Be mindful of your sitting patterns as years of non-motion can lead to various health effects, many that will just sneak up on you at some point.
Learn as much as you can early on about your company, ask the right questions, find a good lunch group, keep learning and move around every hour or so, and remember, you are never really prepared for the first time you do anything in life. But you just have to do it.