61–70 of 220 posts
If that isn't in place. Any such endeavours will fail as other people in the business just won't bother.
I'm not sure about the "successful companies institutionalize the knowledge of their employees" part. In such context a process becomes a (written) 'procedure/specification', and some folks stop innovating, they just do it "by the book". HR quickly grasps this and hires people with less and less skill, cheap personnel 'just able to apply to procedures'. Other ones feel like cogs in the machine (especially the best on…
Earlier quoted context omitted.
Can you export slack logs as plain text, or something easy to process like JSON? (Haven't used it in forever, so I don't know). Being able to grep -A3 -i foobox -r /nfs/info | grep -i rpc is useful. Similarly, you can shove plaintext into a more advanced search engine easily.
> Can you export slack logs as plain text, or something easy to process like JSON? I think you can, the main issues are that: - Conversations aren't forced to be threaded, and there is no way to go back and do anything with conversations that weren't threaded; it's just lost data. - Because Slack doesn't export data into a standardized format, there isn't a big ecosystem of tools to do stuff with Slack data. And it's…
Simple rule: Require that new hires should be able to become productive without having to talk to anyone (physically or electronically). The rest will fall in place.
Part of the knowledge of a large system is due to having discussions with others.
Something I wished companies do is to ensure that discussions happen in internal mailing lists (rather than in individual email accounts) and have all mailing lists searchable and accessible to anyone in the group. This would simplify understanding how certain decisions were arrived at.
* Graduated levels of mastery: few people need the details for standing up a production database, but all department members need to know that a company process already exists for it.
* Training dependencies: the mapping doesn't have to be perfect, a little goes a long way in giving shape to a training program.
* Training records: log employee training sessions, from self declarations of 'Yes I read this brief' to consultant led seminars.
Basically 80% of the military's comprehensive training program can be implemented with a network drive of docs and a spreadsheet. A couple of places I contracted for was pretty heavily reliant on Microsoft Sharepoint. I'd be surprised if there wasn't a fairly decent open source suite of components that could give you a solid starting point for a training program what would be somewhere in the middle of the spectrum.
Starting a set of services should be as simple as "docker-compose up", building should be as simple as "make", checking out the code should be as simple as "git clone", etc. You shouldn't need a shitload of wiki checklists that describe how to install dependencies and how to check out all the git-directories with correct versions relative to each other. Save your wiki for high level documentation
A must for this to work is to avoid configuration state in your servers that is not captured in your source tree. This is the most critical because it's easy to forget and it can quickly become a blocker, not just for RnD but also ops. You have this super important service that everybody depends on and it always works, suddenly the server burns while go-to-guy is on vacation and nobody knows how to bring it up again from a clean slate because it involves several hours of clicking around in some proprietary GUI and ticking all the correct boxes. If you can't reproduce this service today, make a VM snapshot already, then start work on fully declarative service configuration.
1. Working in pairs or teams. Avoid solo people working on projects. 2. Common, easily searchable place to put all documentation at. Good search capability is critical. Wiki is ok. 3. A good code & commit search engine. Ability to search code reliably obviates the need for a lot of documentation. 4. Weekly knowledge sharing sessions with the whole team. Both presenters and question askers need to be rewarded to keep…
> Common, easily searchable place to put all documentation at. Good search capability is critical. Wiki is ok. I have mixed feelings around documentation because I can often read the code faster than the docs, and docs are often incomplete, inaccurate, and out-of-date. Docs for truly long-lived things are nice, though. As for good search, that's easier said than done. The heuristics Google used for search don't work…