僕はコードを読むのは得意な方だけど、それが過ぎてコードを書かなくてもシニアソフトウェア開発者になってしまった。実はコードをちゃんと読めるソフトウェア開発者って希少価値が高いのではないか、と思ったので自分がどんな感じでシニアになったのかをまとめてみた。似た様な人の参考になれば幸いだ。 同意。僕は未だ書く方はほとんど機会なく成果もないけど、コードを読み尽くして、負荷試験や本番で挙動を把握し続け、メトリクスでとことん確かめていった結果、Sr. Engineer になれた。 https://t.co/KXtMdEaRr8 — Ryosuke Iwanaga (@riywo) April 16, 2021 コードを書かなくてもシニアソフトウェア開発者になれた 僕は今 Amazon の Sr. Systems Development Engineer という職種で働いている。いわゆるソフトウェア開発職

mizchi @mizchi 「技術的には可能です」を正しく認識してもらうために、「他の開発すべて止めて数年間社運を掛けた上で成功率が1割ぐらいです」と伝えるようにしてる

LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog (2月5日 16:30追記) SNS等で多くのご指摘をいただき、再度掲載していたコードや表現について社内で議論いたしました。それを踏まえて以下の通り、補足および訂正させていただきます。 エラトステネスのふるいの実装方法については、高速化のための実装ではなく、アルゴリズムなどの勉強をしっかり行ってきたか、ということを示すための1例として紹介しましたが、あたかも高速化を目指したコードとしての例示となり、誤解を招く表現でした。上記の意図を明確にするために、本文中に高速化するための実装ではないことを明記しました。 また、"個性がない"という表現も、上記と同様に"アルゴリズムなどの勉強をしっかり行ってきたという実績や経験がコードから判断

前エントリが思いの他読んで貰えて「まぁ、こんなものか」と思っていた20数年の枯れたプログラマ人生に幾許かの水を挿して貰った気分になった。ありがとう。 続きを書いて欲しいという声もちらほら頂いたので調子にのって書いてみた。 ↓前エントリ https://anond.hatelabo.jp/20210130001953 年収が高いのでは？という声をそれなりに頂いた。 最初に所属した会社が倒産をして先輩の起業に付いていったのだが、その会社が完全歩合制の会社だった為、多重派遣としては良い方の収入だったように思う。 例えば、月単価から2割が会社のお金、8割が自分の取り分というようなシステムである。勿論、仕事が無い時は収入はゼロ。 前エントリでも書いたが、個人でフリーでいるより単価交渉をしやすく、将来貰えるかは解らないが年金も2階建てに出来る。 現状ではある程度キャリアのある人達にとっては悪くないシス

概要 職業ソフトウェアエンジニアを目指す方々にオススメしたい書籍トップ10です 以下の観点から選定しました 10年後でも変わらない、流行にとらわれず長く役に立つ、ソフトウェアエンジニアリングにおいて普遍的な知識 特定のプログラミング言語やプラットフォームやツールに精通するのではなく、現代のソフトウェア開発の哲学・文化の全体像が把握できることを優先 200～300ページくらいで初心者でも読破できる 400～500ページくらいの本もあるが、それらは辞書的に使うのがいい あえて10冊に絞り込んだので、ここに含められなかった書籍も当然あります CI/CDやDevOpsに関する本も入れたかった… デザインパターンに関する本も入れたかった… DDDやClean Architectureなどシステム設計に関する本は意図的に入れていない 真・プログラミングスクールに通うくらいならこの本を読め10選を書きま

この記事は、 Rails を主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ についてのアンサー記事です。 うなすけ君が Ruby on Rails で育ってきたように、僕も JavaScript とともに育ってきたという自覚があります。なので、これについて書くことは、ポジショントークは避けられない、という感覚があります。 冷静に比較しようとも思いましたが、やっぱり開き直って思いっきりポジショントークをすることにしました。そっちのほうが面白いと思うので。 自分の基本的な主張は、こちらの記事にあるとおりです。 Frontend Study #1: 基調講演 - Frontend 領域を再定義する 自分と Ruby on Rails 僕は、キャリアとしては Rails の会社で JavaScript を書いてきたことが多かったです。学生の頃は socket.io

スマートキャンプで業務委託でエンジニアをしている佐藤です。BOXILの開発を1年3ヶ月前から、沖縄からフルリモートでやっています。 皆さんは、毎日楽しくお仕事できていますか？　エンジニアという職業は労働時間やストレスが多く、IT業界は他の業界と比べて精神疾患にかかりやすいと言われています。 私はもともと自己否定ばかりしてしまう思考の癖があることに加えて、7年前に起業に失敗してメンタルを壊してしまったことをいまだに引きずっていて、日々悩みながら生活をしています。 スマートキャンプは、過労とは無縁で、メンバー間のサポートもよく、これ以上ないくらい私に合った職場です。それでも自分の心の問題で不安になったり、絶望感に襲われたりすることがあります。今回はそうなるたびに書き綴ったメモを、開発中にネガティブな気持ちにならないための技術としてまとめようと思います。 メンタルが強くないエンジニアはこんな気持

