Starting job, how do I establish good relations with my new coworkers?

July 11, 2013 2:12 PM

I'm about to join a startup as a software developer on the 4-6 person tech team. What should I do, right from the beginning, to help make this a good experience all around?

The whole startup includes founders, sales, marketing and customer support people, but my main coworkers will be the four other coders and the CTO. I have less experience than they do with software engineering, and I need to learn from them.

Two of the coders are outgoing and talkative, and have stated they are actively interested in mentoring. One of these, however, appears to get fed up rather easily. What can I do to nurture and protect their initial interest in helping me?

One of the other coders is dedicated to his craft, but he may be rather shy. What can I do to draw him out? Or would it be wiser to let him be?

The fourth coder I haven't spoken with yet, so, any general ideas about meeting new people on the job?

I've spoken most with the CTO and have less uncertainty about how to work with him.

Complicating factor: I'm older and better-educated than anyone else on the tech team, or even in the whole company, but I'm relatively new to software development. Special care seems indicated here.

So far I've memorized the names of everyone in the company (not just the coders) and the personal information in their blurbs, formed a picture of each one's role as they were hired and the startup grew, worked through what the company income statement probably looks like to try to understand the money side, and received a fairly thorough explanation of the company's products and methods in the course of interviews.

The main challenge for me is learning the rather daunting great huge pile of software they use. I've already been working on that, but good working relations are possibly even more important, both as a means and as an end in themselves.

TLDR; It looks like the biggest determinant of future happiness in a new job is working well with four other coders. Any words of wisdom for a new software developer joining a small team?

posted by kadonoishi to Work & Money (15 answers total)

