Be humble. You're not the smartest dev in the room. I was guilty of this in my early career.
Related to this is realizing that most software degrades over time, being touched by many people under varying deadlines. Assume best intentions of your teammates until you _know_ there's a endemic problem.
Read code. Don't despair if you check out some cool OSS project and a lot of it is going over your head: pick another project or start consuming the code in small chunks.
Don't engage in bikeshedding.
Don't be an asshole.
Always be able to explain _why_ you: picked that solution, developed it that way, favor X over Y, etc. Explain your thinking.
The "right choice" is typically right at the time the decision was made; time will usually erode that "right choice" until it looks wrong.
If possible, document the reasons why critical/large decisions were made in the project/codebase (e.g. "we had to do this like X since system Y wasn't compatible with system Z at the time of writing").
Think of the next developer to touch your code. Think of you touching your code 8 months from the time of writing. Both will help you documenting the "whys" of your strategies if it may not be abundantly clear.
Follow coding conventions of everyone else at your company; don't try to buck the standards.
Don't be cynical. Don't be a source of constant negativity. Those people suck to work with.
Find programming forums/message boards and consume at least a few times a week.
Don't obsess over picking the "absolute right solution", pick the one that sucks the least given the information on-hand at the time. If it's a big choice, document why you made that choice.
Do not burn out. If your company commonly features "death march" projects, seriously consider leaving. I suffered a nervous breakdown around 5 years into my career by working 60-80 hour weeks for months on end while dealing with veiled threats about all our jobs. This was during an economic downturn and an especially hard time to find dev jobs, but I still think it would have been better in the long run to leave. I believe our company, knowing the tough local market for devs, intentionally grossly overpromised on a deadline to a huge customer because they knew many of us wouldn't have many options. I probably made less than minimum wage that year, never did the math.
Related: in many cases, the company is not loyal to you at all. Do not devalue yourself for loyalty to your company.
Always, always give credit where it's due. Never take credit for another's work or ideas.
One of the best things you can do for teammates is relieving them of stress and sharing the burdens; leave no one on your team behind (metaphorically). This obviously depends on how close-knit your team is, but there were many times I stayed late to help a close teammate with a production problem that technically I wasn't directly involved with. When they did the same for me, I was very thankful to have that other set of eyes, the person to discuss the problems out loud. I know together we solved those problems quicker, to boot.
Related to this is realizing that most software degrades over time, being touched by many people under varying deadlines. Assume best intentions of your teammates until you _know_ there's a endemic problem.
Read code. Don't despair if you check out some cool OSS project and a lot of it is going over your head: pick another project or start consuming the code in small chunks.
Don't engage in bikeshedding.
Don't be an asshole.
Always be able to explain _why_ you: picked that solution, developed it that way, favor X over Y, etc. Explain your thinking.
The "right choice" is typically right at the time the decision was made; time will usually erode that "right choice" until it looks wrong.
If possible, document the reasons why critical/large decisions were made in the project/codebase (e.g. "we had to do this like X since system Y wasn't compatible with system Z at the time of writing").
Think of the next developer to touch your code. Think of you touching your code 8 months from the time of writing. Both will help you documenting the "whys" of your strategies if it may not be abundantly clear.
Follow coding conventions of everyone else at your company; don't try to buck the standards.
Don't be cynical. Don't be a source of constant negativity. Those people suck to work with.
Find programming forums/message boards and consume at least a few times a week.
Don't obsess over picking the "absolute right solution", pick the one that sucks the least given the information on-hand at the time. If it's a big choice, document why you made that choice.
Do not burn out. If your company commonly features "death march" projects, seriously consider leaving. I suffered a nervous breakdown around 5 years into my career by working 60-80 hour weeks for months on end while dealing with veiled threats about all our jobs. This was during an economic downturn and an especially hard time to find dev jobs, but I still think it would have been better in the long run to leave. I believe our company, knowing the tough local market for devs, intentionally grossly overpromised on a deadline to a huge customer because they knew many of us wouldn't have many options. I probably made less than minimum wage that year, never did the math.
Related: in many cases, the company is not loyal to you at all. Do not devalue yourself for loyalty to your company.
Always, always give credit where it's due. Never take credit for another's work or ideas.
One of the best things you can do for teammates is relieving them of stress and sharing the burdens; leave no one on your team behind (metaphorically). This obviously depends on how close-knit your team is, but there were many times I stayed late to help a close teammate with a production problem that technically I wasn't directly involved with. When they did the same for me, I was very thankful to have that other set of eyes, the person to discuss the problems out loud. I know together we solved those problems quicker, to boot.