t_wの輪郭

Feedlyでフォローするボタン
document
UIとドキュメントの両輪が大事ドキュメント追従あれドキュメンテーション開発とドキュメンテーションの分離あれGoogleドキュメントドキュメントの不備ドキュメントはスケールする質の良いドキュメントがあれば、人数増加に対して説明に係るコストは定数『ドキュメントに固執せよ』ドキュメントの「はじめに」に想定読者を書くドキュメント構造化あれあれあれドキュメントツール無料ドキュメント『アクションを駆動するドキュメントの作成 | DevelopersIO』あれ

あれ

2024/10/19 20:48:00

仕様をまとめたドキュメントをAIが全部かいてくれればいいのにと思いながら書いてない。

スタティックな「ドキュメント」が不要になるかも。

「ソースコード読め」から「AIに聞け」へ変遷する。

あれ

2024/3/5 9:13:00

Wordでドキュメント書くの、最初はMarkdownを変換してdocxファイル生成したらぁ!とか思ってたんだけど、Wordで書くのが思いの外楽しい。

Wordのアウトライン表示が楽しいんじゃ。

  • 文章を書く序盤→アウトラインが書けて楽しい
  • 文章を書く中盤→アウトラインがそのまま見出しになって楽しい
  • 文章を書く終盤→文章の塊を見出し単位で簡単に移動できて楽しい

あれ

2024/3/5 0:57:00

ドキュメントがWordで20ページぐらいになりそう。理系の卒論やん。

あれ

2024/2/27 1:09:00

ドキュメント書くのめんどくせーなと思ってたけど、Wordのスタイルをいじってたら興が乗って文章が生えた

あれ

2022/6/19 18:17:00

会社で知識や技術の共有をうかつにやったらパクられるだけで大損じゃん。誰が二度とするか。

エンジニアにとっては知識技術収入の源泉知識が資本)だから、それらを供出させるのは難しそう。ドキュメントを書く専門の人(テクニカルライターとか)がいればまだマシなんだろうか。開発とドキュメンテーションの分離という感じで。

ドキュメンテーションを引き受ける作業者がいれば、開発者は開発に集中できる

技術的なドキュメント化はあらゆるプロジェクトに求められる汚れ仕事である。 適切なドキュメントを書いて、保守することは、プロジェクトチームが後で使ううえで重要だ。しかし、こうしたドキュメントは誰が書くというのだろう? 開発者が自分でドキュメントを書いたら、「実際の」作業の妨げになってしまう。

それゆえ:
必要なドメインをよく知っていて、設計自体には利害関係のないテクニカルライターを雇おう。 適切な記法を用いて設計を表現してもらおう。整えたうえで公開し、レビューしたり、組織で使えるようにしてもらおう。

from 『組織パターン』