2016年になってから色んなソフトウェアエンジニアの人と話してきて、その中で3人から聞いた例え話、格言、小噺が面白かったので、僕の中だけで留めておかずに開放しておく。 息継ぎをするには『まず息を吐く』という例え話 水泳で息継ぎをするなら『まず息を吐きなさい』と教わるらしい。これは息を吐かずにどこかで息を貯めてしまうと、ちゃんと息を吸えないという事を意味してる。息を吐くと苦しくなって顔は絶対に水面に出る。 これと同じことがソフトウェアの学習にも言える。 つまりまずアウトプットする、なんでも良い。作ったものをGitHubに公開するとか、発表するとか、ブログやQiitaに書くとか。ちゃんとアウトプットしたものはフィードバックがあり、そのフィードバックを受ける(PRやissue, 質問, マサカリ etc)、どんどん吐き出していくと吸わないとネタがなくなるので、吸い込むためにまたインプットする。

この記事は，はてなエンジニアアドベントカレンダー2016の10日目の記事です．昨日は，id:dekokun によるVarnishによる一貫性を考慮した積極的キャッシュ戦略実験 - でこてっくろぐ ねおでした．今日は学生向け！フレッシュ！ こんにちは．はてなでアプリケーションエンジニアとして働いているid:Windymeltです． 今年の春から新卒として入社し，ようやく業務に慣れてきたものの，今までとはまったく違う環境での新生活に，ちょっぴり不思議な気持ちを味わっています． 私がソフトウェアエンジニアとして働いていることを知ると驚く人がいます． 私は法律系の学科を卒業しましたが，情報系の学科でないにもかかわらずソフトウェアエンジニアとして働いていることが意外に思われるようです． とはいえ，私は現在Scalaを主と使ってサービス開発に携わっており，日々なんとか設計とコーディングの経験を積むべく

どうも、坂津です。 皆さんは地雷ってご存知でしょうか？ 地面に埋まってて踏むと爆発するやつです。 何が厄介って、普通にしてたらどこに埋まってるか分からないところと、いざ踏んだ時の被害がえげつないところ。 爆発前に見付けても、撤去が難しいそうです。 なのでこんな器具で対処してるとか。 この球体は風に吹かれて地雷原をコロコロと転がるそうです。 で、地雷の上に乗っかると起爆。 「マイン・カフォン」という名前なんだって。 全壊はしないので、一球で３～４つの地雷を処理できるとのこと。 つまり地雷の処理は「起爆しないように慎重に撤去する」よりも「壊れても良い何かで爆発させる」方が効率的ということです。 加納「課長、11月分の集計資料ができました」 坂津「早いね！ありがとう。あー、もう12月かぁ・・・」 加納「呆けてる暇はありませんよ。殺到してます、ご注文が」 坂津「嬉しい悲鳴ってやつだね。よし、頑張ろ

システム開発の佳境に、開発メンバーが突然出社しなくなってしまう。 携帯にも連絡がつかず、3日ほど音信不通になったので、さすがに心配になった上司が大家と共に自宅を訪れると、夕日が差し込む部屋の真ん中に、当の本人が何の表情も浮かべずにただ座っていたりする。 そういう事は大して珍しいことではないので、ある程度経験のあるIT業界人なら、同僚が「消えて」しまってもそれほど驚くことはない。 プログラマというのは、とかく「消えて」しまうものなのだ。と彼らは思っている。 「消えた」プログラマは、意識的にしろ無自覚にしろ自分の人生をちょっとばかり台無しにしながら、プロジェクトに虚無の穴を空けるわけだが、そうした「工程の穴」は他のメンバーが残業したり、派遣会社から来た代替の人員が埋めてしまったりする。ビジネス的には人月で数えられた我々の「数字」などというものはちょっとした帳尻あわせでなんとかなってしまうらしい

2016-11-21 技術書の歩き方勉強会「達人プログラマー編」での資料です。 https://connpass.com/event/44500/

