君は爺さん（婆さん）になってもエンジニアとして食っていけるか。：101回死んだエンジニア：エンジニアライフ
いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 ■エンジニアとしての寿命 一時期、「エンジニア35歳定年説」という言説が蔓延していた。人間である以上、年を取れば体力も気力も衰える。なので、エンジニアとしてばりばり働けるのは、せいぜいが35歳だろう。という内容だったと思う。 本当にそうだろうか。いろいろな視点から考えてみたい。 ■後継者がいないので、自然と現役でいられる 実際の現場を見ると、30歳半ばを過ぎてもいまだに一番下っ端で、年下がいない……なんて話をたまに聞く。実際、出生率がだんだん下がってきて、若い人が減ってきている。それに伴い、自然と現役エンジニアの年齢が上がっていく。その結果、35歳定年説を覆してしまうのではないか？ なんて思う。 また、現場が人を育てないため、業務をこなせる若い人が減ったり、企業も“
エンジニアにハッピーでいてもらうためにFacebookがしてること”Hackamonth” – TechDoll.
2日前くらいにFacebookを辞めたモバイルのGuruが書いたブログ記事を翻訳しました。FacebookのNoteとしてアップしてます。Joe Hewitt氏によると、Facebookは常にチャレンジすることを後押ししてくれる素晴らしい環境だったそう。そんな、エンジニアがハッピーでいられる環境を保つための新しい取り組みを先週Facebookが発表しました。その名も”Hackamonth”。 Hackamonthは、選ばれたエンジニアがいま在籍しているチームを離れて、自分が選んだサイドプロジェクト（主たるプロジェクトではない）の仕事ができるようにするもの。この取り組みの目的は、従業員の燃え尽きを防止すること。おまけに新しいサービスが生まれるかもしれない。 実際にいい感じの新サービスがこの取り組みから生まれているそう。ここ1年間で、Facebookは”Hackamonth”を35人のエンジニ
プロとしての行為 Act as Proffesional
スーパーエンジニア達の習慣が大人気だったので、自戒の意も込めて、反面教師として成長しないエンジニアの悪習慣について僕の経験と視点からまとめてみる。 業務時間外での学びがない プロ野球選手は日々練習をして、試合という本番で勝敗の結果を出して評価されるこれをエンジニアに置き換えると、どこかで練習をして、仕事という試合をして、ソフトウェアという勝敗の結果をつくりだす。プロ野球選手が試合を練習だと思って取り組んでいたら、結果を出せるのだろうか？ 業務外で練習をして、本番で良い結果を出せるように努力しよう。練習大事!! 時間をかければよいものができると信じているいくら時間をかけたって、バグのないエレガントなコードのソフトウェアはできない。効率的に仕様を満たしていくことが求められている。むしろ、時間をかけるべき所は上記で指している練習!! 参考：集中力を発揮して、生産性を高めるために知っておくべきこと
これはマネしたい！スーパーエンジニア達の習慣 | Act as Professional
いままで勉強会に顔を出し、すばらしいエンジニアと数多く会うことができた。そして、スーパーエンジニアと共に仕事をすることもできたし、できている。そんなスーパーエンジニア達が持っていた習慣を僕の経験と視点からまとめてみる。 自分が使う道具を厳選して選んで手入れをしているエンジニアでいえばエディタやツールなど。皆が使っているIDEやエディタを何も考えずに使い始めたりしない。 厳選したエディタやツールを使って、手になじませるのである。手になじませるというのは、2つの意味がある。 1つは操作性に慣れること。呼吸をするように自然に、キーボードの上を駆け回る心地よいリズムを奏でるエディタを選ぶ。 2つめは、自分に合わせて拡張しているということ。プラグインのON/OFFだけではなく、オリジナルのショートカットを設定し、適切なハイライト、シンタックスのチェック、コーディングルールのチェック、様々な言語への対
エンジニアを幸福にしないヤフーというシステム - 武蔵野日記
@nokunoさんのYahoo! JAPANを退職しましたという記事を読む。いまはタイトルに「翻訳」と書いてあるので紛らわしくないが、最初は「すわ id:nokuno さんがとうとう辞めたか?!」と釣られたものである (笑) 内容を読んでみると「まあ、そうだろう」という感じで、そんなに目新しいことが書いてあるわけではない (が、Yahoo! JAPAN の労働環境について知らない人が読むと「え、Yahoo! ってそんなところだったの??」とびっくりするかも)。著者も断っているが、これはアメリカの Yahoo! のことではなく、日本の Yahoo! JAPAN のことであり、Yahoo! JAPAN は外資系の会社ではなくコテコテの日本企業である (それが悪いと思うかよいと思うかは人次第)。 (2010-10-31 追記) Yahoo! JAPAN の環境がそんなによくないのは My New
エンジニアの生きる道は開発の現場だけじゃない - GoTheDistance
今まで1ミリも考えたことが無いのですが、せっかく定番のネタ｢エンジニア35歳定年説｣で色々エントリを拝見できたので、自分の｢モヤっと｣を整理しておきたいと思います。 発端となったyusukeさんの新プログラマ35歳定年説、あるいは2010年問題 (arclamp.jp アークランプ)は拡散的なので難しい所なのですが、言わんとしていることの1つに｢プログラミングだけを武器に35歳以降を戦っていくのはすごく大変だし、それができるのは一握り｣ってことがあると思います。僕もそう思います。 僕はプログラマとしての自分は凡庸よりちょっとマシぐらいだと思っているので、正直な所｢35になろうが40になろうがコードで力の差を見せ付けるぜ｣という気持ちがありません。常に前を走れる自信がありませんし、僕には必要無い。 ｢いやーこの案件は○○さんの腕が無いと決して出来なかったよ！｣って感じで純粋な技術力をもって自
エンジニアの不安と壁 - naoyaのはてなダイアリー
このところ、KLab×はてな エンジニア応援ブログコンテストというのを開催していまして、エンジニア人生に関するちょっとした小話をブログに書いていただくと、内容によっては、シリコンバレーに行けたり、iPad が貰えるかもしれない。という企画です。「え、ブログ書くだけでシリコンバレー? 」 なかなか太っ腹な企画です。 よい機会なので、宣伝がてら、自分もちょっと、昔話をしてみたいと思います。 振り返ってみると、自分がエンジニアとして経験を積むなかで、「ここが壁だったな」と思うところがぼちぼちありました。それが何で壁に感じたのかといま改めて考えると、いずれも体系的な知識がなかったために、それを乗り越えるための指針がなかったというのが大きかったように思います。 きれいなコードを書くにはどうしたらいいんだろう? 負荷分散って、どうやるんだろう? 溜め込んだデータをうまく活用するには、どうしたらいいんだ
どれくらい重要？ 技術者にとってのコミュニケーション力：わたしの愛するエンジニアライフ：エンジニアライフ
本音が語れるエンジニア参加型メディア「＠IT自分戦略研究所 エンジニアライフ」。日々、ITエンジニアの「生の声」を公開している。 ここでは、編集部の独断と偏愛によって選んだコラムをテーマ別に紹介していく。今回のテーマは「コミュニケーション」。 「エンジニアは技術力が最も重要だ」「いやコミュニケーション力だって大切だ」――こうした議論はよく存在する。果たして、エンジニアにとってコミュニケーションはどれくらい必要なのか、エンジニアに求められる「コミュニケーション」とはどのようなものか？ 「コミュニケーション」についての意見をまとめた。 技術力を生かすためにも、コミュニケーション力は必要 まずは「エンジニアにとってコミュニケーション力はとても重要」派の意見を紹介しよう。 サイオステクノロジーの山﨑靖之氏は、SEやPMとして働いた経験の中で「コミュニケーション力の重要性を思い知らされた」と述べてい
エンジニアにも役立つ！ 講師の「教育ノウハウ」ノート：わたしの愛するエンジニアライフ：エンジニアライフ
本音が語れるエンジニア参加型メディア「＠IT自分戦略研究所 エンジニアライフ」。日々、ITエンジニアの「生の声」を公開している。 ここでは、編集部の独断と偏愛によって選んだコラムをテーマ別に紹介していく。今回のテーマは「講師に学ぶ『教育者の心得』」。教える立場の人間が持っていたい心得やノウハウ、勉強方法をまとめた。 教える立場の人間が持っていたい心得×8 まずは、講師が人に教えるうえで気を付けている「心得」を学ぼう。IT講師として働く阿部直樹氏は、新入社員研修を行う際のポイントを3つ紹介している。 1つ目のポイントは、「研修の意味付けを行うこと」。新入社員は、教えてもらうのが仕事だ。だが、学校と会社では「給料をもらうか否か」という点が大きく違う。そのため、「教えてもらいながら給料ももらっている」という立場を、新入社員たちにしっかり認識させることが重要になる。 2つ目のポイントは、「新入社員
「天才エンジニア」でIT業界は変わらない | おごちゃんの雑文
相変らずITProが「勘違い奴隷育成キャンペーン」をやろうとしているように見える。 天才高校生はIT業界を変えられるか？ この高校生が偉いんだってことは、まぁそうなんだろうと思うけれど、大変残念ながら彼等がエンジニアになる限り、IT業界なんて変えられない。 彼等がどういったことをやって、どんな成績でどうであったかは「まぁ偉いんだね」とわかればいい。何であれ成果を出すのは良いことだから、そういった意味では評価されていい。まぁこの記事だけでは何が偉かったかまでよくわからないのが残念だけど、リンク先を見ればいい。 というのはまぁいいんだが、問題はこの記者の持っている期待だ。 それでも，マイクロソフトのビル・ゲイツやGoogleのセルゲイ・ブリン，ラリー・ペイジといった天才が世界を変えたように，保坂さんのような天才が将来，日本のIT業界を変えてくれることを，密かに期待してしまうのだ。 という部分。
livedoor Techブログ : tracerouteの仕組み
ネットワーク事業部 コアネットワークグループ所属の市川です。普段は、広域ネットワークの管理をしていて、端末に向かっていても頭の中は、1都3県を飛び回っています。 好きなポートは何番ですか？ 入社後エンジニア部隊に配属され、隣に座っていた同僚に挨拶をした時の返しの第一声が忘れられません。 「好きなポートは何番ですか？」 これって自己紹介なのでしょうか...それとも好きなポート番号から僕の性格が分かっちゃったりするんでしょうか？ところで、みなさんの好きなポートは何番でしょうか？ちなみにボクは、23番が好きでした（笑）。さて、私は現在ネットワーク事業部でネットワーク管理の仕事をしております。ネットワークにトラブルが発生した場合、状況調査に利用するツールでもっともメジャーな物に、ping/traceroute（windowsではtracert.exe）があります。 このtracerouteの仕組み
堀江貴文 エンジニアは誇り高くあれ｜【Tech総研】
東京大学文学部宗教学宗教史学専修課程中退。1996年に「有限会社オン・ザ・エッヂ」を設立。2002年に旧ライブドア社から営業権を取得し、2004年に社名を「株式会社ライブドア」に変更。2006年に証券取引法違反容疑で起訴されて一審、二審ともに有罪判決を受ける。現在上告中。1972年福岡県生まれ。 今、非正規雇用の増加やいわゆる「派遣切り」が社会問題になっていますけど、僕が前の会社（ライブドア）で社長をやっていたときは、技術者派遣やSI会社の常駐社員などは一切使わなかったし、逆に自社の社員を派遣することもしなかった。社内ではこうしたシステムを利用するようにかなり説得されたけど、ここだけは頑固に譲らなかった。 唯一、派遣会社を使ったのは受付の女の子たち。いろいろとあって押し切られてしまったのだけど、彼女たちが望めば正社員にしていたし、希望すれば総務や経理に異動もさせていた。ほかに社員でない人と
プログラマー面接時の技術的な質問事項(アプレッソ版) : 小野和俊のブログ
技術者・SE・プログラマ面接時の技術的な質問事項というエントリをはてブで見かけたのだが、私もjavaプログラマーの面接を割とよくやっているので、よく質問する内容をまとめてみた。 (ちなみに、基本的にコーディング面接の形態を取っている) プロジェクトの性質にもよると思うが、私の場合には、情報処理技術者試験的に基礎が満遍なく抑えられているかどうかよりも、 すぐ答えが見つからないような課題に対して、きちんと自分でやり方を考え、対応することができるか 「変な」コードをコミットしたりしないか(見つけにくいバグを混入させるとか、汚いとか、遅いとか)といった点を重視している。 まず、何を知っているかよりも、どんなものを作れるか、どんなことができるか、という質問。 ここで強烈な回答が来る人は、たいていここより下の質問は「あー、はいはい」という感じでサラッと答えてくることが多い。 これまでに携わってきた開発
エンジニアの勉強法について
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。 サービス統括部に所属しております、堀 邦明と申します。 普段はYahoo! JAPANトップページのフロントエンドエンジニアとして、JavaScriptやPHP,Perlといった言語を利用して開発しています。 この度、デベロッパーズサミット2009というイベントにおいてエンジニアの勉強法というテーマでJavaScriptの勉強法についてお話をさせていただきました。 今回は、そのときのお話について発表しきれなかった部分も含めてご紹介できればと思います。 勉強の分類 勉強には大きく分類して2つのステップがあると思います。 1. 情報収集 1つは情報収集です。 技術書やウェブサイト、ブログを読んだり、勉強会やセミナーに参加
勉強会は、講師と受講者のライブセッションだ － ＠IT自分戦略研究所
エンジニアの開催する勉強会が増えている。本連載では、かつてシリコンバレーで「勉強会の文化」に身を置き、自らも長年にわたって勉強会を開催し続けている「生涯一プログラマ」のよしおかひろたか氏が、勉強会に参加し、開催するためのマインドとノウハウを紹介する。 開催場所を見ると、さすがに東京が多い。しかしそれ以外にも、大阪、福岡、沖縄、島根など、日本全国津々浦々、毎日なにがしかの勉強会が開催されている。規模もほんの数人から100人を超える大規模なものまで千差万別である。 われわれはなんと勉強会が好きな国民なのか。一億総勉強会フリークなのか。 本連載「初めての勉強会」では、勉強会好きなあなたや、そうでないあなた、一度も勉強会に行ったことがないあなた、さまざまな人を対象に「勉強会」の面白さ、楽しさを伝えていくことを目的としている。自分は特に引っ込み思案で、人見知りだから、と思っている人や、一度も勉強会に
となりの技術者をイラッとさせる10の方法 - ぼくはまちちゃん！(Hatena)
人の画面をじっと見る あるいは人の後ろにずっと立つ。 人の画面を指で触る せめて爪側、できればペン等で…！ 作業中に話しかけて、そのまま長話 質問や要点をまとめておいてから→いまいい？って確認するとか。 急ぎでなければ、たとえ隣の席でもメールかメッセンジャー的なもので…！ 自分じゃなくても答えられる質問 その技術者が「誰でも知ってて当然だろ」と思っているようなことを質問しちゃうのはだめ。 逆に技術者が「これは俺の得意分野」って思っていることを質問すると機嫌が良くなる場合も。 知ったかぶりによる言語批判 「****(言語)って汚い or 気持ち悪い」 これを言うのはほとんどその言語をちゃんと使ったことない人ばかりでは…！ バグの犯人捜し・犯人叩き 開き直っちゃうけどバグが出るのは仕方がないよ…！ 日経新聞から得たような(あるいは広告業界特有の)IT(?)用語 「WEB2.0のインフルエンサー
ITエンジニアの「やってはいけない」---目次：ITpro
設計・実装から運用，メソドロジまで，最新アンチパターンを徹底解説 先輩から教わったことのなかに多くの「やってはいけないこと」（アンチパターン）があるだろう。だが，その理由を問われると，うまく説明できないことがあるのではないだろうか。突き詰めて考えると，状況によっては「やっても構わない」こともあるし，技術の進化に伴い「やれるようになってきた」こともある。そこで設計，実装，テスト，運用，メソドロジの各分野について，取材を通じて浮かび上がった最新アンチパターンを徹底解説する。テーマごとに「どれくらいやってはいけないか」のレベルも表した。レベル３～レベル１の３段階あり，レベルの数字が大きいほど，やってはいけない度合いも大きい。 関連サイト： ■設計編 ■メソドロジ編 ■実装編 ■テスト編 ■運用編 ■サーバー運用編 ■データベース編 ■セキュリティ編 ■記録メディア編 ■方式設計編 ■内部統制編
I, newbie » 技術者同士のコミュニケーションは腹の探り合い
別に、出方を探るとかいうのじゃなくて、「こいつ、どれくらいデキるのか」ってやつね。 能力の高低が問題なのではなくて、なるべく早めに相手のスキルを把握して、その後のコミュニケーションを円滑に進めようとする本能みたいなもの。営業ならともかく、技術者相手にもっともわかりやすい表現からコミュニケーションを始めるのは無駄が多い。「あ、これは通じなかったから、これなら通じるかな」と、徐々に低くするとか。もちろん、「あ、この人これはわかるんだ、じゃこれも大丈夫だろう」という反対のパターンも。そしてお互いのだいたいの水準がわかったら、それをベースに会話をする。 「F/Wでblockされてるみたい」 なんでそう考えたんですか? 「だって、ほらつながらないでしょ」 確かにそうですね(どんなエラーが起きていることを探そうとしてないな) 「ってか、ネットワークに問題あるよ」 なぜ?(調べもせずに結論に飛びついてる
Geekなぺーじ : 良いプログラマの見分け方
「How to recognise a good programmer」という記事がありました。 良いプログラマを見分けて雇用するためのTIPSが書いてありました。 原文前半では、Paul Graham氏が書いている「The 18 mistakes that kill startups, 日本語版:スタートアップを殺す18の誤り」というエッセーに書かれている「90年代のE-コマースで多くのベンチャーを失敗させたのが質の悪いプログラマであるが、プログラマではない起業家には良いプログラマと悪いプログラマを見分ける術がない。」といった内容に対して反論すると書いています。 見分け方をまとめると、以下のようになるそうです。 流石に全ての項目を満たすような人は少ないそうですが、どれか一つでもあてはまる項目があれば、それは良いプログラマなのかも知れないそうです。 原文には、詳細な説明があるので興味のある
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Act as Professional |