So many people fail to realize the fact that 95% of all programming occurs off the keyboard. Most people think we just sit and type all friggin day. Programming is actually an extremely taxing cognitive task which requires a certain state of mind. This is why teams who co-exist in a friendly, challenging, supportive, and inspirational environment tend to excel. This is also why I think that all programming companies should get out of the 9-5, 5 days a week mentality. Good programming isn’t something you just turn on and off when you come and go from work. Good programming requires a clear and active state of mind, and often a great deal of inspiration.
As Steve implied, typically when interviewing for a new job, the company’s own interview process has you talk to only the hiring manager, plus maybe 2 or 3 of your prospective teammates. The personalities of the remainder of the teammates, then, are unknowns until after you’ve accepted the job.
I agree; it’s a concern. Nobody seemed to like my interview strategy suggestion:
http://www.codinghorror.com/blog/archives/000226.html
And the lesson is work on your own!
True as far as it goes, but working alone can also be a barrier to personal growth:
http://www.codinghorror.com/blog/archives/000890.html
When you quote someone else, is it cool to insert links in the quote to your own writing?
Interesting; I don’t think of it that way. I’d never insert actual words in a quote (thus changing the essential nature of the quote), but I view hyperlinks as a flexible meta-layer on top of the writing. For example, I might link Bruce’s words to a Wikipedia entry further explaining what he means.
I found that you join a team at a very small company of 5 or so people who have been working their for 8 or more years, they general have no people skills. Such isolated teams become snobs.
When you work at a bigger company with atleast 100 employees, you can’t afford to look like a snob because then everyone will hate you no matter how smart you are. And for every smart snob there is another smart humble person.
kashif
When you quote someone else, is it cool to insert links in the quote to your own writing?
Interesting; I don’t think of it that way. I’d never insert actual words in a quote (thus changing the essential nature of the quote), but I view hyperlinks as a flexible meta-layer on top of the writing. For example, I might link Bruce’s words to a Wikipedia entry further explaining what he means.
Linking to definitions is one thing, but linking to opinion articles is another, especially since you’re quoting a blog post, and readers expect blog posts to contain links. Ask yourself: What would you have done differently if Bruce’s original post had actually contained a link to your site? What if Bruce had linked the words “young business” to a blog post with a totally different take on the topic?
Inserting links that aren’t purely informative is IMHO a very minor sin — and IMHO not a sin at all if you’re inserting them in a quote of a dead-tree book or other obviously linkless source — but it’s a sin that could have been completely avoided in this case much more elegantly than Jerome suggests:
Bruce Eckel deftly identifies (link)the root cause of all software development problems(/link): that the software industry is (link)too young(/link). (blockquote)
companies hire people that are jerks, and hide them from you in the interview process only to be unleashed after you accept an offer
No wonder you work for yourself! If you start out antagonistic and defensive, if you start out thinking everybody hates you then everybody will. There are always difficult people to work with, I do my best not to be one of them. I also accept that I’m not perfect and no-one else is, anyone can have a bad day. Have a look at http://mooseonthetable.com too. I’ve worked in a lot of environments that match the one described in the fable.
Slightly off-topic. A good defence against open plan is headphones. However, one of the things they talk about in “Peopleware” is that listening to music isn’t the best thing to be doing when you are trying to solve certain classes of problem because the parts of the brain used to attend to music and solve them are the same. I usually notice this when I’m working on refactoring or moving chunks of code about to make it cleaner. I use Dan Gibson’s Ocean Surf, which is a recording of waves breaking on a beach, to blank out the background noise in a way that doesn’t engage my music centre.
Also thanks to Dave L for the link to Programmer’s Stone - I’d forgotten about it.
Thanks, Jerry - the “loan” was just down the hall to a bright newcomer I’m mentoring, but she has had it for months. “Secrets” is one of a handful of books over the years that I’ve kept several copies of and handed out - time to restock!
I’ve lent my copy of “Secrets of Consulting” to a friend so I can’t check the exact quote, but my memory is that Weinberg’s point is that if you’re asked to act as a consultant (which he defines as providing advice at the asker’s request), it’ll be because of a people problem - that technical problems can be solved internally.
This is unsubtly different from simply saying “It’s always a people problem” in all circumstances.
IMHO.
Your mileage may vary (I’ve only been doing this since 1967)…
David is right. I feel understood. (and not just by David, but by others on this thread)
When someone asks you to help them solve a problem, they’re usually pretty desperate (especially if they’re ego-centric programming types). Their desperation in itself is a people problem. Working in desperation is not generally the best mode for solving problems (in spite of the hero-image that some of us like to cultivate).
As David also says, he’s been doing this since 1967 (and I’ve been doing it since 1956). We make our living based on this insight. Ignore it at your peril, but if you do, it’s more business for us.
One more insight, for David: Don’t lend your copy of “Secrets of Consulting.” Make them buy their own. Evidently, few people return their borrowed copies–another people problem.
“As Weinberg said, it’s always a people problem. If you aren’t working with people you like, people you respect, people that challenge and inspire you-- then why not? What’s stopping you?”
Uh…
Rent
…and they don’t take platitudes in exchange for food at the Safeway…
I have to agree with Jeff. I am fortunate in that where I work (a fairly small development outfit), all of the developers get on well together (inter-team as well as intra-team).
One thing my company does when hiring new staff is to have a ‘pub lunch’ with the prospective hire before an offer is made (usually after having had a 2nd interview). This allows them to meet a broader range of the people that they would be working with and in a slightly more informal setting. We have found it to be a successful way of ensuring the people hired fit in with those already here.
If only someone would just pay me to assemble my dream team!
I guess there’s always the lottery. . .
These kinds of posts are why I keep reading this blog. I’m new to the dev career, starting from a team of basically two people that has grown into about 5. Every time we add someone knew, there’s this weird trepidation… I didn’t realize why until #4 tried to bullshit me and we ended up in a fight. Cost me at least a week of productivity. And to this day, he’s still filing bugs on my code that have to be closed as wontfix. Methinks he will get reassigned soon…
I’m glad people like Einstein, Beethoven, the Write brothers, Columbus, etc. stayed true to their own vision instead of letting the majority (other team members) erode it back down to where they fit nicely into a team environment. I fear that while much ‘good’ can result from a thriving team-environment and warm fuzzy relations with other teammates, there is some (maybe much) ‘greatness’ that is lost. People, don’t ever lose your allegiance to the greatness that is within yourselves. Don’t sacrifice something you know to be right for what the rest of the team wants. The majority vote is not always the correct one. We need more people who are willing to risk being the jerk who doesn’t fit in to the team in order to achieve the greatness that we are capable of.
There are two more factors that compound the problem in tech:
-
Few engineering programs emphasize team projects, and those that do rarely provide any training for how to deal with typical team situations. People leave college without a toolkit for interpersonal work relationships - and sometimes with self-propogating stereotypes of the challenges of working with other people.
-
CS tends to attract people interested in working alone, or who have a preference for working with machines. At it’s core it’s not a field that initially attracts people for their social skills.
I don’t buy that the problem is the age of the industry - working in teams is hard everywhere.
Quote: “And job satisfaction, based on my work experience to date, correlates perfectly with success. I have never seen a happy, healthy, gelled, socially functional software development team fail.”
Erm, what kind of crack are you smoking today, can I have a piece?
Your statement has it backwards, let me correct it for you:
“And lack of job satisfaction, based on my work experience to date, correlates perfectly with failure.”
See?
I do agree that teams that don’t work on a social level won’t
get shit done. But I *strongestly disagree that “happy” teams
guarantee success to any degree. If that would make the slightest sense then companies would be hiring “groups of friends” instead of
"skilled individuals".
Furthermore I have seen a lot of “happy” teams fail awfully.
It’s a pity but a bunch of idiots who totally like each other
will not deliver significantly better work than a bunch of
idiots who totally hate each other.
We had all complained frequently about the poor attitude of the bad apple. But, as management told me, he gets things done.
I’ll never forget how nice it was to go to work after he was laid off. The productivity and cohesiveness of the team went through the roof.
On the bright side I learned more about team dynamics at that job than I could from any book . . . even Peopleware. That said, if you haven’t read Peopleware follow Jeff and Joel’s advice - read it.
There are lots of useful comments here. After reading all of them I thought wait, did anyone say ‘trust’? And I grepped the page, and indeed no one had.
On my dream software team, the single most important thing to me is that everyone trusts everyone. Each team member is good at different things, and the benefits of that can only spread if there’s trust.
Personality and drinking-compatibility are valuable, sure, but not necessary. But it seems that most of the negative phenomena in this thread could be chalked up to distrust, and most of the positive ones can be realized through trust.
If you took me to bar you wouldn’t know anything about me except that I dislike bars and people who need to drink or smoke in order to socialize.
And if you don’t need to drink in order to socialize then what are you upto? Are you trying to get me a little bit drunk so I might reveal something I might’ve not otherwise have told you? How could I possibly interpret that as you being a potential friend?
Approach I prefer is to go through what you like to do for fun (drinking/bars, pr0n not qualifying as they are too generic), what are you good at doing and if time allows show and attempt to teach me some of that. And show your what weird/crazy/funny stuff you like looking/reading in the internet or the games you play, whether it’s in youtube, sa or wherever.
Certainly that doesn’t tell same things someone might divulge over a beer immediately, if you want me to divulge more personal bits you’d need to actually learn to know me first rather than coerce me tell you with external substances.
Commenter Steve said:
- companies hire people that are jerks, and hide them from you in the interview process only to be unleashed after you accept an offer
This is a good point – when considering taking a job with a new company, what, if anything, can be done to check on how cool each of your new teammates will be to work with?
As Steve implied, typically when interviewing for a new job, the company’s own interview process has you talk to only the hiring manager, plus maybe 2 or 3 of your prospective teammates. The personalities of the remainder of the teammates, then, are unknowns until after you’ve accepted the job.
One idea might be to ask the manager for a list of the names and work email addresses of all of the team members, and then email each person on the list individually, explaining that you are a new prospective member of the team and asking a question or set of question, and then try to get some kind of feel for the personalities on the team based on each person’s responses (or lack thereof)?
Would this kind of thing be reasonable to do? Is there any other guidance out there on how a typical (non-entrepreneurial) developer can position themselves on a team of all quality (“cool to work with”) people other than by chance?
I’ve always found the “If I started my own company, who would I take with me” to be the perfect test of how much you like your team.
I HIGHLY recommend reading The Three Signs of a Miserable Job by Patrick Lencioni. It’s a quick read, I burned through it in maybe 2 hours. It breaks down the team/job dynamic in elementary terms and I believe could be effectively used in a job interview to find out what you’re going into. I’m technically just a programmer peon, but reading this book reaffirmed the way I want to treat my coworkers and the way I want them to treat me.