2020.08.27 スキル 2020年４月21日、NTT東日本と独立行政法人情報処理推進機構（以下、IPA）は、新型コロナウイルスの流行によって在宅勤務を強いられている人々を支援するため、無償かつユーザー登録不要で利用できるシンクライアント型VPN『シン・テレワークシステム』の提供を開始した。 このシステムを構想からわずか２週間あまりでリリースに漕ぎ着けた中心人物こそ、今回紹介する登大遊さんだ。 登　大遊（のぼり・だいゆう）さん 1984年兵庫県生まれ。2003年に筑波大学に入学。同年、IPA（独立行政法人情報処理推進機構）の「未踏ソフトウェア創造事業 未踏ユース部門」に採択、開発した『SoftEther』で天才プログラマー／スーパークリエータ認定を受ける。17年、筑波大学大学院システム情報工学研究科博士後期課程修了。博士 (工学)。現在、IPAサイバー技術研究室長のほか、ソフトイーサ株

こんにちは！ リクルートテクノロジーズでセキュリティエンジニアとして活動している、藤原 巧です。 毎年恒例となっており、大きな反響をいただいている、エンジニアコースの新人研修の内容を紹介させていただきます。 研修の概要 リクルートテクノロジーズでは、新卒採用の新人向けに３ヶ月間の技術研修を行っています。この技術研修では大きく分けて２つのコースが設けられています。 1. プログラミングやWebサービスの構造の基礎を体系的に学び、その後一人につき、ひとつのスマホサイトを企画からリリースまで行うコース 2. 一定以上のプログラミングスキルと開発系経験がある新人に向けた、実際の開発で必要となる様々な技術要素をより深く学び、その後実際のサービスでチーム開発にてOJTを行うコース 今回公開するのは 2. で使用した資料です。 この技術研修は、そのほとんどの部分を内製で実施しています。 この研修の最大の

はじめに Github Help Wantedでissueを選ぶ OSSのコントリビュート方法を確認する 実装 既存コードの動作確認 機能実装 プルリクを出す マージされる 最後に はじめに こんにちは。広告技術部のjohnmanjiroです。普段は広告配信のAPIや管理画面を作っています。 今回は最近自分が始めたOSS活動のやり方について紹介しようと思います。 issueを見つけたその日にプルリクを出し、約１週間後にマージされました。 「OSS活動始めたいけど、別に普段使ってる中でバグを見つけたりもしてないし、貢献したい明確なOSSもない、どうしよう🤔」そんなOSS活動未経験者の参考になれば幸いです。 ちなみに自分自身、活動を始めたばかりのペーペーです。 Github Help Wantedでissueを選ぶ OSS活動を始めるにあたって、まずは貢献するissueを選びましょう。iss

いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が（たぶん） IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・　良い仕様書がもたらす 5 つの効果 ・　仕様書の重要性が増していく 2 つの理由 ・　仕様書に含めたい 14 の項目・実戦編 ・　仕様書作成時に心に留めたい 3 つのこと ・　具体的な仕様書サンプル（

チームでどうやって活躍するか、まだイメージがついてない、振られた仕事をやっているだけで、仕事をしている間は忙しいけど、確認待ちになるとすぐ暇になってしまう、というメンバーの悩みを聞いていた。 巨大なチーム、巨大なプロダクトだと、すぐに全容を把握するのは難しい。その中で、この範囲なら触れています、任せてください、という庭を作るとよいのでは、という話をした。 思いつきで話したわりには意外といいことを言ってるなと思ったので掘り下げて書いてみます。 庭とは 現代では、庭のある家に住んでる人は少ないかもしれない。うちは実家が田舎だったので庭があって、ボールを蹴って回ったり、石をめくってアリを観察したり、隣の家の庭との境界もゆるくて、冒険と言って隣の家の庭で遊んだりしていた。 大人になってからの庭というと、池袋で遊んでた人が「池袋は俺の庭」と言ったり、JR新宿駅の東口を出たら椎名林檎の庭があることが知

