はてなブックマーク

私はエンジニアになってから何度も「マネージャー向きですね」と言われてきた。 理由もなんとなく分かる。問題を整理するのが好きだし、複雑な状況を構造化するのも好きだし、人の認識を揃えるのも好きだからだ。 技術的な課題が絡み合っている状況を見ると、まずは図にしたり論点を書き出したりしたくなる。 そういう振る舞いをすると、「それってマネージャーの仕事ですよね」と言われてきたし、実際にマネージャーになってみたこともあった。 そして時には、もっと直接的に「技術の人じゃないね」と言われたこともあった。 当時の私は、その言葉を半分受け入れていた。  でもずっと違和感も持っていた。 私はマネージャーになりたいわけではなかった 誤解のないように言うと、マネージャーという仕事を否定したいわけではない。実際に優れたマネージャーにもたくさん出会ってきた。ただ、自分がやりたいこととは少し違った。 私は人事評価に強い興

そういうときがよくあります。 マネジメントを仕事にしたのは今の会社が初めてだけど、きっとこれから先も会社に所属している限りは、なくならない気持ちなんだと思います。 だから、そんなときに振り返れるようなものを残しておきます。 ...時が経つのは早いもので、コードレビューを受けるのがつらかったわたしも、気がついたらチームリーダーになっていました。 今では、当時自分自身が書いた記事を読んで、レビュアーとして考える日々を送っています。 煽りタイトルで申し訳ないのですが、マネジメントを始めてまだ1ヶ月しか経っていません。 けれど、なんとなく、 コードを書く時間が減ってしまったことに対する不安 自分は何も生産していないのではないか 今後のキャリアどうしよう？ 職場の人間関係に対して常にアンテナを張っていなければいけない気がする不安 Slackから目が離せない あそこで話している人たち、何を話しているの

もう3ヶ月くらい前になるのですが、Dockerを雰囲気でやっていた自分が、ローカル上でそんなことをすることになりました。 当時の自分がこのタイトルを見ても「ハァ？？？」みたいな気持ちになったと思います。。。 dockerを理解するために読んだもの、読みたかったもの 最初の時点で、インフラに詳しいメンバーから 「たぶん network を設定するんだと思いますよー」 と言われていたんですが、とにかく自分はDockerについての知識が浅かったので、まずは docker-compose.yml が読めるようになるまで勉強してみました。 読んだもの 読みたかったもの いろいろ勉強して解決した後に読んだけど、これを先に読みたかったw booth.pm booth.pm docker-compose のnetworkについて DockerとComposeの基本的なところを勉強したら、インフラに詳しいメ

先駆者であるひよこ大佐（@hiyoko_taisa）さまに敬意と感謝をこめて。 こんばんは。めるです。表題の通りです。 年末の時点で次に行く（はずだった）会社が決まりまして、1月末で退職をしていました。 しかし、最終出社1日を残したあたりで状況が一転、内定を辞退して転職活動を再開することになりました。 内定を辞退した理由については、直接聞いてもらうか、時期でお察しください。。 有給を使いきっていたのもあり、もともとバッファで2週間だけ無職になることにしていましたが、それにしても早く職に就かねばならない、ということでTwitterで求職してみることにしました。 諸事情により、ゆる募。 Rails歴1年2ヶ月、PHP歴1年、フロントエンド歴3年程度のエンジニアを雇ってもいいよ、というところ。 その他の経歴等につきましては、TwitterプロフィールのURLをご参照ください。— める＠3/1から

Rubyを使っている人が調べ物をすると必ず出会うであろう、伊藤淳一（@jnchito ）さんの著書「プロを目指す人のためのRuby入門」出版イベントに行ってきました。 techplay.jp 著書はこちら ruby-book.jnito.com 動機は単純で、物理の伊藤さんがひと目見たかったからです。 自分は伊藤さんの記事と、その視点がとても好きで、そこには以下のような理由があります。 文系出身エンジニアだから（自分も文系出身なので） 元バンドマンだから（自分も音楽漬けだったことがあるので） フルリモートだから（旦那がフルリモートなので） 読む人、相手の気持ちを考えているから そこに裏付けられた分かりやすさがあるから などなど。 今日の話で出ていたものもありますが、過去の記事でも取り上げられていたことがあります。 ↓文系エンジニアのくだり↓ blog.jnito.com ↓読む人の気持ちを

