Start holding a domain knowledge meeting

Sharing knowledge is important. It's the reason we gather on sites like this. To Try to get a better grasp on the technology that we use, and the concepts that we work with.

This can be really important in terms of our jobs as well. We do a lot of interesting work at the JLR OSTC. As developers we get to work on a wide variety of projects. One week we might be working on server systems, the next we're building websites, prototype UIs, or interface integrations. Because we've got lots of projects going on, it can be hard to share knowledge across a particular domain.

A month or so ago I decided (on a whim) to start a meeting for the JavaScript developers in our office. It's a relatively small group, but I thought it worthwhile to do a little training (which in turn inspired my "JavaScript functions you may have missed" series) and a group code review, just to expose everyone to other people's methods of problem solving, and code interpretation. It also meant we got to have snacks, which is always a welcome treat.

"Please no, not another meeting" is what you might be thinking. I was a little concerned about this sentiment as well, but I found that what this meeting was about made a big difference on how people viewed attending it.

If you don't have something like this, here's my formula: Biweekly (My thinking being that manager won't worry too much about an hour every other week.) hold a meeting for an hour with developers who work in the same domain as you do. Spend 25 minutes on a "learn a thing" segment teaching a programming concept, a language feature, or something else. Spend 25 minutes on a group code review. Talk about what the code does, why it might do that, and how it can be improved. Use your own code, use a team member's (ask permission) or grab some random code from online.
In the last 10 minutes, open the floor to anyone who has questions, or needs help figuring something out.

This kind of meeting accomplishes a few things: It shares knowledge across the team, it builds rapport with team members, and it helps us professionally develop ourselves.

The next time you hold the meeting, give out assignments. Let someone else run the "teach a thing" segment, and ask them to bring something to teach. It doesn't matter much what they teach. This gives them the chance to run a meeting, share their experiences, and learn how to work better with a team. Same with the code review segment. Assign, or ask for volunteers to lead the review portion. This lets people get their code (or someone else's) I'm front of a whole group of people, and from the process in that group atmosphere.

One very important component: this meeting needs to be a comfortable place for folks to share. When you start the meeting, make it very clear that constructive criticism is welcome but mocking, insults, questions of competency, etc are not appropriate - Your office may have an environment of good-humored ribbing or something similar, but I encourage to drop it here. For this meeting to work everyone needs to feel like it's is one worth attending, and that they're going to get something positive out of it.

I hope you find a domain knowledge meeting as valuable as we have. I encourage you to give it a try. If you don't feel senior enough to run it, pop over to your team lead and see if you can get them to organize it. Offer to run one of the segments.

Good luck!