知っていてこだわらない、それがいいソフトウェアエンジニアの条件なんだと僕は思うんだ - assertInstanceOf('Engineer', $a_suenami)
週末の午前中、カフェでアイスコーヒーを飲みながらふとポエムでも書いてみようかと思い立ってしまったので、ちょっと前からよく考えていることを書く。本当に思いつきで書くので乱文になる可能性が高いけどご容赦いただきたい。そもそもブログを書くこと自体が相当久しぶりだ。 僕ももう 30 をすぎて、プログラマの世界ではさすがにもう若手とは呼べなくなり、教育っていうのはおこがましいけど、まあ自分より若い人たちの指導みたいなことをやらないといけない立場になってきたからこそ、「いいプログラマとはどういう人なんだろう。この人たちはどういうことを学べたら幸せだろう。」ということをよく考えるようになった。そういう話をする。 プログラマは手段のスペシャリストである 世の中には目的・手段論みたいな論調が存在する。 「それは手段だよね。目的をはき違えたらダメだよ。」という話はいたるところでよく耳にするんだけど、僕はこれを
K のこと -- steps to phantasien t(2007-11-03)
友人の話をしよう. 先達に敬意を表し, 仮に彼を K と呼ぶ. (イニシャルは便宜的なものだ; 向上心云々と罵ったこともないし, 恋人を寝取ってもいない.) ある時期, 私は K と一緒に働いていた. 今は違う会社にいるけれど, 互いに暇なのか, このごろもよく二人で管を巻いている. 1 K は優秀なプログラマだ. いつも敵わないと思う. 一緒に仕事をしていたこともあり, プログラマとしての私は K から強い影響をうけている. たとえば私が自動テストを始めた発端には K がいる. コードレビューもそう. この日記に出てくる話も K の影響は色濃い. 私は K のあとを追いかけるようにプログラマを続けている. K と働いてはじめて, ああ, 物事とはこう改善していくものなのかと知った. 何か問題を感じると K は試行錯誤を始める. 問題は私が諦めていたものもあるし, そもそも気付かないものも
プログラミングが楽しいと思えないのは悪いことなのか
ここ半年ほど、「プログラミングを職業とすることの意味」を考え続けています。私自身は職業プログラマではないので、プログラマ向けの各種サービスを取材して、何とか手がかりをつかもうとしています。これまでに、技術情報共有サービス「Qiita」、競技プログラミングサイト「topcoder」、技術者が企業を気軽に訪問できるきっかけを提供する「Wantedly」、技術者が得意なスキルをアピールできる「Forkwell」、プログラミングの実力を測定できる「CodeIQ」や「paiza」を取材しました。 そうした取材の成果は、折に触れてITproや日経ソフトウエアにまとめています。具体的には、ITproの「『プログラマの役に立つものを提供していきたい』、情報共有サービス『Qiita』の挑戦」や「『60万人の一流プログラマ』が『成功率93％のSI』を実現するtopcoder」といった記事です。このテーマの集大
4年前、おれがSIerの片隅で、何者でもなかった頃 - たごもりすメモ
今からちょうど4年前の2010年2月、某巨大SIerの片隅でExcelやPowerPointばかりを眺めて過ごしていた頃、おれは仕事でも仕事以外でもコードなんかまったく書いていなかったし、GitHubのアカウントも持ってなかった。毎日見積書とWBSと納品書と請求書と、Excel方眼紙の詳細設計書と格闘してた。 当時おれは30歳だった。一度はプログラマとして生きるのは自分には無理だと思って入社したSIerで数年やってて、そこそこ成功した数年を送っているとは思っていたけど、でもやっぱり、そんな毎日に飽きていた。 技術力を重視とか言いながらプロパー社員にコードを書かせようとしない会社の方針にも、svnもgitも閉じられててガチガチに監視されたネットワークに繋がせておいてオープンソースがどうのと言う文化にも、手順や履歴を重視とか言いながらロクにバージョン管理システムを使おうとしない一部の同僚にも、
プログラマが満たすべき最低基準って？ - (define -ayalog ’())
日記 プログラマとしての最低基準って何？ 言語の仕様を知ってることが最低基準？ 3つ以上の言語を手足のように扱えるのが最低基準？ モノを作れることじゃなくて、色んなことをたくさん知ってることが最低基準？ 「なんで、こんなことも知らないの？」って人のやる気削ってるだけじゃん。 2013-07-18 17:16:45 via web なんだろう。昨日くらいからJavaの参照の値渡しに関する話がバズってる。 あえてリンク貼らないけど、だいたいこれ読んでる人は知っているでしょう。 そんな中で、どうしても目に入ってくる雑音*1が気になる。 「10年間も知らなかったの？」とか「こんなの知ってて常識だよね」とか「言語仕様を読むよね、普通」とか「レベルの低い技術者は辞めたらいいのに」とかとかとかとか。 間違いを正してあげようとするのは良い事だと思う。だけど、それに余計な言葉をひとつもふたつもくっつける必要
プログラマ辞典: 【所感】300時間働いても疲れない10の方法（プログラマ編）
これまで実戦の中で学んできた、長時間働いても疲れない10の方法。 1. 食べない 割とポピュラーな方法。いわゆるダイエットハイを利用した手法で、野菜ジュースとかユンケルとか飲んで、食べ物は昼におかゆかパスタを少量食べるくらいで、朝と夜は食べない。2週間くらいはこれで持つ。これをやると4時間睡眠とかでも昼間眠くならずバリバリ働ける。2週間以上やると死ぬような気がする。危険な方法なので真似はしないでください。 2. 時々、アルファ波を出す 本当にアルファ波が出ているかは不明だけど、とりあえずそういうのが出ている系のイメージを頭に流す。長時間連続して集中すると疲労が溜まりやすいので、そういう脳の方向の偏りを短時間で効率良くリフレッシュをする感じ。人がいないところでやる方が効果的。 3. 夕食を軽くする 1の方法に近い。寝るときに腹に何かが入っていると回復が遅くなるような気がする。ので、個人的には
エンジニアよ、ゼネラリストなんて目指すな！―VASILY 金山裕樹のキャリア論［2］ | キャリアハック（CAREER HACK）
イケてる人材は3つの“Ｊ”を持っている ―VASILY 金山裕樹のキャリア論［1］から読む 大手企業とスタートアップとの、決定的な違い。 ― 金山さんは、大手企業とスタートアップの両方を経験されていますよね。両方で求められる能力に違いは感じますか？ まったく違うと感じます。決定的に違うのは、ビジネスとして「成立させる」フェーズ。そこにくると、必要になるスキルが全然違うんです。 大企業の場合は、すでに独自の強いビジネスモデルってものがあるんですね。すごく雑な言い方をすると、“Yahoo! の強み”って「どんなページを作ったとしても、広告が入って、収益があがる」ところなんです。Yahoo! として広告がガンガンまわっているから、極論、あとは“どれだけ低コストで広告が入るようなページを量産できるか”の勝負なんです。あとは、自分がやりたいことをビジネスモデルに“どうはめるか”だけを考えればいい。
プログラマの実力は経験だけであがらないことがレベル格差につながる - きしだのはてな
プログラマというのは、道具に慣れることが、実力があがることにならないのですよね。だから、勉強せず業務経験だけだとレベルが低いままということになってしまう。 Javaを10年さわり続けて、Strutsを5年さわり続けても、それだけでは、与えられた画面を手際よく作成できるようになるだけで、たとえばStrutsすらよりよく使えるようになるわけではなかったりする。 Javaにしても、「volatileってなんですか？」という問いに、まあ知らないのはしかたないとしても、解説を見ながらですら答えられない可能性がある。 プログラムの反復生産は、プログラミング能力の向上にあまりつながらない。設定や記述に慣れるだけだ。そして、この「慣れ」というのには「難しいからそもそも実装を回避する」というようなものも含まれる。実力の向上は、作業ができるレベルで止まってしまう。 プログラマとしての実力をあげるための勉強が自
リーダブルコード
美しいコードを見ると感動する。優れたコードは見た瞬間に何をしているかが伝わってくる。そういうコードは使うのが楽しいし、自分のコードもそうあるべきだと思わせてくれる。本書の目的は、君のコードを良くすることだ。（本書「はじめに」より） コードは理解しやすくなければならない。本書はこの原則を日々のコーディングの様々な場面に当てはめる方法を紹介します。名前の付け方、コメントの書き方など表面上の改善について。コードを動かすための制御フロー、論理式、変数などループとロジックについて。またコードを再構成するための方法。さらにテストの書き方などについて、楽しいイラストと共に説明しています。日本語版ではRubyやgroongaのコミッタとしても著名な須藤功平氏による解説を収録。 正誤表 ここで紹介する正誤表には、書籍発行後に気づいた誤植や更新された情報を掲載しています。以下のリストに記載の年月は、正誤表を作
尊重されたいすべてのソフトウェアエンジニアへ - たごもりすメモ
自分はソフトウェアエンジニアとして毎日の糧を得ている。今のところはサラリーマンエンジニア以外の存在になる予定はない、が、とはいえ唯々諾々とつまんない仕事ばっかりやる毎日はできればごめんだと思っている。コードを書くのは楽しいからコードを書ける仕事をしたいし、特に面白い問題やまだ誰も手をつけてなさそうな問題を解決する仕事ができれば最高だ。 つまり、そう、尊重されたい。自分のやれること、やりたいことを尊重されるようになりたい。自分がやった仕事には価値があると思われるのは嬉しいし、そのように(勤務先以外の)他人から認められれば面白い話も聞けるようになるかもしれない。尊重されるソフトウェアエンジニアになれれば楽しそうだ。 尊重されるソフトウェアエンジニアであれば、もしかしたら自分の仕事についてある程度の自由が効くかもしれない。突然わけのわからない政治でがんじがらめの炎上プロジェクトのPMをやってこい
60%の人間はプログラミングの素質がない
Coding Horror: Please Don't Learn to Code Please Understand Learning to Code Coding Horrorで有名なJeff Atwordが、ある州知事が今年の目標としてプログラミングを習得することを挙げていることに対し、そもそも税金を払う我々市民は、政治家にはプログラミング習得以上に重要な、政治家にしかできない問題の解決を望む、よってプログラミングを学ぶのをやめてくれという記事を書いた。これに対して、反論が多数上がっているが、Jeffも読んでいるある論文をあげて、この議論の参加するためには、必ずこの論文を知っておくべきであると書いた人がいる。この論文は有名で、非常に興味深いので、全プログラマーが読むべきである。 ふたこぶラクダという名前で知られている有名な論文がある。この論文では、60%の人間にプログラミングの素質が
langturn.com is coming soon
is a totally awesome idea still being worked on. Check back later.
プログラミング初心者のうちに身につけたい３つの習慣 | Social Change!
プログラミング技術さえ身に付けば、プログラマとして一人前と言えるでしょうか？ プログラミングを始めたばかりのうちは、プログラミング言語の習得や周辺の知識を得ることばかりに目がいきがちですが、それだけでは一流のプログラマになれません。（プログラミング言語を学びたいならこちら：写経で身につけるプログラミングの基本） プログラマとして成長するためには、プログラミング技術を学ぶだけではなく、良いソフトウェアを作るための良い習慣を身に付けることが大事になります。初心者のうちに良い習慣を身につけておけば、ただ知識を追い求めるのではなく地に足をつけた成長ができるはずです。 本記事では、私自身も先人たちから学んだプログラマが身につけたい３つの習慣について書いています。 自分で書いたすべてのコードを説明できるようになろう プログラミングは全て、明確な判断の結果です。if文を使うべきかどうか、どのAPIを使う
入社2週間で書類1枚書かずに大きな決裁！グリーのスピード感：Rails Hub情報局：エンジニアライフ
「オレ、入社2週間で大きな決裁を通しましたよ！ まだ試用期間中だったのに（笑）」。JRubyのコミッターで、Rubyコミュニティで広く知られた大場光一郎さんに久しぶりにお会いしたら、ちょっと興奮気味にこうおっしゃるのですよ。具体的な数字は書けませんが、確かに、ふつうの企業なら1週間や2週間で決まるような金額ではありません。まして入社2週間の試用期間中の社員の提案です。 大場さんは2011年12月に、日本で5本の指に入る大手SIerを退職し、ソーシャル・ネットワーキング・サービス「GREE」を運営するグリーに入社したというではありませんか。そして、あまりの2社のスピード感の違いに驚いているというのです。Developers Summit 2012（通称デブサミ）が終わった後の飲み会でお話を伺ったのですが、水を得た魚とはこのことかというほど楽しそうに、新しい仕事上のチャレンジについて話をされて
dankogaiさんへの返信 : 小野和俊のブログ
昨日、「メンテナビリティの高いソースコードを目指して」というエントリを書いたところ、dankogaiさんから、「コードも見せていないお前にコードを語る資格はない」と怒られてしまったので返信エントリ。 実はブログを初めて1,2年くらいの頃はコードを含むエントリをそこそこ書いてたのですが、プログラマーでない知人から「何の話か全然わからなかった」と言われ、またdankogaiさんも指摘している通り、「コードについて書く方がコードを書くより読まれる現実」があり、コードを含むエントリはJava Programming Tipsという別のブログに移した経緯があります。 ではどこに力を入れているかというと、私が一番力を入れいてるのはDataSpiderという商用ソフトウェアの設計と実装ですが、これはアプレッソの50人の社員を10年間支えてきてくれているソフトウェアなので「はい、どうぞ」とソースコードをお
なぜプログラマを難問奇問・一風変わったテストなどで雇ってはいけないのか？
By Iron Man Records 「なぜ我々はプログラマを難問・APIクイズ・不可解な演算・その他の面接トリックで雇わないのか？」というタイトルで「Ruby on Rails」「Basecamp」など、積極的にウェブ上の開発を行っている人々の間では一度は聞いたことがある小企業「37signals」が自身のブログ上でエントリーを出しており、その中身が非常に考えさせられる内容となっています。 Why we don't hire programmers based on puzzles, API quizzes, math riddles, or other parlor tricks - (37signals) http://37signals.com/svn/posts/3071-why-we-dont-hire-programmers-based-on-puzzles-api-qui
プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン
Sharing OptionsShare on Facebook, opens a new window
プログラマ35歳定年説、定年後の未来 - GoTheDistance
株式会社クラステクノロジー代表の四倉氏の連載コラム「第151回」が、とても興味深いのでご紹介します。 【第151回】35歳定年説の真実-株式会社クラステクノロジー 詳しい内容は上記コラムをご覧頂きたく。 プログラマ35歳定年説とは 上記の四倉氏によれば、プログラマ35歳定年説とは｢1Step,1Stepの生産性に比例するので、長い間労働すれば高いアウトプットが出せ収入が増える。体力が下り坂になってきて徹夜や残業ができなくなるのが、大体35歳前後。体力低下と共に収入も下り坂。それに限界を感じてIT業界去ってしまう｣ということのようです。これをプログラマと呼ぶのかとか、ステップ数(笑)という憤りもあるでしょうが、｢ステップ数と売上が比例するため、いっぱいコードを書けば収入が増える｣という理屈は腑に落ちました。是非の問題ではなく、確かにその理屈なら体力勝負という表現も理解できる。 そして、この理
いっしょに仕事をしたいプログラマ 5つの特徴 - たごもりすメモ
ちょっとこんなことを考えるきっかけがあったので、ざっと書き出してみた。Webに公開されている情報からあるプログラマについて見てみたとき、どういう人ならいっしょに働いてもいいかについて。 ここに書く内容はソースコードの品質以前の問題についてのみにしてある。だからこの特徴を満たしていればどうということに直接なるわけではない。ただ、欠けているところがあれば、少なくとも自分はその人といっしょに仕事をしたいとは思わないだろう。 なお自分は現勤務先の採用活動にはかかわっておらず、このエントリの内容は勤務先の採用基準とは全く無関係です。 学生さんなどの場合にはまた話が違うと思います。 あと割と自分のことは棚に上げてます。「お前これできてねえじゃん」という部分については都度ご指摘をいただけますと大変ありがたく思います……。 1. その人が書いたソースコードが公開されている 日本語で何を言われてもぶっちゃけ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch | Startup and Technology News
