T字モデルに置き換えた持論をベタ打ちします．
イメージを描けるまで語りを受け，真似する （T字を作る）
（注：プログラミング経験などによってここは省略される）
初めに誰しもわからないのは，「ITで何ができるのか」である．ググっても，正直自分たちの（研究の）目的に合った使い方をしている事例はまとまっていない．例えば，ググった内容だけからだと我々の書くコードの理解に甚大な時間と精神力がかかる．
自分の興味などに応じて文献調査するなどはすでにやっていると思うが，それ以外に，“やられて”ほしいこと．
「研究室でよく用いられるモデルは，何ができて，どんな構造で，何に使われるか」
- セミナーを開く（先輩の義務）．参加できなくても先輩を捕まえる（後輩の義務）．
- モデル構造の理解は，将来的には全体概略+自分の興味部分の詳細，となると効率良．
- モデルは近似なので，何ができないかにも自然と興味が行く（時に失望する）．
- ついでに，対象とする研究と時空間解像度との関係も何となく整理する．
- 使うときのルールがあれば，最優先でメモる．
「図の描画（pythonだけで十分?）はどうやるのか，どんな図が描けるのか」
- セミナーを開く（先輩の義務）．参加できなくても先輩を捕まえる（後輩の義務）．
- データ形式（拡張子），pythonなら使う関数とその変数を理解する．
- わからない（気になる）部分が出たら，聞けるうちに忌憚なく質問する．
（筆者の希望）「結果の見せ方・解釈で使う統計学は何か」
- 論文で知らない統計学に出くわしたら，ググる（概念と目的の理解，詳細は興味次第で）．
- （筆者の疑問）研究室でよく用いる統計ってあるんだろうか．それって教えるべきか．
最終目標（T字の形成）
『ふーん，コーディングって，こんな感じに使うのか．だいたいのことできそう．』
自分の目的を達成するために行動する （T字の縦棒を伸ばす）
ある程度研究テーマが決まると，自分の必要な道具も整理される．自分独自の計算をするかもしれないし，自分しか使わないモデルを探すかもしれないし，自分しか使わないような図を描画するかもしれない．これまでで，「たぶん習ったことをうまく生かせば解決できそう」と思えることが前提．大きな違いは，ここからは基本「自助努力」．
「うーん，わからん．」
- まずはひたすらググる（先人の知恵）．
- 初期でも6-7割はそれで解決する．慣れれば95%くらいがそれで解決する．
- ググるべき単語を知らないことも多いのを経験する（図のmarker，legend，ticksとか）．
- 同じ問題についてググりまくると，疑問の根本が整理される．
「うー，ググっても解決できないよ．」
- 周囲で，「この人なら知っていそう」を整理する（モデルユーザなら特に必須）．
- 1分以内とかで説明が完結するように質問は準備する（質問者のマナー）．
- 回答者は，問題を解決してあげるとともに，ググる指針を与える（回答者のマナー）．
- （筆者の意見）質問はため込まない．遠慮なくどんどん訊いちゃって問題なし．
- （筆者の疑問）先輩は後輩を（たまに）気に掛けるべきなのか．ランチ参加とか？
「よくわかった．さて，整理しなくては．」
- 書いたコードは自分が振り返りやすいように．履歴が分かるように．
「でもこれって，Excelでもできるよな...（Excelを使うときに考えること）」
- デフォルトで表示される図を描画につかうのはあまり評判がよくない．
- フォーマットや，処理の自動化などで手間がかかる（やり方はあるっぽい）．
- 自分でデータをさっと確認したり，手っ取り早い作業をするのに使う．
- ググればだいたい出てくるし（マクロ処理は少ないかも），基本自助努力で解決させる．
- フィルタ処理とか，$の使い方（F4便利）とか，テキストウィザードとかは使えるように．
「でもこれって，研究室でやっていいことなのかな...」
- 研究室のルールとかは，正直そうした場面にでくわしているかさえよくわからないことが多い
- 心配が少しでも出たらすぐ周囲に確認する．
- 責任を取る（めんどくさいことになる）のは当事者よりも責任者であると肝に銘じる．
最終目標（T字の縦棒）
『なんか使いこなせてる気がする．直近で必要な図とか計算はできそう．』
自分の研究の幅を広げられること，自分の研究が楽になりそうなことがあるかを探検する （T字の横棒を伸ばす）
研究が軌道に乗ってくると，より説得力のある解析を行う，よりコードの中にある無駄を減らす，よりよい見やすい図を描く，そんな望みを抱くようになってくる．これまでの作業に慣れてくると，たぶん次のような思考回路が出来上がる．
「同じような望み持った人が研究室内かネット上にいるんだろうな．」
- 基本その通り．
- 効率化の一つのkeywordは『ショートカット』．有名なやつは大抵あると踏む．
「うーん，もっとコードが短くなるような関数とかアプリがありそうだな．」
- 基本その通り．
「ググった回答て出てきたこの構文（関数，変数，etc）なんだ？」
- 積極的に調べるとよい．
- 他人のコードを読むと，こうした発見はわんさか出てくる．
「やたら同じミス繰り返すから，いい加減楽に書きたいな．」
- 積極的に改善を目指すとよい．
- 上に出てきた知らなかった構文も，そうした需要があって出てきたもの．
- 既に確立されたコードを読むと，その構造の意味が分かってくる．
- 世間的に広まっているコーディングルールは，共有しやすい，ミスしにくいなどに基づく．
「うーん，そもそも開発元のマニュアルとかソースコード見たほうが早くね？」
- たぶん，一番理想の形．
「あれ，意外と情報ないかも...」
- 課題を自分で新しく解決できたのであれば，ネットで共有するとベター．
最終目標（T字の横棒）
『おー，作業がどんどん効率的になっていく！これは周囲にも勧めねば！』
不足等が出てきたら適宜再編集します．