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!
Top comments (3)
I'm a mentor for second year students while they are doing software development projects 4 days/week for a whole school year. They are in small teams (5-7 person) and while there is some communication and knowledge sharing between teams, there could be so much more.
I tried to hold a weekly meeting of sharing knowledge, but I wasn't able to get the discussion going as often and as well as I wanted and ultimately it petered out. I will be a mentor for the next fall semester as well and this write-up got me interested to try again with a new improved version. Hopefully it will get to a self-sustaining mode and will continue even after I leave.
Thanks for an excellent idea and article.
This is an excellent idea, and something you gotta try if you're not doing it. A few weeks ago we had a similar meeting in my project. Every member got around five minutes to share what they had been working on for the week and how they were solving specific problems. By the end of it everyone had a new bit of knowledge, and we all certainly had fun.
Next time I'll suggest we follow the structure you describe here. I'm pretty sure the team will like the outcome.
Love this idea, and definitely wish my workplace will have regular knowledge meetings.
In my experience trying this in the past, nearly everyone is excited to participate and learn, but the significant entry barrier for everyone has been "what should I teach?" It may have been a combination or 'I've just learnt this topic so I'm not an authority' or 'everyone else already knows this and I have nothing to offer' - this ties into your point of making it a comfortable meeting. Any advice on initial structure & topics to encourage a more organic flow later?