Ben Riordan emailed me an interesting question a while back and I promised to bring it up here and see what my readers think. Here's his question:
When working with a team of developers what should I look out for / any best practices? (vs. working on projects as the sole developer)
I thought that was a great question. Here are some things that I'd consider looking for - and as always - I encourage my (much) smarter readers to chime in.
- If you meet with the team, what's the mood like? Subdued? Relaxed? Fearful? I'm not the best at reading emotions, but I figure if I can pick up on something, good or bad, than I try to think of what that means for the team dynamics.
- Are there standards in place? I don't care what standards - but are there any at all?
- How are conflicts resolved? Is there a tech lead who decides everything? Or do folks do their own thing? If you have an idea about how to do something - what's the process to bring it up to the group?
- I didn't want to include this because the assumption is that everyone uses source control - but - not everyone does. In a team this is critical. It doesn't hurt to ask ahead of time.
- If the team has remote employees, how are they included in discussions?
That's all I can think of. Anyone else?
Archived Comments
I would ask, how good does the team comment their code effectivly. Can I look at someone else's code and figure out the process.
I think Joel Spolsky did a pretty good job of answering this a few (12!) years back:
http://www.joelonsoftware.c...
@David - There are some who believe that you shouldn't comment your code. The thought is that well-written code is self-explanatory, and that if you feel the need to comment it, that's along the lines of saying, "I realize this isn't as good as it should be..."
See http://butunclebob.com/Arti...
That being said, I wrote some code comments just yesterday. It was in a godawful overly-long function and yes, it was bad :)
In any event, just wanted to offer up an alternative perspective to the notion that code should be commented "effectively".
I would ask to take a look at some of the code honestly. I have been in too many places in my past that once I accepted the job and looked at the code I was being asked to maintain, I thought, "Oh my God, what did I get myself into?"
Teams that practice 'ego-less programming' can be great to work in. The idea being that no-one owns the code, the team does. When there is bad code, it is the teams bad code; when there is good code, it is the team's good code. One symptom of this is practicing pair programming and also peer reviews (as opposed to line-manager reviews) where programmers actively seek review from their peers.
Perhaps asking how code is reviewed might be a good lead in to find out more about the team.
And on the subject of old books, 'The Pyschology of Computer Programming' deals with the subject of teams brilliantly and is over 40 years old! Reading the Kindle addition now (which is far more affordable than the hard copy).
@Brian
I've asked that nearly every place I've interviewed, and I get turned down consistently due to NDA type stuff. And when my job would be to work on internal projects or projects that haven't yet been released to the public, I'm not even allowed to see the application.
I understand their reasoning, but it still makes the decision that much harder.
How about... is there a specific matrix for evaluating progress on a team basis? individual basis? Is there a way to know if I'm meeting expectations or not.
I think Joel's list is a great starting place. If they are missing many of those - red flag.
I'd also ask is there really a 'team' ie - do several people work on one project- or are there silos - each developer works on one project.
@ Dominic Watson
I agree that "ego-less" teams are a lot of fun to work on. However, they don't appear to be the norm. In fact, the opposite seems to be (the norm). I have worked with far more programmers who think sharing knowledge with teamates lowers their job security. I want Team guys/gals around me, not the soloist!
@ Jim Priest
Unfortunately, I have seen more of the dreaded SILO approach than a true team approach.
"Do programmers have quiet working conditions?" - I listen to quite a lot of loud music when I write code... on rare occasions I need it quiet, but generally I can't work in the quiet, I need to sing and drum on the desk when I code.
"Do you use the best tools money can buy?" - There are lots of free and open source tools out there, so I suppose he's not wrong but it's not all about money.
I agree with most of his points but Microsoft running on 12 points isn't a good selling point. Look at Internet Explorer and Windows Vista.
"Do programmers have quiet working conditions?"
I do now! I bought earbuds and have a huge library of euro metal to keep it quiet.