※最初に断っておくと職場やそこの人への愚痴などでは一切ありません。 客観的な職場の現状と自分のキャリアの希望のズレに言及した記事になります。 本記事について 現在大手Webサービス会社に新卒入社して7ヶ月経った。 だが、入社初期からずっともやもやしていて目をそらしてきたものがあるのでここで一旦言語化して整理したい。 記事の概要 ざっくり言えば、 「入社一年目はインプットが大量に必要だと思っているが自分が求めるインプットではなかった。自分の今後のスキルアップを考えたら今の環境にいるべきではない気がするが、今の環境で結果を出せていない事実もあるのでどうするのがベストか決めあぐねている」といった内容の記事を書く。 自分が職業エンジニアとしてやりたかったこと 自分は情報技術が好きである。 何かしらの大きな課題を前にしてそれを技術で解決することに憧れている。だから入社前はデータ分析職を希望した。よく

３０歳の若造なのに部署のトップになってしまい、今まで下っ端営業マンだった自分が数人の部下を持ってからもうすぐ１年。有給とはいえ特にやることがないので、この１年でやったことを書いていく。 ・細かいところまでとことん効率化 １０年前のやり方が化石のように現存していた部署だったので、毎日のように徹底的に効率化に励んだ。アナログで書いたり打ったりしていた書類を、せめてエクエルでと関数やマクロを組んでその人が理解するまで家庭教師みたいに一緒にやった。パソコン関係ではなく、細かい手順やルールまで「そもそもコレなんのために必要？」を毎回やって、徹底的に無駄を省いた。 ・定時退社おばけになった 定時がくると「定時ですよ～定時ですよ～」とフラフラと部署を歩き回るおばけになった。残って仕事をしている人には簡単に何をやってるのか説明してもらって、明日でも大丈夫そうだと自分が判断したものは「明日！明日！」と言いな

私は、プログラマとして30年以上仕事をしてきた中で、学んだことがあります。そのいくつかを以下にご紹介します。もっと挙げることもできますよ。 実物を見せないと、顧客の希望は分からない。 このことは最初の仕事で学びました。顧客は、実物を見るまでは、何が本当に必要なのかがよく分かりません。言葉で長々と説明するよりも、機能検証のためのプロトタイプを提示する方が確実に役立ちます。 十分な時間があれば、あらゆるセキュリティは破られる。 現代社会において、セキュリティを保つことは信じられないほどの難題となっています。プログラマは常に完璧を求められますが、ハッカーは1回でもハッキングができれば成功なのです。 セキュリティが破られた場合、事前にその状況に備えた対策を講じているかどうかで結果が変わってくる。 最終的にセキュリティが破られることを想定する場合、その時に起こることに備えて対策を立てておく必要があり

週末の午前中、カフェでアイスコーヒーを飲みながらふとポエムでも書いてみようかと思い立ってしまったので、ちょっと前からよく考えていることを書く。本当に思いつきで書くので乱文になる可能性が高いけどご容赦いただきたい。そもそもブログを書くこと自体が相当久しぶりだ。 僕ももう 30 をすぎて、プログラマの世界ではさすがにもう若手とは呼べなくなり、教育っていうのはおこがましいけど、まあ自分より若い人たちの指導みたいなことをやらないといけない立場になってきたからこそ、「いいプログラマとはどういう人なんだろう。この人たちはどういうことを学べたら幸せだろう。」ということをよく考えるようになった。そういう話をする。 プログラマは手段のスペシャリストである 世の中には目的・手段論みたいな論調が存在する。 「それは手段だよね。目的をはき違えたらダメだよ。」という話はいたるところでよく耳にするんだけど、僕はこれを

