Don't believe anything management tells you about raises or promotions. They always over-promise and under-deliver. Count on needing to switch jobs to get more money.

In that same vein, don't believe any crap that the bosses say about your company being "family". It's pure manipulation. The company has no loyalty to you.

Don't put in overtime to meet arbitrary deadlines. If the production system is broken, sure, fix it. But if someone wants you to lose your weekend so that the project can meet any arbitrary deadline, forget it.

"We'll do X later" means "We'll do X never". There's always talk of having more time after the immediate priority is taken care of, but there never is any slack time after delivering a project.

Never talk to your manager about spending time dedicated to refactor code. They'll always say no or say you can do it later. As mentioned before, later means never. Refactor as you go and don't talk about it with management.

This may all sound rather cynical, but this is what I've learned over my nearly 20 years in the industry. That said, I have always had good relationships with my managers... I have just learned what works and what doesn't.

I don't think thats coming off as particularly cynical. Feels like the cynicism would come from not following this kind of advice and getting resentful/ burning out. Anyway thats all really excellent advice thank you for taking the time to share it!

Oh, it's definitly cynical, but it can also be correct.

Certainly there are some companies that work like this, and others that do not. Your experience will likely vary from one place to another.

Except the bit about family. It's a job, not a family. These are your coworkers, not your family.

The company may not have loyalty to you, but you're coworkers and managers might. Relationships matter greatly.

In the same genre, Human Resources are not your friend. The key word there is resource.

Well let’s not pretend that the employee has any loyalty to the employer either. In a second either party will drop the other at a better opportunity.

My simple advice... Your attitude is everything. Be open to learning and doing anything that needs to be done. Be a team player. Offer to help team mates. There is no time for that perfect solution. Always think big picture before digging into details. Find the one guy on the team that knows pretty much everything about the product/code and study his ways.

Every job is a game. Life is a game. Learn the rules.

By which I mean every circumstance is different. Every coworker, every manager, is different. Pay attention and figure out what actions get stuff done. Which people get stuff done.

For example in a small company if you need a new laptop, you just ask someone. In a corporate space you need to be in a budget, so planning far ahead is important.

Some managers like lots of feedback. Others don't. Some companies are cheap, others are generous. It's a game - learn the rules. It's no good being a football player in a baseball team.

All advice is wrong some of the time, because everything is contextual. Your job is not to write code -- code is the easy part. It's to hold enough context in your mind to solve the problem given to you and to balance all of the competing constraints, and then to encode that solution.

Hahah. I have a whole blog for that, with over 4 years of blog posts covering various aspects.

But my one liner is: "Don't be afraid to ask questions."

https://letterstoanewdeveloper.com/

(Wrote a book too, but the blog is free.)

PS Congrats! Getting the first job is the toughest.

When you make a 'prototype' spend more time filling in the gaps and making it halfway production ready (decoupling, documentation, nice-naming etc). Assume ti's going to be reviewed by a psycho. That way if it suddenly becomes flavour of the month and someone says the fatal line of 'wow! that looks awesome! Let's look to getting that spun up on the cloud layer!' you can breathe a quiet sigh of relief and know that most of the hard refactor is already done. Also your colleagues will buy doughnuts when you tell them you did this.

If you're asked to estimate a task in real terms (days/hours/minutes) and not rough estimates, over estimate ALWAYS. It suggests that the technical understanding isn't there for the project planning so when things go wrong and you say you need more time you'll find real friction. Similarly if you are estimating in rough times or even better Fibonacci scales then you are likely to be in an environment that will accept delay because of unexpected findings... CHECK THIS THOUGH, if you don't want to ask, ask or listen out for what happens when something goes wrong and timescales slip, cos they will.

Make friends with people that you enjoy spending time with, but if you are working on something complicated, try and find a coding buddy who doesn't think like you (as long as there isn't actual tension). Threshing out ideas with someone 90 degrees to your perspective can lift weird and wonderful rocks.

Never trust your instinct, but listen to it ALL the time. Remember correlation is not causation but something is making you think you should look. The more you look the more you'll feel an understanding for something so follow your instinct, but learn on your own terms.

Many things never get renamed when they should do, so just because something seems sensibly named and it's behaviours are beautifully documented, don't entirely believe it until you've passingly proved it.

Any business that isn't honest about wanting to earn money off your work is lying to you and sometimes worse, themselves. Those that are honest about this are (in my experience) easier to work for, as your expectations on what you need to deliver are so much more obvious (money for the business) rather than some fluffy nonsensical indefinite esoteric concept.

oh and as for advice on good/bad coding behaviours, I'll be honest that should be described for you by the coding standards for that piece of work, or project, or entire company. If it isn't then that smells in it's own right and for your own sanity go looking for a coding standard to hold yourself to.

Go to the staff nights out and get to know your colleagues.

Learn how to ask great questions in a way that generative. This will help you catch issues early. To do this pay attention to people asking great questions that are well received and surface issues without causing a lot of tension. Break them down to understand why they’re effective

You will find that there is plenty of negative commentary about software development. Ignore all of that. Remember that you are in a job which seems magical to most of the people who do not code. Yes, this also includes your managers. Enjoy being in this position. Enjoy the thrill of figuring something out no matter how small it is.

My tips:

The less state (mutable variables) you have in a solution, the less you will have to hold in your head when trying to debug it.

Don't make jokes about peoples' names; the risk outweighs the reward.

If you have a "dumb" question ask it. Odds are you're not the only one wondering and that will actually make you look smart.

Keep an open mind because there's lots to learn. Don't worry too much about "specializing" in a particular area. Keep pushing yourself to get better. Make sure you're having fun! If you're not having fun for a while (all jobs are boring sometimes) then it's probably time to find a new job.

Try to learn from everyone, even people you don't like. Reactions, consequences, planning and outcomes tell a lot. Always look for what's actually right for your product and then what's good for the team. Take time to think about your feedback and don't give it instantly.

Congrats on the full time gig. Be aware it can go away.

That's a risk. Risk costs money. Aggressively save for the first while until you have 6 months of income as liquid investments.

Ooh nice. Thats a good one : )