[jamesog]

> I collaborated a lot with a collage - James (Jog). I asked him loads of questions, from "how to login to a server", via "what is anycast" to "tell me how you mitigated this one, give me precise instructions you've run".

Hi, that's me! There were definitely a lot of fun conversations.

I liked that a culture of internal blogs became a thing too. It was good to see people brain dumping their experiments and findings. I think people learnt a lot from following all the internal blogs.

[DiggyJohnson]

Always funny to see these sort of missed connections on HN.

> internal blogs

In my personal experience the problem is the total lack of writing culture at non-premiere companies.

Put differently: unless you’re working on a great team at a great organization roughly 90% of people cannot be expected to write/read well as a component of technical collaboration. Any thoughts on that? I may just be too cynical

[throwaway2037]

From my personal experience, internal Wikis are 90+% written by about 5% of the workforce. The vast majority of internal Wiki users are "read-only". That is fine. Really: Read that twice. It is OK that the vast majority of docs are written by the few who are highly motivated to do it. When I write for an internal Wiki, I am trying to reduce the number of future questions that people will ask me. If they do come with a question, my first answer is always: Did you search our Wiki? It only takes once or twice for them to change.

[tracker1]

I'm not sure it's really cynical at all, in my experience, even with a LOT of wiki documentation, it is almost always severely out of date and many people don't know what is where... after a while, there's new, new, new versions of docs because people didn't want to refactor existing docs someone else created. And, in the end, almost nobody reads it and just ask other, more senior people within the team/org.

This is, of course, without explicit management directives to update documentation as a task/chore. Much like in many (most?) orgs, churning through technical debt is rarely a priority.

That said, no place is perfect and it takes only a handful of people to improve a culture, but without at least management support and/or fostering such a culture, it doesn't tend to happen.

[mlinhares]

But the non-premiere companies also do not hire the talent that is capable of doing this (and that might be fine, they might not really need that specific talent).

I've many friends that worked most of their carreers in small to medium companies where this wasn't a thing and stuff mostly worked. We can't expect to replicate the high end tech experience everywhere, I doubt it is a good investment of resources.

[torton]

This is rather likely to get worse.

Reading comprehension is declining. Emphasis on individual "impact" and deadline pressure, common at both premiere companies and "non-premiere" companies mindlessly copying the former, both consume time that could have been spent thinking, writing, and engaging with optional things others wrote. People who avoid documents because they might get outdated create systems with no documentation at all. And now, LLMs promise a world where documents don't need to exist a priori -- a model will look at your code and generate a plausible description of possible intent and system architecture on demand, if someone implausibly happens to ask for documentation. If nobody happens to ask, that's even more time saved - a win-win!

Leadership can either support or inhibit the culture of writing and reading. However, modern managers are not immune from the rising pressure. Their response is to shift from thinking and deliberate information processing to rapid-fire pattern matching. Some of them don't see documents as "real output" to begin with, and operate solely in meetings without any written record or documentation whatsoever. Of coures their staff will pick up on the pattern. I have a vivid memory of engaging with a full team working on a substantial project in the absence of their senior leader, getting the tactical picture and then asking the team about the project's goal. You could have heard a pin drop. None of the people working on the project could speak about anything but their immediate assigned tasks.

[majke]

Internal blog is another thing, but indeed related to chat. Once we figured some techical thing out, I often put it under "personal blog" on wiki under something like ~marek/date-slug. (I'm actually quite upset about jira removing slug from the url and replacing it with random number, this makes url completion much worse. I often titled the wikis funny/witty to make it easier to remember and find)

These were usually quite short notes. Like I did this and that. Or here are instructions I've run. Pretty much a "lab notebook".

Again, this was often useful to people. Folks new what I was working on at that time. Over time more people adapted this style of public note taking (within company), but I have the impression I was more consistent than others.

I did it for many reasons. I genuinely forget things. It was always nice to see comments (like James complaining that I shouldn't do `dpkg -i x.deb`, and instead finally install the package repo in apt-sources!). So again - searchability (a form of documentation), reach (getting feedback), and work log (for planning).

The format was also nice - short, without specific audience in mind. Zero drama, zero effort. Plentiful and low quality. Because it was "blog" and not "pages", this meant it was obvious when the note was written and nobody expected old blogs to be up to date. The lower the friction in note taking - the better.

Finally, I was working with an SRE team, which was tightly knit and communicated very often over daily checkins (which I wasn't invited to) and other informal channels. And I worked from home a bit. This meant I had to find an asynchronous way to communicate with the team. My personal blogs worked nicely. I highly recommend this style to anyone working remotely.

Although I must admit the personal "lab notebook" wiki thing is not scaleable. It's impossible to "follow" more than a handful of people.

I kept statistics. It's fairly obvious when I was most productive. Here it is, my internal blogs on the wiki per quarter:

  2013-Q4 |  0 | 
  2014-Q1 |  0 | 
  2014-Q2 |  2 | ##
  2014-Q3 |  3 | ###
  2014-Q4 |  2 | ##
  2015-Q1 | 14 | ##############
  2015-Q2 | 15 | ###############
  2015-Q3 | 57 | ###################################################
  2015-Q4 | 60 | ######################################################
  2016-Q1 | 70 | ######################################################################
  2016-Q2 | 71 | #######################################################################
  2016-Q3 | 17 | #################
  2016-Q4 | 23 | #######################
  2017-Q1 | 13 | #############
  2017-Q2 | 22 | ######################
  2017-Q3 | 16 | ################
  2017-Q4 | 25 | #########################
  2018-Q1 | 12 | ############
  2018-Q2 |  9 | #########
  2018-Q3 | 23 | #######################
  2018-Q4 | 14 | ##############
  2019-Q1 | 14 | ##############
  2019-Q2 | 20 | ####################
  2019-Q3 | 18 | ##################
  2019-Q4 | 36 | ######################################
  2020-Q1 | 19 | ###################
  2020-Q2 | 13 | #############
  2020-Q3 |  4 | ####
  2020-Q4 |  3 | ###
  2021-Q1 |  4 | ####
  2021-Q2 |  8 | ########
  2021-Q3 |  3 | ###
  2021-Q4 | 21 | #####################
  2022-Q1 |  4 | ####
  2022-Q2 | 12 | ############
  2022-Q3 |  4 | ####
  2022-Q4 | 28 | ############################
  2023-Q1 | 14 | ##############
  2023-Q2 | 16 | ################
  2023-Q3 | 10 | ##########
  2023-Q4 |  6 | ######
  2024-Q1 | 12 | ############
  2024-Q2 | 22 | ######################
  2024-Q3 |  0 | 
  2024-Q4 |  2 | ##
  2025-Q1 | 20 | ####################
  2025-Q2 |  3 | ###

Total 784 over 11 years.