先に前提を話しておくと、会社は全く辞めるつもりはないし、むしろどんどん会社を良くしていこうと思っている。今回はそういう基準で自分がコードやドキュメントを書いていますよという話。 コードやドキュメントを書く時に、どのくらいきれいにしておくかとか、どのくらいわかりやすくしておくかとかを考えることがある。こんなとき僕は、いつ突然自分が会社をやめて連絡がつかなくなったとしても他の人がある程度理解できるか、を基準にしている。そのためにはあまりいい方法が思いつかなくて仕方なく書いている部分にはちゃんと経緯のコメントを書く。他にも例えば作ったサービスであるイベントを開催する方法のドキュメントを書くなら、全く何もやったことがない人がそのドキュメントを読んだらとりあえず開催できるよう、ドキュメントを書く。当然コードもかっこよさよりも、説明しなくても分かりやすくなるようなシンプルさを追求する。 また、このよう

（言葉遊びみたいな記事を書きますね。その上、用語の使い方が間違ってたらごめんなさい。） 一時期、フルスタックエンジニアって言葉流行りましたよね。ふと、要件どこまでだっけ？と思って調べようと思ったんですが、日本語で調べると、妄想が暴走してロクな話が出てこなそうなので、英語の方で調べてみるとわかりやすい。 What is a Full Stack developer? Server, Network, and Hosting Environment. Data Modeling Business Logic API layer / Action Layer / MVC User Interface User Experience Understanding what the customer and the business need. 個人的には、ネットワーク監視やデプロイなどのインフラ運用

プログラマーが使う思考の七つ道具 Programmers using 7 gadgets for thinking 2016.05.31 Updated by Ryo Shimizu on May 31, 2016, 06:48 am JST 「最速の仕事術はプログラマーが知っている」が売れたせいか、最近も「実践としてのプログラミング講座 (中公新書ラクレ)」なんてのを上梓したりもしているし、これまでプログラミングと縁がなかったいろんな媒体から「プログラマーならではの仕事の効率化を教えてほしい」と取材を受けることが多くなりました。 ・・・が、そもそもそういう話があるとすれば本に書いているので、いまさらあたらしいネタがポコポコあるはずもなく、まあ多少はありますがさすがに毎月記事にできるほどの被らないネタが出てくるわけ無いですよね。 でも、もしかすると意外とプログラマーは当たり前のように使って

新人の開発者が繰り返し突き当たるテーマがあります。プログラム言語を1～2種類勉強するのに時間を費やしたり、プログラミングの演習を行ったりすることに関して問題はないと感じていても、学んだことをどう応用していいのか分からずにいるのです。このことは、次のようなフレーズとしてよく耳にします。「プログラムの書き方は知っているが、何をプログラムしていいのか分からない」と。これに対する答えは、一般的に、「プログラミングの課題を行いなさい」、「オープンソースプロジェクトに貢献しなさい」、または、「ゲームを作りなさい」というようなものです。 プログラミングの課題を行うことは、知的ないい訓練にはなります。しかし新しいプログラムの開発方法を学ぶのにはあまり役立ちません。オープンソースプロジェクトに貢献するのは確かにステップアップになります。実際のプロジェクトがどのように構成されているか学び、プログラム言語の技術

エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 最近、メンター制度として新入社員や若手のメンバーに対して、先輩をつけて相談事に乗ってあげたり、仕事のサポートをしたりといったような教育プログラムを組む企業が増えています。このメンターという役割は、ちょっとした訓練が必要だったりするのですが、このあたりの研修や訓練をせずにいきなり明日からメンターね！なんてことがままあります。

Linus Torvalds / 青木靖 訳 2016年2月 (TED2016) クリス・アンダーソン 奇妙な話です。あなたのソフトウェアであるLinuxは何百万というコンピュータの中にあり、インターネットのかなりの部分を動かしています。さらに実際に使われているAndroid端末が15億台くらいあって、その１台１台にもあなたのソフトウェアが入っています。これはすごいことで、その開発本部ともなれば、さぞ大層な施設なんだろうなと思っていたので、この写真を見たときはびっくりしました。これがその — Linux世界本部なんですよね？(笑)(拍手) リーナス･トーバルズ 大したものには見えませんよね。この写真の中で最も興味深く、多くの人が反応する部分は、あのトレッドミル・デスクです。私の仕事場で一番興味深いものですが、私はもう使っていません。この２つは関連していると思います。私の働き方として、外的な