Help Get Me Going at my New Gig

November 23, 2009 8:17 AM

What are your tips when starting a new job as a software developer? Looking for coding, organizational approaches and social hints as well.

Happily, my way out of this situation was to find myself a new job. YAY ME !

I've read this thread but I'm hoping to find answers specific to development. I'm also going back to a language on another platform and I'd like to ramp up quickly. Any tips along these lines would also be appreciated.

Thanks Green !

posted by sidd.darko to work & money (13 comments total)

Congratulations! I like to spend as much time as I can browsing the company wiki or similar types of documents in the first while on the job. If you guys have a wiki or anything like it, reading it for a while is a good way to soak up some corporate culture and to get a feel for some of the more significant decisions or projects in recent memory, which tend to be the ones documented on a wiki. Beyond that, don't be afraid to ask colleagues for help in setting up a development environment. Depending on how well things are documented there, it may be nigh on impossible to do yourself, and it's in no one's interest to have you guessing which versions of various arcane libraries are required when someone else may have the answer for you.

In terms of going to another language, I'll admit I'm kind of a sucker for the Head First books by O'Reilly. They are sappy as hell, and certainly not pitched at a very advanced level, but they pound various bits of knowledge pretty deep into your brain by playing various tricks with your memory, which actually makes it worthwhile.
posted by zachlipton at 8:32 AM on November 23, 2009

I guess it depends on the specifics of your dev environment and the team you'll be working with, but I recommend getting very familiar with a good IDE. I've found Eclipse (or EasyEclipse!) to be powerful and flexible for a lot of different types of work. There's a lot of value in having all your tools together in one spot, particularly if they're integrated with CVS/SVN/other versioning systems. If you're doing web development like I do, you can grab an FTP plug-in, or for offline stuff see what types of compiler support is available. I'm not a hardcore software programmer, so apologies if this is too basic or irrelevant for your needs.
posted by The Winsome Parker Lewis at 8:33 AM on November 23, 2009

Congrats! I'm pretty soon going to be in a similar situation, jumping into a different environment with a new team (shout out to MeFi jobs!).

Don't be afraid to ask a lot of stupid questions. I'd rather be thought of as a little-bit-slow for the first week, then secretly do everything wrong for months and have that bite everyone in the ass down the road.

Don't be afraid to question things/give technical opinions ('Why are you doing it this way? I've always done it this way.') but do realize you might be wrong and there might be a very good reason it wasn't done that way.
posted by wrok at 8:39 AM on November 23, 2009

Learning a new established codebase is always a challenge. Be sure to ask lots of questions when appropriate to your coworkers. You'll find some people really like explaining things (especially if they are proud of their work). These people are golden because they will happily tell you about the architecture and the rationale (or lack of rationale) for the decisions they made. Keep in mind some people will despise this line of inquire and either explicitly or implicitly imply that all the details are in the source that you have in front of you.
posted by mmascolino at 8:46 AM on November 23, 2009

Sit with one of the other developers for a day or two. Find out how they do things. Do things that way at first. Take notes of the details you will need to keep handy like server names and addresses, coding conventions etc...

Don't act like you know everything.
Even if you do.

Learn the tools they use that you are unfamiliar with.
posted by srboisvert at 9:23 AM on November 23, 2009

Be sure to ask lots of questions when appropriate to your coworkers. You'll find some people really like explaining things (especially if they are proud of their work). These people are golden because they will happily tell you about the architecture and the rationale (or lack of rationale) for the decisions they made. Keep in mind some people will despise this line of inquire and either explicitly or implicitly imply that all the details are in the source that you have in front of you.

I agree with this. There are almost three proverbial types of developers:

1) The one who answers questions in an obscure way that only confuses you more.
2) The one with poor social skills (we'll call him "Aspy") who makes you feel like an asshole for not intuitively knowing all the proprietary things you couldn't possibly have known, having never seen them before. The kicker is, once you do understand this guy's code, it tends to vary somewhere between idiosyncratic and just plain shitty.
3) The guy who will actually explain stuff to you. He's rare, but most companies do have at least one. Find him.
posted by drjimmy11 at 9:38 AM on November 23, 2009 [1 favorite]

Also, I try to keep track of all the little idiosyncratic commands, URLs, snippets and stuff in a little database of my own, so i don't have to constantly re-ask the same questions. Whenever someone IMs me a reusable SQL command or something like that, I paste it into a note.

I use Personal Knowbase for PC, it's a great little tagged-note database. If you're on a Mac, I'm sure there's something similar out there.
posted by drjimmy11 at 9:42 AM on November 23, 2009

nthing take notes. most people in my office don't mind being asked questions. none of them like being asked the same question. i have found installing a wiki on a usb drive works best for me.
posted by phil at 10:14 AM on November 23, 2009

After you've been introduced around, try asking a few of your co-workers out to lunch/coffee to give you background. You'll want to know not just the current state of affairs, techniclly speaking, but how things got that way. Were there other efforts that had been tried and found wanting? Is the current system a replacement for an older system, and if so what was wrong with the old system? If the project is of any size at all, there will be components that just don't seem quite right when viewed in isolation, but might have made sense at the time. Better to get the background first before saying, "You know, it would have been better to do X."

As far as learning a new language or platform, a good book will go a long way. Maybe if you gave us some more details we could suggest specifics. In general, I like books that give good foundational knowledge (the O'Reilly "nutshell" books are often good) and not just cookbook type things.
posted by lex mercatoria at 10:50 AM on November 23, 2009

If you can, make a point of making friends with and vocally appreciating your QA staff. Too many devs either resent or take for granted their testers -- they are there to help you do your job.

Nthing ask questions. You'll maybe look a little dumb in the short run by asking something that maybe seems obvious to the person you're asking. If you don't ask, you'll be wasting your own time, and maybe internalizing the wrong answer.

Hard to give you pointers on in general picking up a new system without specifics on what you're picking up, and what level of experience you already have in it. I always do a couple of toy projects when I need to pick something up. Make a basic object model, add some features, refactor it. Solve some basic problems in that language so when I see those problems solved in other contexts maybe I'll recognize what they are.
posted by contrarian at 12:23 PM on November 23, 2009

These are awesome guys ... Thanks !

A few more data bits .. I'm senior-level, moving from Java to .NET and I expect I'll be doing mostly webdev.
posted by sidd.darko at 12:32 PM on November 23, 2009

if you are moving to .net land i can't recommend r# enough.

depending on who you ask web forms are on their way out. if you have the opportunity i would suggest checking out the .net mvc. the folks behind MVCContrib have made some nice enhancements.
posted by phil at 12:39 PM on November 23, 2009

Transitioning into .Net specifically: make sure you understand the page life-cycle. You will write awful, awful code until it starts to click. Don't get me wrong, it's not super complex or anything -- it's just hugely integral to everything you do in webform/page/control land.

Learn to love Visual Studio, it's one of the (at least) most fantastic IDEs out there.
posted by wrok at 3:11 PM on November 23, 2009