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...
