タグ

考察と仕事術に関するgikanのブックマーク (3)

  • 一流の研究者の抜け駆け功名 | Lifehacking.jp

    一流の研究者の先生と机を並べて一ヶ月半。毎日繰り返される議論にも慣れてきて、パソコンの操作や PowerPoint の作成をお手伝いしているうちに、なんだか緊張がほぐれてきて、この人がどれだけすごい研究者なのかを忘れつつありました。 そんなある日、現在私が進行中の研究についてのディスカッションをしてもらっていたときのことです。 私「…とまあ、こんな結論にしておこうと思うんです」 先生「それもいいですが、こちらの結果も野心的でいいじゃないですか。論文に入れないのですか」 私(ぎくっ)「そ、そちらはちょっと怪しいというか、あまり言われていない話なので…」 その部分は自分でも気づいてはいたのですが、提示した資料からは言い過ぎではないのかと思って結論には含めなかったものでした。先生はちょっとの会話でそれを的確に見抜いて突いてきたのでした。そしていかにも不満そうに付け加えました。 「mehori さ

    一流の研究者の抜け駆け功名 | Lifehacking.jp
  • ポモドーロ再考 - 西尾泰和のはてなダイアリー

    Twitterより転載 ポモドーロの肝はPDCAのCの部分だと思う。僕が割り込みの比較的少ない職場なのになぜプラン通りに作業ができていないのかをチェックするには割り込み頻度にフォーカスしたレコードでは足りなくて、ポモドーロ終わったのに作業を続けてしまうとか、タイマー付けずに作業しちゃうとかも計測されるべき 何をレコードすべきか ここしばらくポモドーロ作業をしていて起きた割り込み 地震 話しかけられる 一日平均1回未満だと思う。きっと割り込みの少ない職場のはず。だから僕の生産性向上に関しては割り込みを減らすことより、もっと別の注力すべき課題があるはず。 バッドパターン タイマーを回さないで作業をして、カウントされるべきポモドーロがカウントされない 休み時間に調べ物をしていたら、そのまま作業に移行していて1ポモドーロくらいの時間を使っていたが計測していない 休み時間の調べ物が予想以上に手間取っ

    ポモドーロ再考 - 西尾泰和のはてなダイアリー
  • プログラマーの開発速度は「はまる」時間の長さで決まる : 小野和俊のブログ

    プログラミングを始めてから今日に至るまで、 様々なタイプのプログラマーと開発を共にしてきたが、 驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、 一つ共通の特徴があるように思える。 それは、「はまる」時間が極端に短い、ということである。 風のプログラマー」を指向しており、開発速度を重要視している。 例えば平成14年未踏ソフトウェア創造事業「PICSY」では、 発表直前に知人でプロジェクトリーダーの鈴木健にレスキュー隊として呼ばれて 2,3日でGUI全般と、クライアント/サーバー通信部分の設計と実装を終わらせたのだが、 このときなどは、大体の要件を口頭で聞いた後は、 ほぼまったく手が止まらずコードを書き続ける感じで開発をしていた。 「はまる」時間の長さは開発速度に直結するわけだが、 プログラマーが「はまる」場合にはある程度の傾向があると思うので、 今日は「はまる」プログラマ

    プログラマーの開発速度は「はまる」時間の長さで決まる : 小野和俊のブログ
  • 1