あずにゃんはかわいいにゃん
弊社、かつてはプロダクトマネージャーがエンジニアの上級職扱いだったけど、数年前からPMはPMとして採用してるっぽい。エンジニア適正とプロダクト戦略適正は違うので妥当だと思う
This account is not set to public on notestock.
azcat、8年前からあるらしい https://github.com/osak/dotfiles/blame/master/zshrc#L23
This account is not set to public on notestock.
This account is not set to public on notestock.
globのシンボルは何されるかわからないので、そのまま渡したいなら問答無用でエスケープかクオートする習慣が染み付いている
TSA Pre✅の処理がワンチャン進んでないかと思ったけどそんなわけなかった(進んでてももうどうしようもないが)
コードレビュー指南書書いてみてるけど、思ったよりコードレビューの目的というのが複雑で、かつReviewer / Revieweeのどっちかでも評価値の低い行動をするとすぐ破綻するので、こんなんドキュメント化と数ヶ月単位の教育を抜きで実施するの無理でしょという気持ちになっている
コードレビューします、はじめ!で導入してもみんな同じ向きを向いてるようで微妙に違うルールを考えてるからそりゃ破綻するわ
@tsutsuii それは実装者をどれだけ信頼できるかによる気がしますね。チケットとかコミットメッセージとかで十分に補足があれば、設計そのもののレビューも十分に可能なので
@tsutsuii そこは採用と人事との兼ね合いですね……。末端がただの作業者になってしまうのも、そういうレベルの人を使わざるを得ないというリソース配分上の問題なので。そういう状況だと、そもそもコードレビューという行為自体が適切でない可能性もあります
@tsutsuii プログラミングは「ライン工に任せれば出来上がり」状態がないのが辛い気がしますね。本当にタイピングだけ早ければいい状態なら仕様書がすでに同程度に複雑なプログラムになっているはず(よって単に二度手間になっている)だし、そうでない(通常の)場合はある程度抽象的な仕様書をコードに落とすという仕事なので、何もしなければ品質にかなりばらつきが出るのは自然。そういう抽象的なものを相手にする人が「コードレビューはできない」くらいの能力だと厳しいとしか言えない
コード書けるのにコードレビューできない(人のコードが読めない)ってどういうことやねんと思うが、どうも知ってるテンプレにただ穴埋めする感じでコード書いてる人というのが存在するっぽいんだよな……変数名や離れたコードの一貫性が取れてないコードを生みまくるのはそうとしか思えない
テンプレ穴埋めタイプの人、典型問題が出てくるコーディングインタビューみたいなのは相性いいのかなと思った
@tsutsuii ありますねえ!まあアーティファクトになるくらいちゃんと動くならだいぶマシという説もある
@tsutsuii 弊社はエンジニア起源のWeb系なのでそういうときは強く押し戻せるんですが、HW系は確かにつらそう……
@brsywe おさけーめも、書いたことで満足して忘れるケースもたまにありミッションクリティカルな用途は危険
This account is not set to public on notestock.
575 (@ Austin Bergstrom International Airport (AUS)) http://foursquare.com/v/440da2cbf964a52091301fe3