Ruby3年目にして初めての RubyKaigi に行ってきました。とても楽しかったので、来年も身軽だったら参加したいと思いました。 キーノートのレポートは追って会社ブログにあげる予定なので、ここではセッション以外の話を箇条書きしていきます。 知見 朝早めに行って公式ノベルティをもらわないとTシャツのサイズがなくなるらしい スポンサーのノベルティも早めに回らないとなくなる 荷物は少なめがよい 飲み会が川で行われるらしい カラオケではジャンル別に部屋ができるらしい partyをしっかりチェックして、ちゃんと夜の予定を定めるべし 前夜祭の船とコード懇親会、面白そうだったけど埋まっちゃってた 飛行機のチェックインは早すぎるくらいがちょうど良い 行きの飛行機がかなりギリギリになってしまった よかったこと エモリハウスに突撃した エモリハウス ぼっちにならない 一方で団体行動もきつくない 17人もい

今日会社で「なんかいい本ないですか？」と聞かれて、オススメ本リストを作りました。 前提としては Rails × Vue をメインに開発している会社なので、他のバックエンド・フロントエンドの情報はない感じです。。 オススメ本って人によって違うので、幅広いジャンルを心がけました。 未読のものもあるのでなんとも言えませんが😅、せっかくなので、ここに残しておこうと思います。 反省としては、Railsに関する本、Vanilla.jsに関する本、データベースに関する本、インフラに関する中級者以上向けの本を知らないんだなあ、わたし。と思いました。 特にDBとインフラは、もうちょっとがんばらねば。 あとから思い出したら黙って追加してるかもです。 Web全般 Webを支える技術 Real World HTTP ハイパフォーマンス ブラウザネットワーキング テスト駆動開発 体系的に学ぶ 安全なWebアプリケ

9月まで開発を離れてマネージャーをしていましたが、先日最終出社を終え、10月1日よりWebエンジニアとして新天地で働く予定です。 マネージャーをやってみたことに対して後悔はしていません。 どんなマネージャーかと言われると言語化が難しいのですが、ピープルマネジメントがメインで、プロジェクトマネジメントのサポートとプロダクトマネジメントのサポートもしていたのかなたぶん、という感じです。後半はめっちゃ採用してました。 前職で過ごした時間は本当にあっという間で、振り返ってみると在籍期間全体で見ても、あまりコードは書いてなかったなあと思います。 ですが、急成長している会社で経営層とコミュニケーションをとることができ、とても信頼していただけたことや、エンジニアだけではなく多くの素晴らしいメンバーと仕事ができたことなど、貴重な経験がたくさんありました。 当時はとにかく「人」について考えることが多かったな

私はエンジニアになってから何度も「マネージャー向きですね」と言われてきた。 理由もなんとなく分かる。問題を整理するのが好きだし、複雑な状況を構造化するのも好きだし、人の認識を揃えるのも好きだからだ。 技術的な課題が絡み合っている状況を見ると、まずは図にしたり論点を書き出したりしたくなる。 そういう振る舞いをすると、「それってマネージャーの仕事ですよね」と言われてきたし、実際にマネージャーになってみたこともあった。 そして時には、もっと直接的に「技術の人じゃないね」と言われたこともあった。 当時の私は、その言葉を半分受け入れていた。  でもずっと違和感も持っていた。 私はマネージャーになりたいわけではなかった 誤解のないように言うと、マネージャーという仕事を否定したいわけではない。実際に優れたマネージャーにもたくさん出会ってきた。ただ、自分がやりたいこととは少し違った。 私は人事評価に強い興

自分の傾向として写経ばっかりしがちなので、たまには自分で考えて作ってみようと思って作りました。 作ったものはこちら。 https://c5meg1012.github.io/vue-flag/ ↓リポジトリ https://github.com/c5meg1012/vue-flag JavaScriptのフレームワークの話題でよく出てくる、 componentをどう切るかが難しい データをどう持つかが難しい どこまで大きくなったらVuex（Redux）を入れれば良いのかが難しい という感覚を、だいぶ理解できるようになったと共に、そのあたりの甘さが思いっきり出た感じになりました。。 Vuexを入れればApp.vueはほぼ表示に専念できるのかも、と思ったり。 あと、この手のJavaScriptはどうやってテストを書くのだろう、とも思ったり。 そもそも言語問わずテストの書き方自体をあまり知らない