HTTP API の設計方向
見てみると、たしかに Get 系の API だとしても POST を利用しているし、API の URL 設計に get_shared_link_file のようによく言われる REST っぽい設計は使っていなかった。 この方針は同意だ。自分は結構前に REST っぽい API を捨てることにした。だからといって REST API がダメだとかは思っていない。 一般ユーザが使う場合の API は REST API であるほうが慣れ親しんでいる場合が多いからだ。 AWS で利用されている HTTP API 仕様AWS の DynamoDB の Erlang/OTP ドライバーを書いているときに気づいたのだが、AWS の一部のサービスはかなり独特な API の仕様になっている。
フルリモートワークを諦めた
正社員のフルリモートワーク採用を目標としていたが諦めた。 現在、自社では週１出社それ以外は自宅からのリモートワーク社員がいる。一緒に働いて感じたことはフルリモートワークの場合はうまくやっていくことはかなり難しいだろうと感じたことだ。 自社では自社パッケージ製品を開発している。この開発には双方向のコミニュケーションがかなり必要になる。特に顔を突き合わせて話すというのがとても重要になる。さらに感覚的な話も多くなりがちだ。 実際、週１出社してる社員とはよく話をする。仕事の話、雑談。本当に色々話をする。 特に自社は社員も少なく１社員が担う範囲も多く、意思疎通がとても重要になる。これが週１出社してもらうだけで、かなり違う。ギャーギャー面と向かって話ができるというのはとても重要だと感じたのだ。 フルリモートワークになると出社は月１回とかになるだろうか、大きめの企業であればうまくタスクが分担できたりして
自分が考えるテックリード
このエントリがとても素敵だったので。自分が考えるテックリードの役割を書いてみることにした。個人の意見なうえに、自分自身がテックリードという職を経験したことないので、完全に妄想である。 自分はコードを書くプロダクトマネージャー、たぶん。 テックリードの条件積極的にチャレンジできる困ってる人を技術力で助けられるチームの成功を意識して行動できる技術力のある雑用。コードをゴリゴリ書いて解決というイメージではない。それよりも自分の担当範囲は粛々とこなしつつ、他のメンバーが困ってる所を助ける。さらに、ボトルネックになりそうなところを早めに潰して回る。 テックリードと言う素敵な名前だけれど、むしろ裏方。 技術力をつけるためには、そのための努力は惜しまない。その技術は自分のためというよりもチームのため、チームが成功するために他の人をサポートするために使う。サポートするためには自分のタスクを早めに終わらせる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
