なぜ優秀なプログラマは人を雇わないか - 人生を書き換える者すらいた。
僕の知っている範囲だと、優秀なプログラマはフリーランスか小規模な法人のオーナー社長であることが多い。人を雇っている場合でも、ほんの数人である。もちろん僕もその一人。そりゃまあGoogleやMicrosoftの本社には凄いプログラマもいるだろうけど、日本人だと本当に一匹狼系の人が多い。 僕もフルタイムの従業員を雇って１年以上経ち、人を雇うと何が起きるのかについてけっこう分かってきた。なので、なぜこのようになるのかについて考えてみた。 なんと金銭的な面「だけ」でも、合理的な理由をつけることができる。僕を含めた何人かを平均したモデルで例を出してみよう。すごく単純化しているけれど。 いま一人の優秀なプログラマがいて、平均的な会社でサラリーマンとして働いても年俸1000万取れる実力があるとしよう。この人が独立した場合、「好きなプロジェクトを選べるのでやる気が出る」「独立していることについてのリスクプ
プログラマはプログラミングをしていないという現実
フロリダのRubyプログラマのSteve Clayさんがブログに投稿した「プログラマーはプログラミングをしている、はずが実際はそうでもない」という記事が話題になっていました。 神話：プログラマは一日中、プログラムを書いている。 現実：多くのプログラマは下記の事に多くの時間を費やしている。（順不同） 外部のプログラマーのMLへのメールやテックでない人へのメールを用心深く書く ミーティングに参加、モックアップやDBスキーマの作成、要求された機能へのパフォーマンスの心配 バグレポートを書く、過去のバグを検索 複雑なシステムの障害の原因を何ギガもあるログを探索して調べる ダウンタイムについてユーザーや上司への説明 他人の問題の解決へ協力 ドキュメント、本、ブログ、リリースノート、脆弱性アナウンスを読む 必要な既存の名前の分からないようなコードを探す 見つかったコードが自分の環境に互換性がありライセ
プログラマが知るべき、たったひとつの大事なことがら - Developers Summit 2011 - techlog
デブサミエントリのインデックスはこちら。 Developers Summit 2011 に行ってきた - まとめ - techlog 【18-B-1】プログラマが知るべき、たったひとつの大事なことがら 和田卓人 氏 和田卓人(id:t-wada)さんのセッション。 togetterのまとめはこちら。 だいぶ前にタイトルは決めなきゃいけないので、タイトルは釣り気味。 「プログラマが知るべき97のこと」は通称きのこ本、「97のきのこ」と空目したひとがいるから。 いちばんだいじなきのこ きのこ18番 学び続ける姿勢 今日話すこと。 read / write / talk 1996/07/22 コンピュータと出会う。 留学したホームステイ先の子供の心をマリオ3の無限1upで掴む。 2000 OO厨 オレオレOR Mapper / xsl書きまくり / テスト嫌い 完璧主義の呪い / 正しいモデルが
Life is beautiful: 私のとっておきのプログラミングスタイル
404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は７月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置で
第4回 オブジェクト指向の本質 | gihyo.jp
エンジニアとして良い仕事をするために必要なこと ソフトウェア業界で日米を往復しながら仕事をしていると、世界中のさまざまなエンジニアに会う。私のように「プログラミングを心底楽しんでいる」人から、「新3K」（きつい・厳しい・帰れない）を身をもって体験している人までさまざまだが、共通して言えることは、エンジニアとしての基礎がしっかりできている人とできていない人では、その生産効率に大きな開きがあり、それが結果的には、会社での労働環境や待遇に、そして結果として自分自身にとっての「仕事の充実度」に、大きな影響を与えているということである。 いつも締め切りに追われている、毎回バグで苦しんでいる、徹夜の連続で体力に限界がきているなど、「仕事がきつい」理由はいろいろとあると思うが、会社や上司の悪口を言う前に、自分自身がプロフェッショナルなエンジニアとしてこの業界で勝負をするうえで必要な最低限の基礎がで
「バグ数には興味ないのだよ」――顧客が喜ぶテスト仕様書とは？
「バグ数には興味ないのだよ」――顧客が喜ぶテスト仕様書とは？：誰にでも分かるSEのための文章術（11）（1/2 ページ） 「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 メーカーが機械を納入する際は、耐久試験や性能試験などの結果を添付して、問題がないことを顧客に確認してもらいます。同様にシステム開発においても、テスト結果を顧客に提示してシステムに問題がないことを確認してもらう必要があります。 今回と次回の2回にわたって、「テスト仕様書」の書き方と表現のポイントを説明します。 今回は、「顧客にとって良いテスト仕様書」とは何か、「顧客にとって良いテスト仕様書」にするためには何を記述すればよいのか、テスト仕様書のおおまかな
入門 自然言語処理を禁書にすべき10の理由 | TRIVIAL TECHNOLOGIES on CLOUD
みんなのIoT/みんなのPythonの著者。二子玉近く160平米の庭付き一戸建てに嫁/息子/娘/わんこと暮らしてます。月間1000万PV/150万UUのWebサービス運営中。 免責事項 プライバシーポリシー 「入門 自然言語処理」はヤバい書籍なので禁書にすべきだ。 タイトルは釣りじゃない。その理由を10個挙げる。 自然言語処理のかなり基本的なことからそこそこ高度なことについて解説されてあり，自然言語処理について理解が深まり過ぎる ボリュームがあるのに書き方が平易でついつい読みふけってしまう 演習問題があり，自分の理解度を確かめられたりするのもケシカラン 原著は欧米語のための言語処理について書かれた書籍なのに，日本語の形態素解析などについても解説してあって我慢できない 必要ライブラリのインストールなど環境構築に時間が取られそうでヤバい 書籍の応用でBotとか人工無能とか作ったらどうかな−，と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
