Hamee様 開発合宿 2021年（前半戦）の資料です。 # 参考リンク - https://speakerdeck.com/soudai/engineer-life-hack - https://www.shinryo.com/special/contents01_3.html - htt…
Hamee様 開発合宿 2021年（前半戦）の資料です。 # 参考リンク - https://speakerdeck.com/soudai/engineer-life-hack - https://www.shinryo.com/special/contents01_3.html - htt…
10xプログラマー、それは「一流のプログラマーは、普通のプログラマーの10倍の生産性を持つ」という、ソフトウェアエンジニアの世界における神話です。 「多くの人に使われるものを創れるようになりたい。」 そんな想いから、これまでGunosy、Mercari、LINEなどでエンジニアとして働いてきましたが、最近、自分の進むべき道を見つめ直す機会があり、「良いエンジニアとは何か」について考える時間がありました。 そんな中で、Redisの開発者である Salvatore Sanfilippo が書いた「The mythical 10x progrmmer」という記事に出会い、その内容が非常に参考になったため、翻訳させてほしいと本人に申し出たところ、「Sure!」と快諾していただけたので、僭越ながらここで共有させていただきます。 Salvatore Sanfilippo（@antirez） - htt
5年後、10年後の自分を想像してそれを実現するために必要なことをトップダウンして、、、っていう自己実現の方法論みたいなものがあるけど、僕にはそんなことできません。 10年前に自分がフリーランスになってると思っていなかったし、主夫とか言っちゃってるとも思っていなかったもの。せいぜい1,2年先くらいまでを想像してその時はこうしたいな、こうなっていたいな、を考えるのが精一杯でその先のことはさっぱりわかりません。 なのでこのエントリーは年始くらいから考えていることを「2年後くらいまではこんな感じで生きていこう」という軸で整理したものです。 戦略1 妻に働いてもらおう 僕は主夫なので普段は家事をしながらパートでエンジニアをしています。つまり妻はフルタイムで働いているということです。とても頑張ってくれています。妻が働いてくれている限り飢えてしまうことはありません。なので僕にとっての最も堅実な生存戦略は
はじめに プログラムを書いたことがある人なら、誰しも「ハマる」という状況に陥ったことがあると思います。 ハマるとは、一般的には何かから抜け出せなくなってしまうことを意味しますが、システム開発の世界では、ある課題やエラーなどに対して、解決の見込みが見えないまま多くの時間をかけてしまうことを意味します。 今回は、ハマってしまったときに、いかに問題を解決し、ハマった状態から脱却するかについて書きたいと思います。 目次 問題解決における6つの基本 最初に、問題解決の基本的な考え方を書いておきます。当たり前のことばかりだと感じるかもしれませんが、この基本が完璧にできていれば、ハマることはそもそも稀だと思っています。 もし、普段の実装の中で「同じことで丸1日悩んでいるけど解決の手立てがない」「これにさえ気付いていればもっとはやくできた」「単純なミスだった」といったことに時間を溶かしているのであれば、問
目次 はじめに 情報不安について 人の話を聞くこと 寝てから考えよう わ・ざ・と、ゆ・っ・く・り・、や・っ・て・み・よ・う ロビンソン式悩み解決法 驚き、最小の法則 むしょうに腹が立つあいつのこと あなたは、そのままでいいんです はじめからやり直したい症候群 人から信頼されるためにはどうしたらよいか トラブルがチャンス あなたはひとりではありません あなたのための聖書の言葉 ぜひ、感想をお送りください リンク集 更新履歴 はじめに 私はプログラマです。 プログラムを書いて生活の糧を得ています。 プログラマというのは精神的にも肉体的にも過酷な仕事だと思われています。 夜遅くまでディスプレイに向かい、 キーボードを叩き、ジャンクフードを食べながらバグをとる…そんな職業だと思われています。 確かにそういうところもありますが、プログラマも人間です。 不健康な生活を長いこと続けることはできません。
大枠のアイデアを書き出す。とりあえず動かす。期待どおりに動かない。考える。書く。動く。次を書く。 書いては消し、書いては消し。 この、木彫り師が木を削りながら中にある観音様を浮き上がらせる、というような行為が好きだ。 コードはコンピューターに対する命令書にしか過ぎない。エレガントな書き方は存在する。メンテのしやすい書き方というのも存在する。その一つ上のレベルに真にクリエイティブな一部の人だけが生み出せるオリジナリティと実用性を兼ね備えたコードというのもある。 自分は少なくともこの最後の部類の人間ではない。これらのまさに「アーティスト」とも呼べるこの人達はまた違う人種だ。自分はただのいちプログラマーに過ぎない。 ただひとつだけ言えるのは、コードは命令書であるということは我々が書いるものは「文章」であるということで、そして文章とは書かなければ決して上達しないということだ。 書いては消し、書いて
「HRTの原則」という言葉をご存知だろうか。 これは書籍 Team Geek ―Googleのギークたちはいかにしてチームを作るのか で紹介されている言葉であり、本書ではほぼ一冊すべてをかけてこのHRTの原則とその実践方法とを様々な角度から紹介している。 1. 謙虚(Humility) 2. 尊敬(Respect) 3. 信頼(Trust) の3つの価値が大切にされており、エンジニアとしてもチームや組織、顧客との対話においてこれらの価値を重んじていくことが成功につながる、というものである。 あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ Team Geek p.15 プログラマとして成功するには、最新の言語を覚えたり高速なコードを書いたりするだけではいけない。プログラマは常にチームで仕事をする。君が思っている以上に、チームは個人の生産性や幸福に直接影響するのである。 Team
プログラミングは自由ではない ここ最近、 「プログラミングを勉強して自由な働き方を手に入れよう！」 みたいな趣旨の記事や広告を良く見かける。 大方プログラミング教育系の事業が増えてきているからだと思う。 それに対して非常に違和感を感じる。 というのも、自分の中でプログラミングは楽しいものではあっても、 決して自由と近しいものではないと思うからだ。 自由に一番近い職業と言われると、確かにそうかもしれないが、 それでも他の職業と同様にエンジニアは不自由だと思う。 （とはいえ新卒なのでなんとも言えない） ここ最近プログラミングが楽しくないと感じる機会が少なからずあるので、 その理由と合わせて違和感の原因を整理しておく。 なので、この記事の正確な主旨は、「僕が」プログラミングを不自由に感じる場面とその理由、だ。 （下記は自分の技術力のなさを棚上げしている。このタイミングでまさかりが飛んできたら死ぬ
前提 思想：自由にやりたい 場所：東京 時代：2013～2014現在 職種：プログラマ 経験値：会社人ゲーム開発10年、フリーランスWeb開発1年 場所と時代は大きなファクターだと思う。 この前提から剥離している環境にいる人が、もし仮にこの記事を見て参考にしようとしても、あまり参考にならないかもしれない。 #108127768 / gettyimages.com 活動場所 自宅 コワーキングスペース (主に茅場町のCo-Edoを利用) カフェ ファミレス (カロリー注意) 仕事の記録 請けた仕事 Co-Edoの田中さんに仕事を貰いました。 Co-Edoでたまたま会ったFさんという人から仕事を貰いました。 Fさんの知り合いのNさんから仕事を貰いました。 興味のあった仕事をネットで見つけて応募して週2程度の定職を得ました。 元いた会社の繋がりのHさんから仕事を貰いました。 Co-Edoでたまた
プログラマ同士で話している時には当たり前の事だけど、非プログラマと話すと意外と共有されてない事に、これがある。 ここ最近、プログラマでない人とソフトウェアを作る、という話が三回あった。 一度はその人の為にツールを作る、という奴。もう一つは私のアプリのデザインを一部変更する、という話で、けれどデザイナがソフトウェアのデザインやった事無い、という奴。もう一つはアプリの素人だけど、アプリのアイデアとかはあるからアプリが書けるようになりたい、という人に話をする、という奴。 ちゃんと作ったのは最初のツールだけで、残り二つは辞退したけれど、どのケースでもソフトウェアを作るというのは結構難しい、という事があまり共有されていない。 私は結構ソフトウェアを作るのは難しいから、XXXみたいな事が必要だ、というような提案をする。 例えば、リモートの開発はかなり困難で、メールのみでソフトウェアの振る舞いの話をしあ
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2002/2/13 「うちの開発チームのどこが悪いのか分からない。」とCEOは心の中でつぶやく。「プロジェクトを始めたころには何もかもうまく行っていたんだ。最初の2 週間チームは馬車馬のように働いて、ちゃんと動くプロトを作ったんだ。ところがその後は進み具合が這うように遅くなった。単に連中が怠けてるだけということかもしれん。」彼はキャラウェイ製のチタンドライバを選び、キャディに冷たいレモネードを取りに行かせる。「2、3人首を切れば、連中の尻にも火が付くだろう！」 その間、もちろん開発チームの方は何が悪いのか全然見当も付かない。実際何もまずいことはないのだ。彼らはスケジュール通りに進んでいる。 こんなことがあなたの身に起こらないようにすることだ！あなたの人生を百万倍も楽にしてくれる、こういう非技術系マネジ
とりあえずプロデューサが作りたいゲームを語る。酒の席だったりする。 それを何となくプランナに伝えて営業用資料を作る。この過程で何度も何度もあーでもないこーいうつもりでもないと言いながらもできあがる資料は抽象的でなんとなくそれっぽい絵とどこかで見たようなシステムに独自っぽい名前を付けてるだけのすっからかんなペラい物になる。本音を言うと「ポケモンを作る」と言われる方が楽だ。「作りたい本人が説明できない、今までにないような独自のゲーム」を作る事になるとバグとか糞とか以前に完成しない。 そのペラい資料をもって営業に行くがすんなりは決まらない。この間はいい感じだねって言ってたじゃんって展開も。そのまま下にも同じ事を言われる。 決まらないがとりあえず作り始めてとデザイナとプログラマに投げられる。とりあえずジャンル名くらいしか決まっていないので色々聞きながら作ってみる。もちろん面白いとかつまらない以前の
自分はソフトウェアエンジニアとして毎日の糧を得ている。今のところはサラリーマンエンジニア以外の存在になる予定はない、が、とはいえ唯々諾々とつまんない仕事ばっかりやる毎日はできればごめんだと思っている。コードを書くのは楽しいからコードを書ける仕事をしたいし、特に面白い問題やまだ誰も手をつけてなさそうな問題を解決する仕事ができれば最高だ。 つまり、そう、尊重されたい。自分のやれること、やりたいことを尊重されるようになりたい。自分がやった仕事には価値があると思われるのは嬉しいし、そのように(勤務先以外の)他人から認められれば面白い話も聞けるようになるかもしれない。尊重されるソフトウェアエンジニアになれれば楽しそうだ。 尊重されるソフトウェアエンジニアであれば、もしかしたら自分の仕事についてある程度の自由が効くかもしれない。突然わけのわからない政治でがんじがらめの炎上プロジェクトのPMをやってこい
私がよく通る道に古いオフィスビルがあり、そこの１階にＩＴの会社が入っている。看板に出ている社名と、窓からちょっと見える社内の雰囲気からして、古いタイプのシステム開発会社のようだ。その会社ではスーツ着用が必須のようで、全員スーツを着てＰＣに向かい、開発している。座席のレイアウトも昔ながらの「島型」で、向かいの人の顔が自分の視界に入るやつだ。私はこの会社の横を通るたびに、「ここの社員はかわいそうだなあ」と思う。 座席のレイアウトは、場所や予算の制約もあるだろうから、まあ目をつぶるとしよう。しかし、開発をするエンジニアにスーツを着せても、まるで意味がない。営業やサポートにも行くエンジニアや、客先常駐するエンジニアならまだわかるが、自社で開発しているエンジニアにスーツを着せても、仕事のジャマになるだけだ。 こういう古いタイプの会社は、経営者がおそらく「まじめに働く」ことを重視しているのだろう。みん
「この辺を勉強してどういう良いことがあったか教えて欲しい。」というコメントがついてた。 良いこととして、一番は、まあ勉強するのが楽しくなった、ということなのだけど、それは循環してるので置いておいて。 実務的に一番いいのは、プログラムを組むのが楽になったということ。 とくに、本質的な間違いが少なくなっていくので、後戻りが減るというのが楽。組んでみたけど動かない、途中でそれ以上組めなくなる、というのが少ない。まあ、ミスはあるので、そこの修正はするけど。 あと、できないことができないとわかりやすい。そのデータの持ち方でそのデータ数でその処理ではその精度の要求は満たせない、ということが原理的に判断しやすくなる。なので、むだな努力をしない。そして、どの条件を緩和すれば要求が満たせるかにも気づきやすい。 初見のライブラリや言語、ツールの理解が早くなる、とかも。 もちろん、前のエントリにも書いたように「
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 2019/06/11追記: これは2012年の投稿です。なぜかはてなブックマークで拡散されていますが、内容は時代にそぐわなくなったものもあるのでご注意ください。 これ知らないプログラマって損してんなって思う汎用的なツールのコメントに寄せられたツールを分類分けしてみました。 解説は、ほぼコメントに寄せられた内容のコピペです。 URLのみの記述は公式サイト(か、ほぼ公式サイトと化しているサイト) 公式サイトとは別に、ページタイトルだけでツールを説明しきっているページへのリンクも付けておきました。類似ページが複数ある場合は、はてブのブックマー
先週おこなわれたTEDxTokyoで改めて考えさせられた内容がありました。 長時間労働が常習化している社員・経営者 これから家庭を持つ人、持った人 これから（現在）出産や育児に携わる人 のような人に特に見て頂きたいと思います。 小室さんは昔からお美しい…。動画は中盤から本質的な話になるので、だまされたと思って全部見てください！ 日本の労働 近年の日本人の労働の実体は 平均残業時間60時間/月 労働生産性は先進国の中で最下位 とのことである。国土も、人口も、資源も、少ないと言われる国なのに、そのうえ生産性が低いときたら…。 だが一方で… 「30%の残業が減っても、売上の上がる企業がある」 これは、私の経験からも事実であると感じます。 私は過去に経営に携わった会社では、月の残業時間が20時間を超えると人事評価を落とす制度にしたことがあります。 もちろん、これが平社員であれば、マネージャーの評価
ある程度の年齢を迎えたプログラマが抱える悩み ある程度の年齢を迎えたプログラマが抱える悩みに、「若手のプログラマと比べて、どうやって価値を出していくか」という問題があります。これは言い換えれば「同じような生産性であれば、相対的に給料の低い若手のプログラマに置き換えられてしまうのではないか」という悩みです。 この問題のひとつの解決策は、プログラマ以外の仕事のポジション（たとえば管理職など）に移ることですが、他のポジションには向いていない、まだまだ現役でプログラマをやりたいという場合にどんな戦略があるか考えてみました。なお、後述するように、以下に挙げた戦略は相反するものではなく、組み合わせが可能です。 エキスパート戦略 この分野ではトップクラス、というレベルの専門性を身につけ、その分野に特化してキャリアを築くという戦略です。たとえば、ネットワークやセキュリティといった分野で一流と認められる専門
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く