こんにちは。mattn（@mattn_jp）です。一部の方はご存じかもしれませんが、僕は普段あまり皆さんの前に登場することはありません。どちらかというとお堅いSI業で仕事をしています。社会人になってから今まで一度も、Web業界と呼ばれるB2C（Business to Customer）な職種に転職したこともありません。 ですが、今ではOSS（オープンソースソフトウェア）を通して、多くのエンジニアと友達になり、カンファレンス等で何度かお話しする機会をいただくまでになりました。この記事では、OSSに縁遠いはずの僕が、いかにしてOSSと出会い、そして多くの方たちと知り合うチャンスを得たのかをご紹介したいと思います。 オープンソースとの出会いはVim 日本のVimコミュニティを作る VimConfで作者Bram Moolenaarと握手 Vimから得られたチャンスや出会い GoコミュニティからGo

0 0 719 0 この 4 年間、Dropbox では、デスクトップ クライアントの同期エンジンを白紙の状態から再構築しようと懸命に取り組んできました。同期エンジンは、デスクトップ パソコン上の Dropbox フォルダの陰に隠れた魔法です。これは、Dropbox で最も長く使われているコード部分であり、最も重要なコード部分の 1 つでもあります。今回、新しい同期エンジン（コードネーム「Nucleus」）をすべての Dropbox ユーザー向けにリリースさせていただくことを、ここに発表いたします。 同期エンジンの書き換えは本当に大変な作業で、多くの環境でマイナスともなりうる構想であったことに鑑みると、手放しで祝う気持ちにはなれません。結果的には Dropbox にとって素晴らしいアイデアであったわけですが、それは、私たちがこのプロセスにどのように取り組むべきかを熟考したからこそ、たどり着

by Christiaan Colen Windowsで現在起動しているプログラムやCPUの使用状況などを確かめたい時に、真っ先に思いつくのが「タスクマネージャーを使う」ことです。そのタスクマネージャーを約25年前に開発したMicrosoftの元エンジニアであるデビッド・プラマー氏が、直々に使い方や知られざる機能を説明しています。 I wrote Task Manager and I just remembered something... : techsupport https://old.reddit.com/r/techsupport/comments/gqb915/i_wrote_task_manager_and_i_just_remembered/ プラマー氏は1993年からMicrosoftに勤務していたそうで、1994年頃、タスクマネージャーのプログラムである「TaskMgr

こんにちは。エンジニア組織開発責任者の id:kfly8 です。 はじめに 最近、COVID-19の影響で、在宅で勤務している方が増えているかと思います。モバイルファクトリーでは2月中旬から原則在宅勤務になり、家の開発環境をこの機に整えている声などを聞きます。 そこで、今回は弊社のメンバーに在宅の開発環境のこだわりなどを聞いてみました*1 尚、この記事はGunosyさんのこの記事にインスパイアされた記事です。 tech.gunosy.io 1人目 1人目は、デザイナーの@momoyagiです。 普段はMBP本体＋ディスプレイ2枚で開発していますが、自宅環境はMBP+ディスプレイ＋気分転換用にipadになっています。デザイナー職のため、会社支給のwacom ペンタブレットを持ち帰ってます。デバイスが少し多いので配線管理がつらい。 在宅開発環境の良い点 周りがうるさいと集中できないので、一人の

そろそろWebエンジニア3年目の折り返しになるので、Webエンジニアとして働く中でこれまで読んできた情報たちをまとめようと思い立ちました。 エンジニア3年目の今だからこそまとめられる情報として、「エンジニア1年目の１年間で読んでおきたかったな〜。」という本と記事をまとめておきます。 まとめ始めたら楽しくなってしまい、情報量が多くなってしまった...。全部手に取るのは不可能だと思うので、サーっと目を通して見て興味が湧いた本や情報を手にとっていただけると良いかと。 これからWebエンジニアになる人、Webエンジニア1年目の人の参考になれば幸いです。 これは何？ Webエンジニア1年目が仕事を進める上で絶対に求められるであろう知識を、技術力・Web知識・仕事の進め方・キャリアの観点からまとめました。 「これだけ読んでおけば絶対大丈夫！！」という安易なものではありませんが、「どんな知識を学べばいい

こんにちは。谷口です。 先日、オライリー社から『レガシーコードからの脱却――ソフトウェアの寿命を延ばし価値を高める9つのプラクティス』が発売されましたね。 弊社でもすぐ購入し、読みまくり、「これはリーダブルコードのように次世代のエンジニアのバイブルになる予感…」と言っているエンジニアもいたので、今回は本書の概要紹介と感想について書きたいと思います。 私の本書はすでに画像の通りふせん貼りすぎ下線ひきすぎ読みすぎでボロボロです。 レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス 作者:David Scott Bernstein発売日: 2019/09/19メディア: 単行本（ソフトカバー） 概要について 本書はどんな内容の書籍なのか、まずオライリー社公式サイトにはこう書かれています。 本書では、ソフトウェア開発において、初めからレガシーコードを作りださないた