解決困難な課題に対し、どのように向き合っていくか : 小野和俊のブログ
・最善を尽くしてもどうにもならないなら、自分のこれまでのやり方に固執せずに、課題を解決している先人達がどのように対処してきたのかを謙虚に学び、自らも実践を試みる。 ・先人達の方法を模倣しても課題が解決しないなら、自分の強みと弱みとを振り返り、自分の強みが活きるよう、先人から学んだ方法を微調整して再度課題解決に臨む。 ・失敗が続き、もう自分は降りよう、という気持ちになってしまったら、課題を乗り越えた先にある成功をイメージし、「あの坂を登れば、海が見える」のだ、と、自らを勇気づけるようにする。 ・身も心も疲れ果て、自分を奮起させる気力さえも無くなってしまったら、再起のためにあえて一時的に課題から離れ、安楽の中で自らを癒す期間を設けることも検討する。 解決が困難な課題に直面した時、ただ立ち尽くすだけでなく、解決に向けたステップをひとつひとつ踏んでいくことが大切なのだと、ここ半月ほどDiablo3
成長しないプログラマーの7つの悪習慣 : 小野和俊のブログ
はてブのホットエントリで「成功できない人たちが持つ7つの悪習慣」という記事を見かけたのだが、ライフハック系の本やエントリは胡散臭く感じるところがあってあまり好きではない私から見ても、これは確かに、と思える内容で、プログラマーについても同じことが言えると思ったので、エントリにまとめてみた。 ・自分の理解力不足を技術のせいにする。すぐ理解できない技術や、普段自分が使い慣れてない技術は「キモイ」、「自分には合わない」などといってすぐ学習を放棄する。 ・他人の非に非常に敏感。使っているライブラリや人が書いたコードに少しでもバグが見つかると、「使い物にならない」、「書き直した方が早い」などとすぐ口にする。 ・環境がよく壊れる。「このPC不安定」、「また開発環境がおかしくなった」、「OSから入れ直さないと」といったように、作業環境が頻繁におかしくなる。たいていは自分で必要なファイルを消してしまったり上
小野和俊のブログ:プログラマー風林火山
アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニアと仕事をしてきた。 あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。 そういう経験を重ねていくにつれ、私の中では、スターエンジニアと呼べる人たちの持っているものについての、いくつかの類型ができてきている。今まで一緒に仕事をしていく中で本当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるような財務のわかるエンジニアとか営業もできるエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもなかった。ではどういうエンジニアが、というこ
小野和俊のブログ:徹夜をしてはいけない理由
どうしても昨日までに仕上げなければならない仕事があったので、一昨日は徹夜で開発をした。一人で飲んだり、人と飲んだり、布団の中で考え事をしたり、徹夜をすること自体は悪いことではない。しかし、徹夜で仕事をするのは可能な限り避けた方が良い。 ベンチャーを始めてからの最初の2年は、年末年始を含めて365日1日も休まず仕事をした。徹夜なんて当たり前である。そんな私だったが、会社が3年目に入る頃に休息の重要性を痛感し、以来、できるだけ徹夜はしないようにしている。それは、徹夜がもたらす作業時間よりも、悪影響の方がずっと大きいということに気づいたからだ。 私の経験では、徹夜が常習化するにつれ、個人/組織には次のような症状が出てくることがある。特に、影響力のある人がこのような状態になると、組織全体が影響されて深刻な症状にかかりやすい。
小野和俊のブログ:私がシリコンバレーで学んだ5つの教訓
1. 会議を最適化する ミーティングのゴールを明確に設定する。 ミーティングの最後に必ず結論と ToDo を確認する。 ミーティングの回数をできるだけ少なくして時間もできるだけ短くする。 ミーティングのトピックごとに関係する人だけ集めて最少人数で議論を行う。 (途中であなたはこのトピックに関係ないから退席して良いです、と指示がでる) 会議を最適化することで労働時間中の実作業時間を最大化させ、労働時間全体を圧縮する。そして、早く帰る。 この体験は、その後自分が会社で会議をしていく上で大きく役立った。 XM(eXtreme Meeting)にも、この時の体験が直接的にも間接的にも影響を与えたと思う。 アドバイザーとしてプロジェクトに参加していたテクニカル・コンサルタントが、技術的に明らかに間違った発言をしたことがあった。 私を含む日本から来ていた何人かのメンバーは、あんな基本的なこともわかって
小野和俊のブログ:続・プログラム・デザイナー宣言
前回書いたプログラム・デザイナーと職人プログラマーとプログラム・デザイナー宣言と同じような感覚を持っている人は意外と多いのではないかと思って探してみたところ、はてなの伊藤さんのエントリ(こちらも)が見つかった。伊藤さんとは何度か話をする機会があったが、ウルティマ・オンラインの話で盛り上がってしまって、今までIT関連の話はしたことがなかった。ブログを読んでいて、伊藤さんもきっとプログラム・デザイナーなのだろうな、と思った。 UNIXにみる世代間の断絶にならって職人プログラマー/プログラム・デザイナー/UIデザイン・プログラマーを表にすると次のようになる。 比較項目 職人プログラマー プログラム・デザイナー UIデザイン・プログラマー 譲れない点
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
