プログラマーは皆、常に秘密や嘘を抱えている - totopon114689の日記
プログラマーは皆、常に秘密や嘘を抱えている。 これは間違いない。 基本的には誰にも話さないが、 （家族や友人などプログラムを知っていない人間に話しても分からない、という事もある） プログラマー同士の飲みの席などで、過去の笑い話として酒の肴になる事はある。 秘密や嘘の傾向には幾つかのパターンがある。 1) 仕様があいまいな場合の適当なコーディング 仕様があいまいな機能を実装する場合、想定していたものよりもプログラム量が膨大になる事はよくある。 また、細かいパターンや想定外のケースに対し、どのようにプログラム的対処を行うべきか？ 洗い出しているとキリがない場合もある。 仮に事前に洗い出していたとしても、 「ケース自体は洗い出せているが、具体的にどのようなエラーメッセージを表示すべきか？」 などといった、その先がまたあいまいになっている場合もある。 このような場合、本来であれば決裁権のある人間に
残業を悪とするチームを作ろう - ひがやすを技術ブログ
長時間労働やサービス残業は、基本的には会社の問題であり、上司の問題です。 例えば、大手SIerで長時間労働やサービス残業が発生するよくあるケースを見てみましょう。 会社は、ワークライフバランスを向上させるために、年間360時間以上の残業をしてはいけないというルールを決めたとします。この段階で、会社は残業は社員のために良くないと認識しています。 現場は、社員の稼働率を上げるためにオーバーワーク気味に仕事をアサインします。仕事がないときに備えて、仕事があるときは、多めに仕事を振るのです。これが間違いなのですが、たいていの現場は、このように行動してるでしょう。つまり、仕事があるときは、多めに振られているので残業することが前提なのです。 ここで、会社の作った残業規制のルールが効いてきます。上司は、会社のルールがあるので、月30時間以上の残業をつけることを基本禁止します。「残業をつけることを禁止する
レビューのアウトプットは、レビューアのレベルを超えない（５）
「レビューのアウトプットは、レビューアのレベルを超えない（3）」で述べたように、ソフトウェア開発でソースコードをレビューすることを実践し始めたのでは1999年頃からです。 それから、コードレビューの重要性の教育やコードレビューを実際に実践して、一行一行コードをレビューしながら処理漏れはないか、バグはないか、読みやすくて理解しやすいかということをレビューしていきました。それは、きちんとしたレビューをしないとソフトウェアの品質が上がらないのと同時に、きちんとしたレビューを受け続けないと、レビューアが育たないからです。 そして、2000年前後から2008年までの期間で多くのコードレビューを実施し、自分自身でもコードを書き続けて、現場の若手の技術者を育成していました。そこには、レビューすることに対する開発組織全体の理解や中堅クラスのソフトウェア技術者でもレビューを受けるということで、全体で長期的に
プログラマーの力量を見極めることは困難ではない - komagataのブログ
プログラマーの力量を見極める--面接官になったら尋ねるべき質問実例集 - IT業界を生き抜く秘密10箇条 - ZDNet Japan ソフトウェア開発者を採用する面接の場においては、応募者の専門家としての力量を見極めることが最も困難な作業の1つである。 現時点でプログラマーの面接についての自分の考えをまとめておきます。 結論： プログラマー採用にあたって応募者の力量を見極めることは困難ではない。（面接で見極めることは困難である。） 前提： 短時間の面接（対面して話す事）でプログラマーの力量を実用的な精度で見極めることは不可能である。 中途採用において、PCやネットと切り離した無菌室状態での力量と現実世界での成果には大きな差がある。 専門技能（プログラミング）の高低と人間性の良し悪しは無関係である。 採用方法： ソースを見る。（githubのアカウント名を教えてもらえれば十分である） 会って
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
