ぶくま殿 extern

IT業界における「技術力」の意味するものは、日進月歩の勢いで変化しているということを理解してほしい @ 達人プログラマーを目指して

プログラマーの仕事で唯一不変なのは「常に学び続ける姿勢だ」という人もいるくらいです。

クラウド時代では以前のようにマシンの物理的なアーキテクチャやメモリマップ、OSやネットワークの詳細を理解したエンジニアの数は少なくてすむでしょう。しかし、そのかわり複雑なフレームワークの知識や分散データーベース、臨機応変の要件変更への対処、業務ドメインのモデル化、高度なユーザーインターフェースの実現などにいかに対処していくのかといった全く別の意味での技術力が要求されるようになっています。

「3年前に使った××を今回にも適用しよう」だと周回遅れの出来になってしまうことが多いのが情報技術分野。

魅力的でない選択肢を加えると本来なら選ばれない選択肢に誘導することができる @ デジタルマガジン

関連記事

ActionScript3 最適化・高速化Tips 簡易まとめ @ ConquestArrow.addEventListener(); - actionscriptグループ

処理系特有なものから他の言語でも応用できるものまで結構な数のベンチマーク結果を掲載。ASは初期のMacOSとかSX-Windowのような、イベントドリブンの擬似マルチタスク処理系なので、イベントハンドラの中で時間のかかる処理をしないようプログラマが配慮する必要がある。そうしないと、入力への反応が鈍くなったり、最悪「応答なし」になってしまう。

もたつき感を減らすのに上記のような高速化は有効。最適化しても1秒とかかかるような場合は「そうめん」なんかを使って強制的にプロセッサを明け渡す書き方をすることになる。

ヒッキーがリーダやってみた @ はてな匿名ダイアリー

正直な進捗を顧客と共有する

作業の内容による。 単純に機能を組合せれば実現できることが自明で、工数を減らす余地がないならともかく、 工数を減らせてしまう場合は、顧客の組織内部で問題視される恐れがある。 契約時と異なる金額を請求すると、過去の判断を「間違っていた」ことにする必要があって、そのために誰かが「間違いを犯した悪者」にならないといけないとか。 さらに次の発注では見積もりの信用が下がって値下げを持ちかけられるとか。
現場が頑張っているのに「現場のミスでした」と嘘をつかれることから実働部隊を守るためには有効だが、 現場の頑張りで実働工数を減らしたら顧客から喜ばれるような仕組みがないと長期的にはまずい。

意識して承認した。ほめた。注意するときも、承認したあと

大事。でも忘れがち。

ふりかえりをした

大事。でもタイミングを逃しがち。機械的に機会を設けるべきか?

話は聞くが、決めるのは私だ

大事。社内で心がけていること→自分の意見を持った上で他人の意見を聞く。「Aでいいですか?」と聞かれたら、他の案はあるのか聞き返す。あるいはボリュームのあるアウトプットについて「これでどうですか」と尋ねられたら、特に気になっている(確認して欲しい)点はどこかと尋ね返す。そこで私も彼(女)も気付かなかったら私の責任だけど、そうならないようにするために話を聞くようにしている。
あと、自分だったら違う結論になると思ったら、彼(女)の結論の理由を聞く。そしてこちらの結論の理由を話す。これは引用記事中でも実践例が示されていた。

「～の意見は確かに正しい。ただし、現状はこういう状況なので、XXしてくれ」

疲労度とかモチベーションのチェック

飲みニケーションが苦手あるいは時間がもったいないと感じる人もいるだろうから、ニコニコカレンダーはいいかもね。

[Perl] do-whileにlast はつかえません @ たまには呪文をとなえてみるか：仕事版

他にも「if〜elsifはあってもunless〜els(e)unlessは無い」とかね。