Be outgoing, but at appropriate times (lunch, etc). Ask for help, but try not to do it when people are in the middle of something. Try not to do it constantly (i.e., ask for help after you've been stuck on something for half an hour or if you're absolutely sure someone else knows it and you don't).

There's no special skill required here, really. Try and make friends, be respectful, pull your weight.
posted by tylerkaraszewski at 2:22 PM on July 11, 2013

Smile at them, say hello to them, ask them for their insight into the job and the company and everything else. Listen to them. Do your work and help them do theirs. Bring cookies sometimes. Cookies help a lot.
posted by xingcat at 2:37 PM on July 11, 2013 [1 favorite]

Don't be overly pushy: friendly and polite yes; overwhelming no.

And yeah, speaking as a shy person myself, don't try to "draw out" the shy guy: it's patronizing, it's rude, and it'd be unwelcome. There's nothing wrong you need to 'fix' about him.
posted by easily confused at 2:41 PM on July 11, 2013 [8 favorites]

When I join a new project I expect someone to show me the lay of the land. That person (my mentor) should explain the architecture of the project, explain in detail the code I'll be interacting with first, and hold my hand through my first change (usually a small bug fix or similar). In my experience this takes at LEAST most of a day. Take notes during that day. No one minds explaining something once, especially to someone eager to learn. Twice is sometimes ok, but if you have those first day notes, reading them a week later may be valuable. After the initial hand holding, it's up to you to find a balance between time invested in trying to figure things out on your own and asking someone who probably just knows the answer. The amount you can figure out on your own should go up as your knowledge and experience grows. For at least the first week you will mostly likely be asking way more questions than you think you should, but that is (IMHO) normal.

Given where you're coming from, I'd say make sure someone (and only one) has the mentor role and is comfortable with it. Probably not Frustrated Easily Person (that's a good backup when primary person is in a meeting). I'm not sure about the being new to software development aspect. If the programming language is new to you, know that it's probably very well documented on the web. But if you have questions about why something is designed in the way it is, or a process is the way it is, or even a programming concept, that seems fair game to ask.

As a more experienced, older professional: be professional. Not in the don't-joke-around sense, but in the getting things done sense. Be the guy that finishes tasks without your manager asking / reminding / nudging you about projects. Communicate clearly. In a small environment, I'd also say "try to get along with everyone", but it sounds like you've already got that under control.
posted by Phredward at 2:45 PM on July 11, 2013 [1 favorite]

Don't be afraid to ask for help when you need it, but make sure you make the most of the information you get - e.g. try not to ask the same question / make the same mistake twice. Even if they're not required, ask for code reviews when you are working on something "interesting." This is a good way to show what you know as well as what you don't know. Most developers I know are happy to help a newbie out, as long as said newbie picks things up fairly quickly.
posted by mr vino at 2:55 PM on July 11, 2013 [1 favorite]

bring donuts the first day.
posted by cupcake1337 at 3:45 PM on July 11, 2013

I've worked on a lot of dev teams. I think basic rules apply here; be courteous, respectful, friendly, etc. It's also important when you work with thought workers to be very conscious of interruptions. Nothing is more annoying than someone bugging you when you're in the middle of thinking about a hard problem. To this end, it might be a good idea to ask explicitly, "Can I come to you when I have questions?" and "How would you like me to communicate with you?"

In my office, most people prefer email/IM because it's asynchronous and possible to ignore. Some people prefer in-person chats. Best to just ask.

Beyond that, I would suggest finding one of the more outgoing people and asking to do a day or two of pair coding. Find something (a bug, feature, optimization) that annoys you both and tackle it together. This is the fastest way to get you up to speed and can be a great way to become comfortable with each others' working styles.
posted by annekate at 4:29 PM on July 11, 2013 [3 favorites]

If you are working and you have a question, it's better to try things first, then go ask and start out by saying I've tried X and looked up Y, but I'm still not getting to Z. Much better than just asking How does Z work? Don't spend all day spinning your wheels, but show up with a start to solving the problem.
posted by CathyG at 5:13 PM on July 11, 2013

Related to CathyG's advice -- try to save up as many questions as you can, so that ideally you're asking 10 questions once a day, rather than 1 question 10 times a day. Obviously this will depend on how vital to your ability to continue to work the answer to a question is, but for the non-urgent stuff it may be convenient to just have a standing daily checkin with your primary mentor until you're up and running.
posted by pocketfullofrye at 5:39 PM on July 11, 2013 [3 favorites]

Never, ever tell a developer that you see an error without telling them WHAT the error is.

It's very normal for developers to have a ramp-up time of a couple months before they can pull their weight. To that end, your primary goal should be to learn all their software really well, really quickly.

If you want to practice asking questions, spend some time idling in a popular IRC channel. Don't get caught up in the arguments, but you'll get a good flavor of what it's like to work with developers all day.

I am excited on your behalf— a five person dev team sounds exciting!
posted by yaymukund at 5:57 PM on July 11, 2013

I have been the new junior guy, the experienced coder and the CTO. Nthing what others have said about batching questions, and looking up online first. I'm not the best most patient teacher, but I'm usually happy to answer questions. With that being said, I do get frustrated when said question is something easily or even not so easily looked up on Google. Especially, if the same person has come to me many times with google-able questions. This has resulted in me eventually giving a lesson on how to Google better. Additionally, one bit of follow up you can always ask is, "what resource could I have used to find this out on my own, so I don't need to bug you with similar questions going forward". Obviously, there will always be things you can't look up, so it's best to save your green stamps for those questions.
posted by ill3 at 6:55 PM on July 11, 2013

if i get stuck on a thing that won't let me continue work at all, i'll give myself a deadline, say, 15 minutes, and if i haven't figured it out by then i give up, and either move onto something else or go ask for help. as good as it is to figure stuff out for yourself, it's also bad to spend several hours researching something that could have been solved in 30 seconds by asking someone. it's hard, but you have to find a balance.
posted by cupcake1337 at 9:24 PM on July 11, 2013

Response by poster: Well, folks, that was a pile of useful advice and no mistake. I'm going to act on every single one of these, except for cupcake1337's first one which I suspect was a conscious attempt at eponystericity.

It's tough to single people out, but:

Phredward, mr vino, point well taken about not asking questions twice. That one will be a focus of effort.

Phredward, saving Easily Fed Up Person for a good backup is splendid, I'll do exactly that.

easily confused, thanks for the warning about the shy guy, I might've botched that.

annekate, pairing sometimes would be great, I'll send out feelers.

pocketfullofrye, ill3, batching questions sounds like a good approach.

CathyG, that is a good basic structure for questions.

tylerkaraszewski, Phredward, CathyG, yaymukund, cupcake1337, the specific lengths of time for different things is quite helpful. I'll gauge my pace with these in mind.

xingcat, smiling is pretty darned simple but I'm still going to remember that, and do it.

That turned out to be everyone, didn't it (does it still count as singling people out if you do it to everyone?) _All_ of you had actionable advice. Except for you cookie and donut people, I'm just not going to do that. Cherries, OTOH, I could do cherries...
posted by kadonoishi at 12:09 AM on July 12, 2013

i wasn't kidding. it's a nice gesture. i'm not saying buy donuts for 1,000 people, but your team, however far up it goes, that is reasonable. you'll get a chance to talk to people. they'll want to come by and say hi and thanks for the donuts and you can get to know them.
posted by cupcake1337 at 7:45 PM on July 12, 2013

Response by poster: I stand corrected. Still more of a cherries person though.
posted by kadonoishi at 9:32 AM on July 13, 2013