エンジニアのキャリアを考える際に刺さった記事三選えふしんのWebサービスサバイバル術 藤川真一（えふしん） FA装置メーカー、Web制作のベンチャーを経て、2006年にGMOペパボへ。
何故僕はエンジニアとして対外発表をするのか | おそらくはそれさえも平凡な日々
僕は本来、人前に出て積極的に話そうとは思わないし、目立たずにおとなしく引きこもっていたいみたいな気持ちがある。潔癖な部分もあるので、プレゼンスばかり高くて技術力がないような中身が無い人間になりたくないし、そうなったら死ぬしか無い、みたいな気持ちもある。それなのに何故、ものすごく技術力があるわけではない自分が対外発表をするのか。 それは元はと言えば対外発表をするような側に行かないとエンジニアとして生き残れないのではないかという危機感があったからです。 Shibuya.pmの衝撃 初めて参加したShibuya.pmは#10だった。その頃の僕は一企業のよくある何でも屋の1人システム担当であり、開発のメインは前担当者から引き継いだレガシーASPだった。そしてつぶしの効く技術を習得したいと思いPerlを学び始めた頃だった。そしてPerlがそこそこ書けると手応えを感じ始めているところだった。 ところが
あ、これ新卒の時からやっときゃよかったなってこと - アナログ金木犀
2011年5月からインターンで、翌年から新卒入社して今に至るまでエンジニアとして生きてきて、最近になってこれをやっておけばエンジニアとしての成長早まってたなって気づいたことを列挙します。 モノをつくって公開することで自分の”名刺”を作る SHIROBAKOというアニメの瀬川さんの名言がこれです。 クリエイターには関わった話数一本一本が名刺代わりってこと。 これってエンジニアにもすごく言えるなって思います。 エンジニアにとっては作ったモノがそのままその人の名刺なんですよね。 逆に言えば、モノがない人は名刺がないのと同じ状態とも言えます。 新卒の時から、なにかアプリや WEBサービス、もしくはライブラリでもいいから作っておくべきだったなと思い反省しています。 いや、実際は作ってはいたのですが、「学習のためだから」と言い訳して、しょぼいからと恥ずかしがって人に見せることはしなかったんですね。 し
A/B テストで施策の効果を検証！エンジニアのための R 入門 - クックパッド開発者ブログ
こんにちは、買物情報事業部でサーバサイドの開発を担当している荒引 (@a_bicky) です。 今回のエントリでは R で A/B テストの結果検証を行う方法の一例について紹介します。 エンジニアでも自分の関わった施策の効果検証のために簡単な分析をすることがあるかと思いますが、そんな時にこのエントリが役立てば幸いです。 なお、次のような方は対象外です。 A/B テストや KPI の設計に興味のある方 この辺には全く触れません プログラミング初心者 わからない単語が大量に出てくるでしょう R で統計学や機械学習の手法をバリバリ使いたい方 世の中の “分析” の多くは集計処理がメインです Python, Julia など既に分析する上で使い慣れた言語・ツールがある方 今回のエントリ程度の内容であればわざわざ乗り換える必要もないでしょう OS は Mac を前提として説明するので、Windows
炎上案件に突如ディレクターとして投入されたときにやってみたこと - Qiita
ぼんやり1メンバーとして眺めていたプロジェクトが、リリース1週間前になって「あれも足りない！これも出来てない！どうすんじゃゴラァ」となったときに突如ディレクターとしてぶっこまれ投入されたときにやってみたことのメモ。 一次対応 とにもかくにもPJTに投入されて最初にやったこと。 コミュニケーションルールをみんなで確認して、守ってもらうようにした 誰が何の情報を持ってて、そして誰から誰にどんな指示が出てて、それらがどんなステータスか、、、 もうぐっちゃぐちゃになっていた。 ディレクターは一度死ぬが、一旦全部ディレクターに報告させて、ディレクターから適切な人に指示を出すことにし、メンバー同士でのダイレクトなコミュニケーションをいったん、原則禁止した。 （ディレクターがAさんとBさんで直接やって、と指示を出すときもあるが、それもやりとりの結果をAさんから必ずフィードバックさせるようにした。） ただ
あるエンジニアの挫折と変節
メーカー勤務のエンジニアがいかにキャリアチェンジに失敗し、価値観の転換を迫られ変化しつつあるかについて記す。 話は2009年頃にさかのぼる。リーマンショックと円高、さらには震災により日本の電機業界は縮小を余儀なくされ、度重なる大手企業のリストラ報道に触れることで自らのサラリーマンエンジニアとしてのキャリアの継続に不安を覚えるようになった。 それ以前から自らのスキルの中核が会社の本業とは少しずれたソフトウェア、Webよりのところにあることを自覚しており、その分野での知識、経験を伸ばすことでエンジニアとしての成長、生き残りの手段と出来るのではないかと考えるようになった。 もともとネット依存な傾向と学術的な活動への未練があってはてな界隈でのの情報収集を行っていたのだが、その中で見いだしたのが機械学習関連の勉強会であった。Web業界を中心とした技術勉強会は2008~2009年頃からツイッターなどの
初めてエンジニア面接をすることになって準備したことと反省 - yashigani?.days
photo by MDGovpics 技術面接を担当する機会があった． 今まで，面接されることはあってもする側になるのは初めて． 短い時間でよい成果を得るため，事前に色々と準備をしてから望むことにした． 最初に 面接といえば質問だ． 逆に言うと質問の集合が面接と言っても差し支えない． そこでなにを質問すべきか考えた． 採用面接の目的は一緒に働く仲間(を増やす|になる)ということだ． つまり，お互いに一緒に働きたいと感じるエンジニアなのかを判断できればパーフェクトコミュニケーションと言えるだろう． 事前準備 会話は3往復くらいさせると深く人となりがわかるらしい． なにも用意しないとそんなのは絶対無理なので，事前に質問を用意しておく． エンジニアの場合，応募資料はだいたい以下の2つがある． ブログやGitHubなどインターネットでの活動 職務経歴書 この2つからエンジニア像を作りつつ，質問した
プログラマが知るべき97のこと
プログラマが知るべき97のこと大人気の書籍『プログラマが知るべき97のこと』のエッセイを無料で公開中！すべてのプログラマにおすすめの本がウェブで読めるようになりました。 エッセイ一覧分別のある行動関数型プログラミングを学ぶことの重要性ユーザが何をするかを観察する（あなたはユーザではない）コーディング規約を自動化する美はシンプルさに宿るリファクタリングの際に注意すべきこと共有は慎重にボーイスカウト・ルール他人よりまず自分を疑うツールの選択は慎重にドメインの言葉を使ったコードコードは設計であるコードレイアウトの重要性コードレビューコードの論理的検証コメントについてのコメントコードに書けないことのみをコメントにする学び続ける姿勢誰にとっての「利便性」かすばやくデプロイ、こまめにデプロイ技術的例外とビジネス例外を明確に区別する1万時間の訓練ドメイン特化言語変更を恐れない見られて恥ず
技術力がつかない負の流れに陥ってしまった。 - 東京アンダーグラウンド
最近自分がとらわれている負のスパイラルについて、思うところがあって書いてみた。 吐き出せば楽になれるかもしれない。 例外的な人はもちろんたくさんいると思うけど、一般的にSIer社員は技術力が低いと言われている。 たしかに自分の周りのSI社員にまともにコードを書ける人なんていないし、話に出るのは1990年代から2000年代のテクノロジーだ。 業務中にプログラミングをするときは、それが業務を改善するためのものであっても、周りの目を気にしてIDEを開く。 隙間の時間に、ほんの少しだけ。 手を動かさないと技術が身に付かないのは事実で、そういう意味だと、SI社員が技術を身に付ける時間は非常に限られている。 少なくとも、業務中に技術的なことをやる時間はほとんどないので、何かを身に付けたいときは、業務外に頑張って時間をとって勉強しなければならない。 家に帰ってからが勝負になる。 例外的な人になるためには
4月から新卒エンジニアになる人達に読んでほしいIT系ニュースサイト9選 - paiza times
Photo by Petras Gagilas こんにちは。谷口です。 来年度にITエンジニアとして新卒入社をされる皆さんは、IT系のニュースや情報の収集はどうやってしていますか？ 先日弊社が開催いたしました、学生の方向けの勉強会でも「就活中や入社前に見ておくと役立つサイトはありますか？」「入社後はどういった情報サイトで情報収集や勉強をすると良いですか？」といった質問が多く寄せられました。 paizaでpizzaを食べながらもぐもぐ勉強会レポート - paiza開発日誌 そこで今回は、4月にエンジニアとして新卒入社をされる方々が、デキるエンジニアになるためにチェックすべきIT系情報ポータルサイトを9件ご紹介いたします。日々の情報収集にお役立ていただければと思います。 ■IT系情報サイトまとめサイト9選 ◆1.ITmedia http://www.itmedia.co.jp/ ITmedia
「これを読まねばプログラマーではない」Twitterエンジニア蓑輪氏おすすめの名著2冊と、技術書の読み方
ひげぽん氏オススメ！ エンジニアが絶対に読むべき名著2冊 西村：ということで、色々お話を伺ってきました。趣味でOSを作って言語処理も作ってIPAで採択され、今や世界的な企業であるTwitterに入られてアメリカに行って、シリコンバレーでエンジニアとして、サンフランシスコで活躍されるという、ある種すごい憧れの存在だと思うんですけど。 そういうひげぽんさんから、今まさにこれからエンジニアとしてキャリアを積んでいこう、スキルアップしていこうと考えてらっしゃる画面の前のエンジニアの皆さんに、アドバイスがあればぜひお願いしたいんですが。 蓑輪：わかりました。まずはですね、エンジニアの皆さんも技術書を読むと思うんですけど、その時に1つだけ僕が気をつけていることがあって。それは何かって言うと、技術書を買ってきて読むわけなんですけど、読んだ時に「わかったわかった」っていう感じで自分がわかったつもりになって
SE的声かけ変換表 - Qiita
効果的にコミュニケーションする 会話は相手と共感するところから始めます。言いたいことは同じでも、言い方を工夫することで相手とより良いコミュニケーションをとることができます。 うまく物事が伝わらないと思ったら、言い方を変えてみましょう。 だめだと分かりながらついついやってしまった自分の過去を反省しつつ、参考にしていただければと思い公開します。
何でもデバッグできるようになるスキル - ワザノバ | wazanova
https://www.youtube.com/watch?v=VV7b7fs4VI8 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 パッケージ（apt, yum, gem等）レポジトリのホスティングサービスであるPackageCloudを開発している、James Golickの講演です。 パフォーマンスの高いハイクオリティなソフトウェアをデプロイしたければ、あらゆるレベルでバグ修正ができるようになること。 まず、エピソードとして紹介しているのが、友人の会社のサイトが落ちて、あいにく、その会社のエンジニアが出払ってしまっていて、どうにかしてほしいと助けを求められたときのこと。 ソースコードを見たことない。 システムの構成を知らない。 phpは詳しくない。 SSHでアクセスできる情報だけはある。 とい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアのための経営学