As developers, we create some kind of knowledge, as we crawl through the internet we discover new things, as we test frameworks libraries, etc..
A part of our work sometimes is to figure out something anyone else in the company have never done. Once it's figured out, the information shouldn't stay in the mind of the person who found it, it should be shared, so other developers from the team would not have to waste time on the same problem/problematic.
Also I watch several websites that makes me discover, new tools, programs, library that are totally relevant to share with my colleagues
So the question is, how do share information in your development team ? Do you have any methodology ? Do you use a particular software ?
Top comments (3)
I've been on teams where the Slack had a
#tribal-knowledgeor#tilchannel to handle little things or links.I've been on teams where the expectation was to write a Confluence doc on the whole research and findings and the whole thing, doing all the stuff for a dev research spike for any knowledge to curate a large number of help docs.
There used to be organization-wide lunch-n-learns, but I've mentioned before that that's turned into more "official" knowledge in niche subjects rather than coworkers helping out other coworkers with learning things.
Since my department doesn't read the Confluence docs, I figure I'm going to write knowledge sharing posts on Medium to link people to and crosspost them here (there's too much crap in my comments to really link them here directly).
I also have my bookmarks on GitLab with my notes as kind of an open source list of stuff I think it useful.
I will typically document things on a wiki page or a README beside the source code. But generally only if something is non-obvious. For example, it was not obvious to me how to setup a linux machine and join it to our domain and give domain admins sudo access. So after I had to do this, I wrote a wiki page for it.
Or certain high-level decisions may impose limitations. A document detailing the pros and cons and why the specific trade-off was chosen. My example here is using append-only log-based storage. This carries limitations in how the data structures can evolve and remain backward compatible, and procedures for making backward-incompatible changes.
I think internal presentations are pretty great for this sort of thing. It's not necessarily "storage" but it's a time to really get people's attention on an issue, and then it can be reflected in some lists or docs. But I think the part where people come, pay attention, provide feedback, etc. is pretty great.