Don't send an embarrassing company-wide email about how someone ate your lunch. I'm still working there after 6 years, but I get reminded about it now and then.
But seriously, focus on learning from your peers as much as possible. Don't worry about what others think of you or your code. You shouldn't take code reviews personally. Seek objectively simple solutions to problems.
Good luck and may you find fulfillment in your new job!
Also don't just do what code review comments tell you to.
If you disagree, state that and tell them why. Maybe you know something they don't about why you did something the way you did. Maybe they are just wrong. Maybe there's some business requirement you know that they don't or vice versa.
Also the other bit of not making changes just because they tell you to is this, you need to understand why you're making the change. This way you won't make the mistake again and you'll learn. You may stop doing the thing again if they comment it enough times and you internalize it, but that's not understanding, that's pattern recognition and won't help you be a better dev.
Code reviews are a two way street and a great learning opportunity. Use them to your advantage! :D
Embarrassment? That's your lunch! At some point you have to take a stand and defend yourself against these animals that knowingly eat another persons lunch. What's next? First it's lunch, then it's your car, your identity, then your 3pm snack!?
Don't forget to have fun! You probably like being a programmer, so don't let this job change that. Treat yourself well. Personalize your work tools to your liking as much as possible. Bring a cup you like to the office and use that. Be alert in case your chair is uncomfortable.
Do a little more than expected. That's where the magic happens. That's how you grow and improve. That's how you build connections, and get freelance work or meet that cool guy who starts an exciting startup, or get recommended for that job at whatever corporate you want to join.
Improve a little bit every day. Honestly this has given me the most returns. It doesn't have to be much at all - find a nicer IDE theme, memorize one shortcut, read up documentation on that command you use a lot but never understood.
Explore things that interest you, not necessarily the one that seems like the next career step. When you're young, your hacker instinct is probably more accurate than most of the data and buzzwords going around.
Find your go-to rotation of music and podcasts so you can immediately plug in when you want to get in the zone. I highly recommend checking out https://brain.fm. I pay like $6.99/mo (about same as my Spotify subscription) and it has been an absolute gamechanger for me. Piano music, lo-fi, classical music are also great places to start if you have Spotify.
For podcasts, which aren't always great since they can be distracting, I've been enjoying Bill Burr's Monday Morning Podcast lately. It's absolutely hysterical hearing him rant for a few hours every week.
I'd recommend the complete opposite - don't wear headphones for the first few weeks. The micro interactions that you get in the work place can make or break your relationships with your new colleagues.
Don't try to prove yourself or worth by "over programming". Learn the culture and abide by it. Don't try to change everything as soon as you start working. Control your ego.
I'd chime in that most places there is a 'big picture' and what people think is the 'big picture' OP should try to learn what those two are. Because you want to work with and not haplessly against them.
First day you aren't going to be doing any coding.
You are likely to be doing a lot of admin nonsense, getting your dev environment set up and learning how their source control works / is structured.
After that you will be told to pull something from source control and will probably spend next couple of weeks familiarising yourself with the particular code base you are going to be working on. Don't treat this as an easy slacking off period. Take it seriously. If you are going into a code bases in the 100K+, 1M LOC size then this is a fairly hefty task on it's own to try and understand the architecture / structure.
Ideally they will pair you with someone senior for a few weeks if you are a junior developer.
Do you know what source control they use? If so it's worth getting to know it before you start.
If you are a junior developer, develop a thick skin, you will likely get lots and lots of comments on your code and potentialy a lot of them negative. This is fine, this is expected. Learn from it. Don't end up in your feelings or take it personally.
Be prepared to ask lots of questions, again if you are a junior developer this is totally expected.
What would be nice is to get included in code reviews from the start, look at the comments on other peoples code reviews and learn from them! This will help you pick up the expected style as well, if they have one (and it's not enforced by some auto-formatting).
Hey, just want to say good luck and hope it goes well! There will be a lot to learn but take it one day at a time. It's a long journey but a fun one. Try to absorb as much information as you can from your coworkers.
Shameless plug: I'm starting a newsletter focused on offering career advice for programmers. You'll learn plenty of technical skills in your new role, but my hope is I can teach some younger devs what kind of soft-skills are needed to navigate your career.
- once you are there for a few months, take ownership of something (a part of the product, some piece of tooling, an area of support, etc) and become the go-to guy for that. You will be rewarded for it
- ask a lot of questions and don't be afraid to look stupid. People are often relieved when you ask the "dumb" question because they didn't know the answer either
- along the lines of don't be afraid to look stupid, if something is going poorly or isn't going to meet a deadline you have set, ask for help as soon as possible
- take ownership of your own career. no one will give you a raise or a promotion without you asking. Occasionally someone who is an absolute standout will get recognition like this, but it's rare
- Read some recent PR's on an area of the codebase you'll be in. See if you can come up with some questions if you can't figure out why something was done. It would impress me if someone came to me with great questions or was just interested in learning.
- Be aware of your time. Sometimes, devs can be pulled in many different directions that distract them from what matters.
- Learn and research your company's tools and practices, i.e. Github/Bitbucket, Trello/Asana, scrum/okr's, etc.
- Get your dev environment running. If there are bugs or issues in the documentation, see if you can make a PR and fix it for the next person.
edit: PR stands for "pull request." Adding, since I would not have known this just out of college.
You will screw up at some point. It's ok. It happens, we all took a website offline or merged the wrong branch. It's part of the learning process.
Learn from everyone, there are many different ways of doing everything, don't just follow blindly one person, observe what everyone is doing and choose whatever works for you.
Be always open to improving, learning and becoming a better dev. This is a job that is ever evolving.
Read the error and understand it. Don't click blindly "ok" or "close" on error messages, they might contain essential clues that are too easily dismissed. Error messages are often done poorly but are also one of the main tools we have.
Don't overdo it. It's soooo easy to burn out, be conscious of your health.
I remember my first big screw up, at my first start-up I worked at.
I mounted production server webdir as an sftp mount remotely. Then I remember doing chown -R at some higher level directory locally thinking it surely won't affect NTFS remote system, but boy was I wrong. It caused a one whole day of downtime. Thankfully easy to fix once I figured it out.
My boss couldn't live it down for a week or two, but eventually it dissipated and I earned a lifetime lesson, and nothing really was lost.
Almost 7 years in since my first job as a developer and I did a 7k£ worth of damage at my current company after merging an enormous PR which among others, messed with the production DB. It was so huge none approved it but I got written confirmation from my manager to merge and "see what happens in production". :P Shit happens. It's never your fault, well, unless when it actually is.
They are traps that everyone can fall in very easily and are way more common that it seems. But because they are "bad" they are often not talked about or highlighted.
everybody is equal but some are more equal. try to identify people with ties to hr/ management and try not to step on their toes. no need to be overly friendly, just be careful around them
two people you need to be always friendly with are the facility manager/ janitor and the reception person. they run the place. thats how you get a better chair or get your amazon packages accepted
dont try to suppress your personality for too long, forget about stuff "yeah i would have liked to speak up about <issue> but im just here for a week, i better wait couple month then ill allow myself that" people notice changes in behaviour (mostly as negative), and in two month you will have an established position in the social hierarchy. if you are a loudmouth, be loudmouth from day one. "the new guy is a loudmouth" will get easier pass than "you noticed? bob is turning really arrogant lately/ since his promotion"
some sitting places are vacant for a reason: smelly colleague or malfunctioning ventilation unit blowing cold air at you. choose wisely before you get stuck in there
dont take shit from others, dont overwork yourself or you will be the "he works an hour more anyway" guy
take your time to learn and read and research twice. take notes of everything you are shown and taught about the thing you work on. be it stuff like "you need to kick the server here to keep UPS from failing" or "dont change spaces to tabs in this file, it will break the build" passing remarks like this are the most valuable insider knowledge there is
remember that you are a social animal and so are others. spending an extra half hour joking with colleagues after lunch is done, instead of leaving the table immediately, makes quite the difference
Your first job pretty much determines in what direction your career it's going to go. If you work with tech you like then good for you. If you don't make sure you move within a team that does because your next job will be just an upgrade of what you are doing now, and you better choose the right thing.
> Your first job pretty much determines in what direction your career it's going to go.
This is untrue. Your first job shows you what all the variations in roles actually are in this industry. It isn't just coding. Do the work, take note of what everyone does. And if there is something that you like more than coding, try to learn that.
You have flexibility - nothing is set in stone. Many people change gears numerous times as their career progresses. Don't stress over it.
Started on plain PHP/MySQL, moved to Python/Django, started on Vue, moved to React and Node for one job, did some Angular at another job, learnt some devops at all of them.
The best (and sometimes worst) thing about this career is how flexible you need to be - just ensure you learn the fundamentals. For example if you're doing React/Vue/Node/etc then learn JS rather than learning just the framework syntax.
But seriously, focus on learning from your peers as much as possible. Don't worry about what others think of you or your code. You shouldn't take code reviews personally. Seek objectively simple solutions to problems.
Good luck and may you find fulfillment in your new job!
If you disagree, state that and tell them why. Maybe you know something they don't about why you did something the way you did. Maybe they are just wrong. Maybe there's some business requirement you know that they don't or vice versa.
Also the other bit of not making changes just because they tell you to is this, you need to understand why you're making the change. This way you won't make the mistake again and you'll learn. You may stop doing the thing again if they comment it enough times and you internalize it, but that's not understanding, that's pattern recognition and won't help you be a better dev.
Code reviews are a two way street and a great learning opportunity. Use them to your advantage! :D
* Sit back and learn the culture before you start stepping on toes.
* Value mentorship - learning why things are the way they’re will give you insights into the evolution of the company.
Improve a little bit every day. Honestly this has given me the most returns. It doesn't have to be much at all - find a nicer IDE theme, memorize one shortcut, read up documentation on that command you use a lot but never understood.
Explore things that interest you, not necessarily the one that seems like the next career step. When you're young, your hacker instinct is probably more accurate than most of the data and buzzwords going around.
For podcasts, which aren't always great since they can be distracting, I've been enjoying Bill Burr's Monday Morning Podcast lately. It's absolutely hysterical hearing him rant for a few hours every week.
First day you aren't going to be doing any coding.
You are likely to be doing a lot of admin nonsense, getting your dev environment set up and learning how their source control works / is structured.
After that you will be told to pull something from source control and will probably spend next couple of weeks familiarising yourself with the particular code base you are going to be working on. Don't treat this as an easy slacking off period. Take it seriously. If you are going into a code bases in the 100K+, 1M LOC size then this is a fairly hefty task on it's own to try and understand the architecture / structure.
Ideally they will pair you with someone senior for a few weeks if you are a junior developer.
Do you know what source control they use? If so it's worth getting to know it before you start.
If you are a junior developer, develop a thick skin, you will likely get lots and lots of comments on your code and potentialy a lot of them negative. This is fine, this is expected. Learn from it. Don't end up in your feelings or take it personally.
Be prepared to ask lots of questions, again if you are a junior developer this is totally expected.
What would be nice is to get included in code reviews from the start, look at the comments on other peoples code reviews and learn from them! This will help you pick up the expected style as well, if they have one (and it's not enforced by some auto-formatting).
Shameless plug: I'm starting a newsletter focused on offering career advice for programmers. You'll learn plenty of technical skills in your new role, but my hope is I can teach some younger devs what kind of soft-skills are needed to navigate your career.
Feel free to subscribe here: https://juniortosenior.substack.com/
- once you are there for a few months, take ownership of something (a part of the product, some piece of tooling, an area of support, etc) and become the go-to guy for that. You will be rewarded for it
- ask a lot of questions and don't be afraid to look stupid. People are often relieved when you ask the "dumb" question because they didn't know the answer either
- along the lines of don't be afraid to look stupid, if something is going poorly or isn't going to meet a deadline you have set, ask for help as soon as possible
- take ownership of your own career. no one will give you a raise or a promotion without you asking. Occasionally someone who is an absolute standout will get recognition like this, but it's rare
Good luck
- Be aware of your time. Sometimes, devs can be pulled in many different directions that distract them from what matters.
- Learn and research your company's tools and practices, i.e. Github/Bitbucket, Trello/Asana, scrum/okr's, etc.
- Get your dev environment running. If there are bugs or issues in the documentation, see if you can make a PR and fix it for the next person.
edit: PR stands for "pull request." Adding, since I would not have known this just out of college.
Learn from everyone, there are many different ways of doing everything, don't just follow blindly one person, observe what everyone is doing and choose whatever works for you.
Be always open to improving, learning and becoming a better dev. This is a job that is ever evolving.
Read the error and understand it. Don't click blindly "ok" or "close" on error messages, they might contain essential clues that are too easily dismissed. Error messages are often done poorly but are also one of the main tools we have.
Don't overdo it. It's soooo easy to burn out, be conscious of your health.
Have a great first day!
I mounted production server webdir as an sftp mount remotely. Then I remember doing chown -R at some higher level directory locally thinking it surely won't affect NTFS remote system, but boy was I wrong. It caused a one whole day of downtime. Thankfully easy to fix once I figured it out.
My boss couldn't live it down for a week or two, but eventually it dissipated and I earned a lifetime lesson, and nothing really was lost.
Avoid obscene language or crude humor. Most people tend to smile and laugh even when they feel uncomfortable.
It looks really bad if you have to go ask them something they have already told you.
two people you need to be always friendly with are the facility manager/ janitor and the reception person. they run the place. thats how you get a better chair or get your amazon packages accepted
dont try to suppress your personality for too long, forget about stuff "yeah i would have liked to speak up about <issue> but im just here for a week, i better wait couple month then ill allow myself that" people notice changes in behaviour (mostly as negative), and in two month you will have an established position in the social hierarchy. if you are a loudmouth, be loudmouth from day one. "the new guy is a loudmouth" will get easier pass than "you noticed? bob is turning really arrogant lately/ since his promotion"
some sitting places are vacant for a reason: smelly colleague or malfunctioning ventilation unit blowing cold air at you. choose wisely before you get stuck in there
dont take shit from others, dont overwork yourself or you will be the "he works an hour more anyway" guy
take your time to learn and read and research twice. take notes of everything you are shown and taught about the thing you work on. be it stuff like "you need to kick the server here to keep UPS from failing" or "dont change spaces to tabs in this file, it will break the build" passing remarks like this are the most valuable insider knowledge there is
remember that you are a social animal and so are others. spending an extra half hour joking with colleagues after lunch is done, instead of leaving the table immediately, makes quite the difference
This is untrue. Your first job shows you what all the variations in roles actually are in this industry. It isn't just coding. Do the work, take note of what everyone does. And if there is something that you like more than coding, try to learn that.
You have flexibility - nothing is set in stone. Many people change gears numerous times as their career progresses. Don't stress over it.
Started on plain PHP/MySQL, moved to Python/Django, started on Vue, moved to React and Node for one job, did some Angular at another job, learnt some devops at all of them.
The best (and sometimes worst) thing about this career is how flexible you need to be - just ensure you learn the fundamentals. For example if you're doing React/Vue/Node/etc then learn JS rather than learning just the framework syntax.
Over all don't burn out, put your time in work and learning but also put time in joy and rest.
Programming is addictive and will you a workaholic. Mind your times well.
- be friendly and focus on getting to know your coworkers a bit
- get all of your account credentials (tools, apps, etc)
- ask about benefits/hr stuff/etc
- set up your local environment (just setup)
- again, don't worry about code yet (no reason you should be dropping code - even tests - on day1)
1. Headphones
2. Water Bottle
3. Coffee mug
(You may want to wait on these, they might provide them)
Be:
1. Friendly
2. Open to learning new things
3. Humble
4. Open to asking for guidance
5. But self sufficient when you can.
Good luck!
day-to-day programming is a lot more like carpentry than science...