I've interviewed a guy from IBM before. He insisted on commenting everything and having getters and setters for all of his fields. If you google you can find out why I didn't think this was such a good idea... https://www.google.co.uk/search?sugexp=chrome,mod=11&sou...
Being in a company has a lot to do with how well you get along with people. You're new, and so I suggest that you listen carefully, ask questions about things that you don't understand (otherwise you'll feel like a dumbass next time they bring it up, and you still don't know what they're talking about).
When you've been working somewhere for a while you also tend to dismiss the problems around you. Make sure you note down all of the things that you find wrong about the place - ask people why these things are they way that they are - it could be a misunderstanding on your part, but it could also be that there are genuinely things that need fixing.
Make sure you keep a notepad on you - note down everything that you learn, problems that you see etc - it'll come in handy.
After a couple of weeks you can start acting on fixing the problems that you've seen - if you actively seek to solve problems, then you can become a hero in the company - the guy that made our lives better.
Lastly remember that if you want something you'll have to fight for it. Don't be afraid to disagree with people, but you have to play a fine game when you've just come into the company - you don't want to piss people off, but you also don't want to set the expectation that you're OK with shitty code.
I hope that helps! have fun out there ;)
A co-worker of mine used to work for IBM. He said he commented everything. However, he wrote them in Spanish. So your code comments should be appropriate for the environment :)
> Being in a company has a lot to do with how well you get along with people. You're new, and so I suggest that you listen carefully, ask questions about things that you don't understand (otherwise you'll feel like a dumbass next time they bring it up, and you still don't know what they're talking about).
Definitely do this. If someone mentions an acronym or project, either interject or remind yourself to ask later what it is. Which one is appropriate obviously depends on the context of the situation.
> When you've been working somewhere for a while you also tend to dismiss the problems around you. Make sure you note down all of the things that you find wrong about the place - ask people why these things are they way that they are - it could be a misunderstanding on your part, but it could also be that there are genuinely things that need fixing.
There are a lot of things done because "that's the way they are" and no one questions that. You should probably question why. Sometimes things are done that way because it was the best solution at the time. However, technology and use cases change.
> Make sure you keep a notepad on you - note down everything that you learn, problems that you see etc - it'll come in handy.
You can also make notes about people. Where they are in the org chart, what they're responsible for, who referred you to them, and maybe even some of their info, like they're a fan of a particular football team or something. That info can help you make small talk and fit in with the group faster. You'll meet too many people too quickly to internalize it all at one time, so the notes will help as a temporary crutch (don't be a stalker, and don't write anything you wouldn't want anyone to read). Along those lines, sometimes you just have to initiate joining a group. You can't always wait for them to invite you in.
> After a couple of weeks you can start acting on fixing the problems that you've seen - if you actively seek to solve problems, then you can become a hero in the company - the guy that made our lives better.
This is true. I've seen it happen.
> Lastly remember that if you want something you'll have to fight for it. Don't be afraid to disagree with people, but you have to play a fine game when you've just come into the company - you don't want to piss people off, but you also don't want to set the expectation that you're OK with shitty code.
We have a philosophy where I work called "disagree and commit." There are too many opinions from too many people to ever work out everything ahead of time. Sometimes you have to just say "I disagree with this idea, but I accept we've decided to go this way, and I'll give it 110%." The trick is knowing when to hash it out some more and when to just shut up and get something done. There are many more problems to be solved, and you can't win every battle.
BTW, update me on how it goes. Email in profile.