なぜプログラマはあなたの事が嫌いなのか - megamouthの葬列
営業やマネージャーにとって、現場にいるプログラマというのは扱いづらい存在である。 飲み会などで、普段の彼らを観察してみると。同じエンジニア同士で固まってボソボソとよくわからない話をして、控えめな声で笑っており、総じて温厚で、扱いやすそうな人々に見える。 ところが、仕事になると、彼らはなんやかんのと理由をつけて、スケジュールに文句を言い、プロジェクト途中のリクエストには素直に答えてくれず、あげくには遠回しな嫌味を言ってきたり、極端な場合には、その温厚な仮面を投げ捨てて、攻撃的な暴言さえ吐く事がある。 どうも彼らは我々の事が嫌いらしい、と感じている営業・マネジメント職の人もいるのではないだろうか？ 彼らの人格や価値観に問題がある可能性も否定しないが、このような感情的な齟齬は、多くの場合、あなた自身が彼らの「自尊心」を傷つけていることに気づいていないことが多い。 プログラマの自尊心 プログラミン
「2000年問題って大したことなかったですね！」と当時小学生だった自分の感想を述べたらSE陣がざわつき始めた
犬 @patriot_9 この前「2000年問題ってありましたよね。機械の時計が狂っちゃう、みたいな！全然たいしたことなかったですけど！」と当時小学生だった自分の感想を述べたら「＂たいしたことなかった ＂？」とSE陣がざわつき、素人の知らない部分で当時死ぬほど大改修・トラブル対応に追われていたことを知った 2016-11-06 01:58:34 犬 @patriot_9 ぼかぁねぇ、就職して初めて「世の中には自分たちが思いもよらないところで必死に支えてくれてる人たちがいる」ってことと「＂ハウルの動く城＂みたいにツギハギだらけでギシギシと音を立てながらなんとか無理矢理回ってる」ということを知りましたよ 2016-11-06 02:04:12
仕事を全自動化して6年間も働かず年収1000万円を得ていたプログラマーが最終的にクビに
By Nicola Albertini プログラマーは自分の仕事を減らすために便利なツールやソフトを作成することができることから、怠け者で愚かな人間ほど優秀と言われることがあるほどです。自作ツールを活用すれば単調で反復的な仕事の生産性を上げられるわけですが、なんと全ての仕事を全自動化して6年間にわたって給与を得ていたプログラマーが、最終的にクビになってしまったというredditの投稿をInteresting Engineeringが取り上げています。 Programmer Automates His Job For 6 Years, Finally Gets Fired, Forgets How To Code| Interesting Engineering http://interestingengineering.com/programmer-automates-job-6-year
ソフトバンク（旧ソフトバンクモバイル（旧ワイモバイル（旧イー・アクセス）））を退職しました - kariaの日記 @ Alice::Diary
2015年9月30日付でソフトバンクを退職しました。2009年に新卒で入社して以来6年半お世話になりました。この場をお借りして（っていうか自分のブログですが）お礼を申し上げたいと思います。ありがとうございました。 あんた誰？何してたの？ っていう質問が絶対来ると思うので書きたいんですが、それを書くと守秘義務だけでなく通信の機密にも触れる恐れがあるので詳細は控えさせていただきます。 焼きそばやチャーハンを焼くことはありませんでしたが、富士山には登りました。 タイトル長くね？ こういう経緯なので所属していた社名は変わりまくってますが、転職は初です。 イー・アクセスに新卒入社（イー・モバイルへ出向） イー・アクセスとイー・モバイルが合併 （ここでソフトバンクがイー・アクセスを買収） イー・アクセスとウィルコムが合併してワイモバイルに社名変更 ワイモバイルとソフトバンクモバイルとソフトバンクテレコ
「技術的負債」の返済ルールを作る 株式会社ドワンゴ 清水俊博 氏 | ギークアカデミー | dodaエンジニア IT
中堅SIerを経て2009年にドワンゴに中途入社。複数のシステムの開発に携わった後、エンジニアの生産性を高めることをミッションとする部署の立ちあげに参加する。趣味はプログラミングとネトゲ。 ドワンゴ清水俊博氏にドワンゴのエンジニア文化について聞いた。2012年4月の第1回「ニコニコ超会議」の後、ドワンゴのエンジニアが大量退職するという危機的な時期があった。エンジニア文化を立て直す社内組織に参加した経緯を聞く。 ──転職のきっかけはコミュニティ活動とのことですが、当時参加していたコミュニティjava-jaの雰囲気をお聞かせください。 java-jaでは、スキルがある人たち、技術力がある人たちに囲まれていました。ヨシオリ（java-jaを立ち上げた庄司嘉織氏、清水氏の元同僚）も当時はSI業界にいて、互いに話をして共感しあい、友人になりました。 java-jaは、ヨシオリが「勉強会」という呼び名
妻と一緒にいても生産性を下げないためにはどうすればよいか - 西尾泰和のはてなダイアリー
Tweetに対する反応まとめ nishio: 妻にWebDB Pressを渡して会社に行って帰ってきたら「プッシュ型メディアはエンジニアの生産性を下げる」を読んで「妻もプッシュ型メディア」とか言ってる nishio: 既婚のエンジニアに聞きたい：妻と一緒にいても生産性を下げないためにはどうすればいいのか 不倫する Yappo: 不倫する nishio: 「不倫したらメディアが増えるだけじゃないか！」と怒ってます＞妻 Yappo: 愛人はプル型メディアです。とお伝えください＞＜ そうなのか… 例えば、妻を避ける tokuhirom: unsubscribe bulkneets: 無視するといいです hayamiz: 例えば、妻を避ける （＞＜） 物理的ファイヤーウォール pandeiro245: 僕はクローゼットの中で仕事してます。 それはなかなかよさそう！集中できそうだし。妻は広いクローゼ
ニコニコ動画 新プレイヤーから考える経営陣の無能さ - 埼玉こそ最強
動画プレイヤーの不満はさんざん書かれていますのでここでは述べません。このエントリーはこの話を材料にニコニコの経営陣への疑問を呈することが目的です。 プレイヤーのまずいところの象徴はコメント欄の位置です。どう考えても使いにくい。なぜこれに誰も異をとなえなかったのか？という疑問があります。推測、というか普通の会社組織ならといったほうがいいかもしれませんが、これに異をとなえることができる人数は実はごく少人数なのです。すなわち、技術部門のトップ、そして経営（もちろん開発チームはあの位置で全く問題ないと考えていることが前提）。なぜか？ 組織というものは原則、組織同士で利害関係がぶつかる場合は調整行動に出ますが、自分の組織に関わりのないことは基本的に手を出しません。例えば生放送プレイヤーの開発チームの誰かが｢なんか動画チームの使いにくいんで僕つくってみました｣なんてことをやることはできません。いや、組
はてな退職しました - 2nd life (移転しました)
7/16 が最終出社日*1となり、はてなを退職しました。はてなブックマークでのチュートリアル機能がはてなでの最後の仕事となりました。 はてなに入ってからを振り返ってみると2006年1月にはてなに15番目の社員として入社し、4年7ヶ月はてなのメンバーと一緒に働いてきました。当時はまだ誰も辞めていなかったため、過去はてなで働いた人すべて一緒に仕事をしてきたことになります。入社時はまだオフィスが東京にあり、毎日全員が朝会でディスカッション、時には数時間も熱く語るというエキサイティングな職場だったのがとても印象的でした。 当時は本当に自由な環境でいろいろな事を試行錯誤していた日々でした。入社約2ヶ月で、会社のフレームワークに DI の概念を実装したころで Perl もう無理と投げ出して Perl を書かない仕事ばっかりやっていたのも今となっては良い(?)思い出です。今だったらあり得ないですねほんと
ニート社長のブログ - アイマス動画「3A07 -Memories are here-」から考えるプロジェクト運営（前編）
※今日のブログは思考過程をダラダラと記述しているため、とても長いです。 ブログ後半の最後に、「まとめ」を書きますので、暇でない方はそちらをどうぞ。昨年末から、「3A07」の制作について、ずっと考察したいと思っていましたが、なんだかんだで後回しにしてしまい、やっと今になって書いています。昨年、11月23日に「3A07」という動画が投稿されました。http://www.nicovideo.jp/watch/sm8893602かなり話題になりましたので、ご存知の方も多いかと思います。超面白かったので、見てない方は「初回コメ無し最大化必須」で、見てみてください。で、動画内容も素晴らしいのですが、それと合わせて 「超高品質アニメーションを、たった3人で半年間で作り上げた」という、制作過程自体でも、にわかに信じがたい程のプロジェクト運営をしています。この事例を、システム開発のプロジェクト運営にも活か
ユメのチカラ: 開発工程を別々に担当してはいけない
古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更
コメント: PHPは駄目な言語なのか? - スラッシュドット・ジャパン
趣味でやっている人のことは、まあ、いいとして（踏み台にされる可能性はあるけど）、仕事でPHPを使うときの注意を書いておこう。 コーディング規約を守る。組織にコーディング規約がないなら、Zend Framework PHP標準コーディング規約 [zend.com]を使う。オレ流コーディングスタイルは禁止。 内部コードにはEUC-JPかUTF-8を使う。入出力もできるだけShift JISを避ける。Shift JISを使う場合には2byte目に0x5Cを含む文字の動作を忘れずに確認する。 開発環境の警告レベルをE_STRICTにする。本番環境ではdisplay_errorsをオフにする。 register_globals、magic_quotesはオフにする。 type hintingを積極的に使う。 スコープの長い配列をクラスでラップする。 プレゼンテーションとロジックを分割すること。プレゼ
「プログラマ35歳定年説」:ITと人間の意外な関係 - CNET Japan
あるサイトで連載の話を進めていて、そのコンテンツを考えていた。目次を書き出しているときにふと「プログラマ35歳定年説」なるものを思い出した。 プログラマ35歳定年説とは、「プログラマは年齢を重ねて行って、35歳ぐらいになったらSEなりマネジメントなり、次に行かないとオマンマ食べられないよ」というものだ。 「そういえば、自分もそう言われてきたっけ・・・。若いころは「俺たちがシステム作ってんだ！実力があれば絶対に大丈夫。ふざけんな！」と思っていたよなぁ。」 ふと考えれば私は今36歳。その説によれば定年を迎えている年齢だ（笑）。年金はもらえないが・・・。 プログラマ、SE、マネジメント、経営の一通りを経験してきて、その説の私なりの考えを書いてみたくなった。 35歳プログラマ定年説は本当か？・・・私にとって かつては技術力に自信があったし、楽しいプログラマ人生を送ってきた。そんな私だが、今もし誰
コードに入らずばコーダーを得ず : 404 Blog Not Found
2007年11月21日00:00 カテゴリArt コードに入らずばコーダーを得ず これを見て(38|0x26|046)な俺も書きたくなった。 36歳になって思う「プログラマ35歳定年説」:ITと人間の意外な関係 - CNET Japan プログラマ、SE、マネジメント、経営の一通りを経験してきて、その説の私なりの考えを書いてみたくなった。 久しぶりに「私」でなくて「俺」で書く。 36歳になって思う「プログラマ35歳定年説」:ITと人間の意外な関係 - CNET Japan俺に限って言えば・・・35歳定年説は本当だった。というより、プログラムを動かすことより、人を動かすことに魅力を感じてしまったのだから、ずっとプログラマだったらどう思うかというのは残念だがわからない。 俺は、実のところプログラムを動かすのと同じぐらいかそれ以上に人を動かすのも人に動かされるのも好きだ。 だから、わかる。 プロ
ニッポンIT業界絶望論:江島健太郎 / Kenn's Clairvoyance - CNET Japan
日本のIT業界は救いようがない。絶望的としか言いようがない。 IT業界不人気なんて、この業界に重くのしかかる決して晴れることのない暗雲の氷山の一角に過ぎない。はてなの匿名ダイアリーにもどうせ理系出身者なんていらねえんだよ。なんて書かれていたけど、これが現実なのだよ、学生諸君。 ちょっと補足しておくけど、ここでIT業界っていうのは、SIerのことだ。お客さんの要件をヒアリングして、その要求に沿ったシステムを受託開発するっていうビジネスのことを指している。 ぼくもその昔、その世界のループに組み込まれていた。そして華麗なるコミュニケーション能力とやらをいかんなく発揮し、場の空気を読み、生意気なぐらいのチャレンジ精神で、それなりに仕事のできるよい子だったようだ。 いや、正直に言うよ。正直に言うとだね、結構楽しかった。 だって、考えてみてごらん。お客さんのところに出向いて行って、その業界のことをじっ
もってけ！仕様書:アルファルファモザイク
「梅田に行って地獄を見るか、南港に沈められるか、今金を出すか」強盗３人組を逮捕 大学生を殴り現金を奪う
要件定義カード1枚8万円──脱・人月商売宣言 － ＠IT
「1タスク8万円」という価格体系を提示し、人月商売からの脱却を宣言するスターロジック代表取締役兼CEO 羽生章洋氏 「二度と人月商売はしません」──スターロジックは7月19日、都内で開催した自社イベント「StarLogic Conference2007」において、エンドユーザー自身による要件定義に基づき、「要件定義のカード1枚当たり8万円（税別）」という価格体系でシステム構築ビジネスを進めていくと発表した。従来の「人月」に基づく見積もりと比べて、1/3から1/5の価格になるという。 「人月換算でコストを請求する商習慣こそが、SI業界のさまざまな問題の根源。人月から脱却するには、納得でき、分かりやすい価格体系を提示することだ」（スターロジック代表取締役兼CEO 羽生章洋氏）。 低コストにできる理由は、ユーザー自ら要件定義を行い仕様を最初に明確にする点と、実装段階で自動生成により生産性を追求し
はてなブログ | 無料ブログを作成しよう
顔に見える？最近「送水口」が気になるという話 「送水口」が気になる今日この頃 最近街中で気になる存在、それがこの「送水口」です。地上のフロアが7階以上あるビルなど、一定の条件を満たした建築物には設置が義務付けられているもので、火事が発生したフロアにただちに水を送るために使われるものです。ポンプ車…
どうしてプログラマに・・・プログラムが書けないのか?
Jeff Atwood / 青木靖 訳 2007年2月26日 レジナルド・ブレイスウェイトが書いていることを読んだとき、私はそんなわけないだろうと思っていた。 私と同様、この著者は、プログラミングの仕事への応募者200人中199人はコードがまったく書けないということで苦労している。繰り返すが、彼らはどんなコードも書けないのだ。 彼が引用している著者というのはイムランのことで、彼は単純なプログラムも書けないプログラマをたくさん追い払っているということだ。 かなりの試行錯誤の末に、コードを書こうともがいている人たちというのは、単に大きな問題に対して苦労しているのではないことがわかった。やや小さな問題(連結リストを実装するというような)に対して苦労するということでさえない。彼らはまったくちっぽけな問題に苦労しているのだ。 それで、そういった類の開発者を見分けるための質問を作り始め、私が｢Fizz
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IT技術者がいない みずほ不安の「2020年問題」 - 日本経済新聞
http://programmer-wanted.capcom.co.jp/