名前空間を区切ったり定数を参照したりするときは二重コロンを使い、メソッドを呼び出す場合はドットを使うのが典型的な使い分けです。

関数やクラスを文書化するときには、「このコードを見てビックリすることは何だろう？　どんなふうに間違えて使う可能性があるだろう？」と自分に問いかけるといい。基本的にはコードを使うときに直面する問題を「前もって」予測したい。

たくさんの機能をまとまりなく組み合わせただけのアプリケーションもユーザを混乱させるだけだ。アドレス帳なのかチャットアプリケーションなのか？　ゲームなのかWebブラウザなのか？

目的が明確な作業と、助け合いながら開発を進めていける環境の２つはモチベーションの向上に大きく寄与しました。

バーンダウンチャートとは、作業の進捗報告を見える化するツールです。

メイ・リン「志有る者は事ついに成るなり。強い意志でものごとを進めるなら、途中でいろいろ困難なことがあっても、最後には目標を達成できるっていうことなの。だからスネーク、気持ちを強く持って。…負けないでね。」

やめようにもやめられないなら、挫折してもまた性懲りもなく始めてしまうなら、そこにお前さんの独学を動機付ける核があるんだろう。

合意と同意は異なります。主責任者を決めて、その人に丸投げしてしまい、その人が困っていたとしても周りが助けないというのは、合意ではありません。合意とは、同意に加えて「全面的にサポートするという意思」まで含んでいます。

参加者の緊張をほぐし、積極的に参加できるようにする工夫のことを「アイスブレーク」と呼びます。

if文の条件節で「真であること（もしくは偽であること）」を判断するために、== trueや== falseと書く人がいますが、これは冗長な書き方なのでやめましょう。

また、テストコードを書いてからデバッグすれば、デバッグの修正と同時にそのロジックのテストコードができあがります。なので、プログラムにほかの修正が入った場合でも、そのテストコードを実行すればそのロジックが壊れていないことを保証できます。デバッグの時間を短縮できる、できないにかかわらずテストコードを書いておくことは非常に良い習慣だと言えるでしょう。

アーキテクチャ評価ワークショップの目標は、アーキテクチャを評価するのに必要なデータを集めて分析することだ。ワークショップの終わりまでに、アーキテクチャが望ましい品質特性やその他のASRをどれだけ満たしているかを確認できている必要がある。

どんなバンドで演るときも一番下手くそなプレイヤーでいろ。 IT業界に入る前、僕はジャズとブルースのサックス奏者をしていた。バンドの中で一番下手くそというのは、いつも自分より優れた人たちと一緒に演奏するという意味だ。

自分で例外を発生させることもできます。例外を発生させるときはraiseメソッドを使います。引数には例外のメッセージを指定します。メッセージの部分は自由に書くことができます。どんな例外が起きたかをプログラマーが調べるときに使えます。例外クラスで例外の種類を指定し、メッセージに具体的なエラー内容を書くとよいでしょう。

プログラムが大きくなってきたときに、意味のあるまとまりで分割することで、書きやすく、また読みやすいプログラムにすることができます。また、同じ処理は１カ所にまとめて書くことで共同利用することもできます。

つまり、データベースという器の中にデータを蓄積さえすれば良いのではないということです。だからアウトプット志向で考えなければならないということになります。

素晴らしい企業文化では、問題や意見の相違が水面下に潜ることなくうまく解決される。社員はみなそれまで作ったことのないものを想像したり、実際に作ってみたりすることを楽しんでいる。それが組織の進化を支える。（中略）誰もが率直に発言できる環境を作り、透明性を徹底して、有意義な仕事、有意義な人間関係につなげることを常に目標にしている。

マインドマップはすべての線が「連想」という糸でつながった１つの意味であり、あいまいであることが、逆にスピードを生み、発送の柔軟性を引き出しているのです（速記性、容易性）。

あらかじめざっと読み、全体の構成や概要を摑んでおく

type文では任意の型に対して別名を宣言できましたが、interface宣言で扱えるのはオブジェクト型だけです。