Going to start my job next month as a "developer". First ever job straight outta college, things not to do ?

Take time to figure out what the company's accepted practices are and follow them. We have a couple of bootcamp grads that we have to work with in our company and it sucks because they never read the development flow document and they just do whatever.

Dont be kind and easy going or the seniors will throw everything at you. When you refuse use reason for that and don't throw a no without anything.

Don't give a shit about others your CV shows you are a fresh graduate, they must treat you like that unless you prove otherwise.

Last but not least, it's your first experience in the real world try to learn from it and don't be a quitter

Best of luck

According to @bittersweet everything is allowed. You can even code naked and stoned while taking a shit on your boss dog.
But then I often read that you shall not deploy on Fridays.

Confucius says, big ears, small mouth.

@Wombat I never go full nude, just underpants. And I'm never stoned... just MDMA and LSD.

@techno848 So I don't know if you should take advice from me, but:

1. Try not to fuss too much about things being done differently compared to practices you've learned in college. You might work with high school dropouts who seem to do things "wrong", even though their solutions might be brilliant.

2. Your boss will not grade your code. Your boss only looks at deadlines and functioning buttons. Your team (and future you) will grade your code. This causes tension. Learn to deal with that tension. Learn to balance refactoring with fast deployment cycles.

3. Learn to communicate often, in detail, and professionally. More so than in college, everyone expects timelines and estimates, refinements and updates.

4. Most colleges teach you all about algorithms, patterns, CS theory, UML, testing, etc -- but some colleges teach you poorly about common tools and processes used in businesses. I've had college graduates sitting in an interview who had never used git. But many employers also expect that you can install Apache/Nginx, have worked with some platform services like Jenkins/Codeship/Bugsnag/Sentry, know a thing or two about Agile/Scrum, maybe you have to learn about Docker, etc. Find out what tools your company uses, and get familiar with them.

5. Say no. A lot. Learn to say no in a friendly way. Don't take too many responsibilities, redirect people to other people.

6. The things you say yes to, make them happen. If you can't make them happen in time, report about the delay/block quickly and honestly.

1) Take breaks. Don't code for too long in a single sitting.

I have wasted hours to find a bug, only to take a break, return from it and fix things within 10 minutes. Soemthing I learnt in the first month itself, the hard way.

2) Don't refer to the existing code of your company, if you're fixing it that means you are supposed to write better than it actually is currently. And it's broken. Again, I wasted hours because I wrote code that broke because I referred to existing code. Ask someone who knows better.

3) If it ain't broken, don't fix it.

4) Test properly before requesting a merge. I got my broken code merged, because I skipped parts while testing it.

1)If your colleagues have time ask to do a pair programming session every now and then, on code you have ti bug fix or new features you have to develop.
Change up who you pair programming buddy is, different people will be experts in different things and will think/code in different ways.

I learn a bunch that way.

2) don't be afraid to ask for help, it's a new environment. Don't stay stuck on a problem for too long

3) learn from your mistakes. You'll do a bunch of then some small some big, just make sure it's always a different mistake never do the same one twice.

@BugsBuggy at item 4, testing: yeah, it's so tempting to skip this because "that can't possibly have unexpected side effects". You have to know the system extremely well for gauging that, and even as experienced dev, that will go wrong if you are new to the project.

i loved the points 5 and 6 thanks :D

@bittersweet

oooh, i usually follow that first point, if i am stuck i take a break and sometimes that works :D. how can you begin to fix something which is not broken? heard that at alot of places ca you elaborate a bit ?

@BugsBuggy

@techno848

You might know the book "Clean Code".

In my opinion, the sequel "Clean Coder" might be even more important, it deals with all the team interaction elements of businesses, how to behave professionally, how to communicate with bosses and clients, how to handle pressure, etc.

I don't agree with all the points made in that book, but I think it's still very useful because it makes you think about the social side of being a developer.