41歳のエンジニア、マネージャーからICへのキャリアチェンジ | おそらくはそれさえも平凡な日々
最初にお断りしておくと、このエントリは驚くほど僕固有の私的な話に終止するので、他の人の参考にはならないでしょう。 ICというのはIndividual Contributorの略で、最近だとHashiCorp創業者のあのMitchell Hashimoto氏が、HashiCorp社内でICになるというのも話題になりました。日本でも、こにふぁーさんがそういう動きをしていたりして、ちょいちょい聞くようになってきた印象です。 今回の僕の転職は、言ってしまえば、自分が培ってきたソフトウェアエンジニアとしてのスキルを活かして世界の舞台で戦いたいという気持ちを抑えきれなかった、という幼稚な理由です。自分が求めているものがLaunchableにはあるように感じて入社しました。 振り返ってみると、最近の自分の転職における決め手は「自分を一番必要としてくれるところ」という側面が強かったと感じています。その結果
Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々
Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
