.NET Zone is brought to you in partnership with:

Software Developer, Mentor, Architect and UX/UI craftsman. Also, a psychology nut that loves curling. Zac is a DZone MVB and is not an employee of DZone and has posted 66 posts at DZone. You can read more from them at their website. View Full User Profile

A Developer's Guide to Starting a New Job

11.12.2012
| 7669 views |
  • submit to reddit

Starting a new job can be an anxious and exhausting process for most individuals. Fold in the high expectations of a technical position and it can be consuming. Starting at a new company is a difficult balance of building relationships, keeping up, asking the right questions, and meeting expectations. Unfortunately, multi-tasking in a new environment is difficult if not impossible. The amount of information absorbed in the first few days can be overwhelming. The following is a list of tips and tricks for a successful first week.

Be On Time or Slightly Early
Don't be late. Plan the route to the new company ahead of time. Have a few alternative routes in the event of traffic. Obtain a contact number to call in case of an emergency. Do not arrive too early as this can also fluster people.

Dress For Success
Always dress up on the first day. Regardless of recommendations, it's better to be safe than sorry. First impressions are everything. No one remembers the guy that overdressed, but everyone remembers the slovenly dressed programmer. After the first day, clarify the dress code with an immediate manager.

Be Social and Personable
Get to know people at the company. Being social can be difficult for programmers but it is key to building good relationships. If needed, build a list of boiler plate discussion ideas. Finding common ground is imperative to breaking the ice. Do not pass up on invitations to lunch, company activities, or social gatherings after work. These are all excellent networking opportunities. Don't forget to smile, be positive, and have an open mind.

Build a Comfort Zone
After the first day, bring in a few personal items, if possible. Personalizing one's desk with a picture or positive memory can help during difficult times. Introducing a small game such as a brain teaser, which developers love, is another great way to break the ice.

Don't Be Too Proud
Many programmers are too afraid of looking bad. What most don't know is that they are expected to stumble in the few first days. Don't be afraid to ask questions about programming, HR, or other concerns. No question is too obvious. Also, don't hesitate to write down instructions or questions. This will naturally decline as comfort levels increase. Individuals who do not document anything may be perceived as cocky. Taking time to ask questions is better than doing something twice.

Go The Extra Mile
Recognize that early in a new job, one may need to go the extra mile to shine. A new job means proving oneself all over again. A good resume and/or interview may have landed the job, but the longer-term interview of "keeping the job" now starts. Don't get disappointed by this; consider it a healthy challenge.

Don't Be Too Aggressive
Suggesting new ideas should wait for the proper forum. Be sure to exclude any "at my prior company" statements. It's important to introduce suggestions delicately. Behind every line of code is a real person with feelings. Although code might seem old or lost, every line had a purpose at one time or another. Never prejudge people or code.

Get To Work
Identify specific initial tasks with an immediate manager. Jumping into code as soon as possible is great for new staff. Take time to explore and attempt to comprehend programming structures and business concepts. When crossing an unfamiliar programming language or vendor product, notate the area for a later deep dive. It's important to become familiar with all tools necessary for the job. Some companies may dedicate time for this, but acknowledge this may need to be completed after hours.


And lastly... Don't forget to step back and breathe from time to time.

Published at DZone with permission of Zac Gery, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)