I was recently hired at a software shop. This is my first programming related job and I was wondering what things I need to do to get into the groove of the new job as quickly as possible.
What tips do you have for a smooth transition into a working environment.
Ask plenty of questions. Don't just sit there scratching your head.
Make sure you're familiar with the software they use (versioning system, IDE and so on). If you're not and they are freely available, download them and have a play with them at home.
Your initial tasks will probably be small bug fixes - this is your chance to get to know the codebase, so pay attention to the surrounding code, the style and so on.
Try and be sociable!
Keep an open mind. The best way to get tagged as a "troublemaker" is to constantly compare what you're doing now with how it was done at a previous job, hobby project, etc. For instance, if your new workplace uses CVS, don't keep moaning about how much better Subversion would be.
Even if you're right - especially if you're right - now is not the time to "rock the boat."
I would e-mail your boss/recruiter and ask them the following:
Your goal should be to really become familiar with the company before you start and get a feel for any tools they use that you may not know a ton about.
On my most recent project, I got access to the business requirements document and additional resources about the technology before I started. It was helpful in terms of ramping up, and I'm sure you can apply the same strategy to your job.
Most importantly, stay relaxed and focus on demonstrating that you are a good asset for the company to leverage.
If your new job is anything like to new one I started a couple months ago, you've got a lot to learn. Reading as much code as possible helps, or even better, reading others reviews of code. But I find I learn much more quickly if I'm forced to. I would encourage you to volunteer to fix as many bugs as possible (and resist the temptation to lobby to work on a new project, if you have a choice). Fixing bugs in legacy code will force you to read and learn it, and you'll also earn the respect of your peers.
If you don't know something, 1) Search on Wikipedia 2) Google it 3) Search on Stack Overflow 4) Ask your coworker. 1) to 3) shouldn't take longer than 30 minutes.
This way, It'll take longer for your coworkers to hate you for asking too much.
P.S. I've had a senior software engineer under me, who blamed me for not teaching about something new to him, which I already knew, even if I pointed him to the introductions page. It was quite embarrassing.
Be a self starter - the best employees I have ever had are the ones that I don't need to manage very much.
First find out what it is you need to learn and what your bosses expectations are. Then sit down and make yourself a plan on how you are going to learn what you need to learn, and how you are going to exceed your bosses expectations. Then set out to achieve your plan.
Don't wait for someone to show you something, actively try to learn it yourself. Ask for help when stumped, but ask specifically targeted questions that a coworker can answer in a short amount of time, and then get going on your own again.
Strike up hallway conversations with senior developers about architecture, and don't just treat it as them lecturing to you - you should take the opportunity to ask them to critique thoughts you are having about the software.
Besides the standard stuff that applies to any job (e.g. be on time, don't dress like a slob, don't spend all day surfing the web(whoops)), I would say to familiarize yourself with how things are done and refrain from rocking the boat, especially over small stuff.
For example, before my last job, I always did:
if()
{
}
but there they did:
if(){
}
at first, I would change it to my style whenever I edited code, till I realized that it just mad extra work when checking in windiff before checking in.
Here's a link to a blog post on randsinrepose.com called Ninety Days.
Here's an excerpt:
Your first job is to relax. Like the first day of school, you’re going to overcompensate in your first day, your first week. Most people do not lay their clothes out the night before they go to work. You’re doing this to calm yourself. Those clothes neatly laid out at the end of your bed are a visual reminder that you have control over this thing that you can’t control.
Relax. There’s an industry standard regarding the amount of time it takes to make a hire and it’s ninety days. New managers hate when I tell them this because they’re so giddy they’ve got a new requisition and BOY WATCH HOW FAST I CAN HIRE. Yes, yes. I appreciate your velocity, but I’m not going to worry about your hire for ninety days.
This chunk of time applies to your new job as well. You’ve got ninety days — three months — to finish your job interview. Draw an a X on a calendar ninety days from now. Make it a physical act that reminds you to relax and to listen rather than fret about what you don’t know. The new team isn’t going to trust you until you stop laying out your clothes, until you stop being deliberate.
Good Luck!
In the first instance, I'd suggest doing some work and not goofing around on StackOverflow.com ;-)
Set up your own task tracker software (I recommend RT from BestPractical) and keep a detailed private log of everything you've been asked to do and everything you do to accomplish it.
Besides practical issues (such as dress code, work hours, logging your work, and so on) do not hesitate to take on whatever task you are offered.
Generally people will offer you documentation, testing, debugging or even "string replacement" tasks just so that they can understand the way you code and you get started with all the projects running in the shop.
And yes, asking too many questions without bothering to lookup for answers to common problems in the internet or demanding changes to a project without even knowing its background / budget is also quite unpolite.
The key word for the first few weeks: 'Observe'.
Understand the processes in place without questioning them. Learn the development practice. What is the version control system? How they do reviews? How the testing team is integrated with development? Does development and testing get along? Do they see each other frequently? How the different teams get along? What are the conflict-resolution mechanisms in place?
Eat lunch with different people. Get to know the people. Ask lots of questions. Come early. Leave late. Observe the working habits and routines of colleagues and teams. Understand the culture. Read company documents/wiki/newsgroups. Know who-is-who. What is the reputation of senior executives. Most importantly: dont base your opinions and observations on feedback from a select group.
You will have plenty of questions. Just make sure you try and batch some of them and write them down, so you can ask them all in one go, rather then firing them piece meal one-at-a-time.
Make sure you do your own investigations first though - don't ask questions you could have found out in 10 seconds by using Google's "I'm feeling lucky" button...
That way, you also have some more ammo/info to work into your question if Google doesn't provide you with some answer.
Being that your new to the job and the area of expertise (as far as professional jobs go) I think they'll understand to a certain degree that you might not 'get' everything right away; So don't be discouraged easilly!
If they give you a tour of their facility and introduce to people make notes on who you might like to sit down and discuss the work environment with. It would be a nice idea to get suggestions/views from a variety of employees that will be working in the same area as you. If a tour isn't one of the first things they give you, I would suggest it be the first.
Ask for some technical documents or code that you should read to gain some familiarity their completed/on-going/planned projects in order to adapt to their particular programming style and way of thinking. Don't hold of asking any questions (after doing a reasonable amount of searching around, of course).
Plan in some self-learning. Sit down and watch webcasts (if available) regarding the particular applications you're using to develop. Whitepapers, technical books, etc. would be good also. If you have regular meetings, don't be shy and offer some of your insight if possible. Even if it won't be a direct help to the problem at hand, it may show them that you aren't afraid to be open and share your knowledge whenever possible.
Make friends with your superiors and win over your co-workers. Try not to be set in your ways. If you believe your way to be superior and should be used in a current project, write a paper/essay detailing why. You may get bonus points, even if they decide to not use you idea anyways.
Most importantly though (IMHO) is to always be willing to learn, even if you have no interest or use for something currently. It may become useful in the future or you may be able to suggest a particular solution for problem elsewhere down the road.
Do something odious that everyone else is avoiding, even if it is menial and beneath you.