I am currently working in an office where the developers are not very social therefore don't discuss their work very much. So I feel that we are not using each other's skills as much as we could.
What are some good ways to stimulate healthy development discussion in the workplace without looking like you are just socialising and not working?
Pair programming and peer reviews have worked well for my company (when we actually use them). We also started using an internal wiki where we can share project-related information.
My personal favorites are to start some email discussions about the code we're working on. If you're working in C++, there are ample opportunities to start threads about strange things you discover in the language. I've been tempted many times to start an alias called "So you think you know C++" for just such a purpose. If nothing else to share my own personal embarrassments.
Other ideas
One thing you might try to avoid is annoying them. It is great to talk and communicate about what you are working on, but don't do it while their right in the middle of writing code for the project.
I also agree with Jared Par and Bill the Lizard.
There's no substitute for having solid team dynamics, which is one of our top criteria for hiring. However, once you're stuck with the people you've got, there's still some things that can help.
Common Area
The biggest thing that helps us is a "common area" where most developers congregate. Currently 3 large tables (~4 people with plenty of space), plan to add a couch or two soon. This is easier because we have laptops, so it's not a big deal to move around. We usually work in groups of 2-3 on tasks, and try hard not to silo anyone on something for more than a few days. We change up who works with whom frequently (every several weeks or so), so developers regularly rearrange themselves in the common area to sit near the other people they're working with.
Again, this is also easy for us because everyone gets along very well and likes to work with everyone else. The key is not to force it - it's not like Bob and Sarah are told they will work together on task x whether they like it or not, to ensure everyone gets a rotation with everyone else. Rather, we have a fairly diverse set of tasks and people are assigned to a task based on what they are interested in and what their expertise is. If your developers are wary of working in pairs or some don't get along as well, start slow and make a few obvious matches with the most social of the group, so the rest can see how much better it is.
Lunch & Learn
One person from the group presents a topic (say, LINQ providers) to the rest while lunch is catered (pizza or something simple). This lets the presenter choose a topic they are passionate about/interested in; it helps hone presentation and communication skills, and it lets the rest of the group engage in a single individual. This helps build respect/rapport.
Celebrations
When we hit moderate-to-major milestones, we send out a meeting request to everyone to meet at a bar. Sometimes it's on the company, sometimes not. Some people will attend one and skip another, but after a few most people end up going. There's no social lubricant like alcohol.
There is always an unavoidable stigma of "socializing, not working" in organizations large enough that there are other groups nearby. Most of our sibling groups probably think we just cut up and never get anything done, but the only thing that matters is delivering quality that makes leadership look good. If you can goof off and chat while doing that, leadership will rarely complain.
Have a periodic, organized event with free food and a short technical talk. Maybe start just once a month, then ramp it up as people get used to the idea.
I force it ... once a month or so, we have brown bag lunches. I buy everybody lunch (pizza, sandwiches, etc) and somebody has to present some new technology. For example, you might present something about VS2010 or the dynamic keyword or whatever. Nothing huge, not a bunch of slides or anything ... most people just bring up devenv and show a few things. Then we talk about it. Specifically, we talk about what we could take from this and add to what we are doing. Then we pick who has to present at the next one. Pretty effective, very low cost, low productivity impact and most of all low stress.
Instant messenger is the only form of socializing I can do while programming.
I always run a multiple protocol IM client, like trillian, and ask everyone what their IM accounts are. It probably quadruples the amount of social contact I would otherwise have at the office.
And always accept an offer to go to lunch. No one is writing code at the cafeteria or restaurant.
Don't assume it is ok to take up people's lunch times. Pizza is a poor recompense for losing a valuable break from work, or an opportunity to do jobs or personal training that people think important to them.
Food is a great incentive to get people to do things they don't naturally do, but it is an inadequate form of overtime payment. I have supported this kind of thing in the past where the company felt generous for providing pizza for forced, unpaid, late working, and am ashamed it took so long to understand why it was not always received graciously.
I often just ask someone if they will brainstorm with me, book a conference room and go do it. I have extensive corporate knowledge of who has done what, so I usually know exactly who might have done something simliar to what I am working on or who might have some good insight.
Code review is really good for learning as well. I've seen things I hadn't considered and let others know about something they hadn't considered or didn't actually know about the data in the database in a code review. Better if you can do the brainstorm thing earlier in the process though, rather than go down a wrong path and have to fix at the code review stage when people expect the product is almost done. I've not seen much that didn't benefit from more than one person considering design even if unofficially.
If it sounds like a work conversation, no one thinks you are socializing. You may have to add the other person to your project to charge time. But no one I work with has ever objected when I did that if the person I added was someone who would have a valid input into the process I was working with.
I also have three or four people who also do data type tasks along with me. When I run into something strange (or they do) usually we mention it at our next team meeting or email everyone so they know that a certain change to the db may break certain types of processes or share the spiffy new way they did something. Knowing what someone else did is half the battle when it is something you may need later.