情報更新
ツイートの記録を停止しています

 

ツイート検索

 

@sinsoku_listy
サイトメニュー
Twilogユーザー検索
新規ツイートの取得を再開しました!取得再開にはログインが必要です。

Twilog

ツイートの記録を停止しています

このアカウントはTwitter APIの仕様変更の影響でツイートの記録を停止しています。
記録を再開するには、Twilogにログインしてください。

 

@sinsoku_listy

神速@sinsoku_listy

Stats Twitter歴
5,105日(2009/06/15より)
ツイート数
78,835(15.4件/日)

ツイートの並び順 :

表示するツイート :

2023年04月04日(火)1 tweetsource

4月4日

@sinsoku_listy

神速@sinsoku_listy

1つのPRをレビューしてる間に手元に2つのパッチが増えるので、手元のパッチが増え続けるという...

posted at 15:08:10

2023年04月03日(月)3 tweetssource

4月3日

@sinsoku_listy

神速@sinsoku_listy

AWSコンソールを使う作業はレビューも記録も残らないので、仕事では基本NGだと思っているけど、人によってわりと認識が違いそう。

posted at 13:49:22

2023年04月01日(土)4 tweetssource

4月1日

@sinsoku_listy

神速@sinsoku_listy

エイプリルフールだから何か嘘つきたいけど、普段は嘘をつかず、品行方正に過ごしているから、何も嘘が思い浮かばないなー

posted at 10:45:06

2023年03月31日(金)3 tweetssource

3月31日

@sinsoku_listy

神速@sinsoku_listy

見積りについて考えたけど、チームが顧客の満足する成果を定期的に出せるなら、見積りは要らないのでは。
顧客の欲しい価値を整理して、優先度で並べた上で、これを定期的に届けることだなと。

posted at 16:39:18

3月31日

@sinsoku_listy

神速@sinsoku_listy

ソフトウェア開発の見積りについて思案してたけど、見積りの精度が上がれば上がるほどに各開発者の処理能力が可視化されるわけで、これはこれで厳しい世界な気がしてきた。

posted at 11:35:59

2023年03月30日(木)17 tweetssource

3月30日

@sinsoku_listy

神速@sinsoku_listy

GitHubで管理されているものは、そのリポジトリのIssueで管理するのが1番良いという仮説がある。テンプレを用意した上で、CSも営業もGitHubにIssue切る運用。

posted at 20:25:10

3月30日

@sinsoku_listy

神速@sinsoku_listy

プルリクのApproveやマージの気持ちも人によって変わりそう。個人的には「マージの利点が納得できて、メンテする覚悟を持てる」ものにApproveしたいと思ってる。

posted at 19:58:27

3月30日

@sinsoku_listy

神速@sinsoku_listy

@luccafort Request changesは「マージしたくない」ときで、Commentは「このコードの責任をもてない(メンテし辛い)」くらいの気持ちで使い分けていますねー

posted at 19:55:00

3月30日

@sinsoku_listy

神速@sinsoku_listy

レビュワーのApproveなしのコメントは暗に「私のApproveが欲しいなら、納得いく説明やコードの変更」を求めているのと同じだと思ってるけど、この辺りの感覚はわりと人によって異なりそう。

posted at 19:49:56

3月30日

@sinsoku_listy

神速@sinsoku_listy

バッグログを作って優先度の高いものから実行するのもアリだけど、開発者が好きな順番で改善するのもアリだと思っている。この辺りはチームの戦略次第。

posted at 17:43:28

3月30日

@sinsoku_listy

神速@sinsoku_listy

今までコピペエンジニアにも「自然言語を読んで選び取る」という価値があったが、Copilotが上位互換になりつつある。

posted at 16:13:35

3月30日

@sinsoku_listy

神速@sinsoku_listy

GitHub Copilotがすごいと思うけど、Copilotが生成したコードを理解せずにそのまま使う人はそのうち職を失うだろうなとも思う。

posted at 16:13:35

3月30日

@sinsoku_listy

神速@sinsoku_listy

@tdakak そこも含めて人間で、人間が上手く働いて成果を出すのが仕事なので、相手の気遣いが低いなら自分が譲歩して成果に繋げられないか...みたいな考え方をするようになってきました。

posted at 10:50:17

3月30日

@sinsoku_listy

神速@sinsoku_listy

@bakueikozo 自宅の🔑が無いのはすごい。
ただ、そこの連携だと自宅と外出の区別なので顧客の要件を満たせるか怪しいので難しそう。(ハードオフにいるのが分からなそう)

posted at 09:35:39

2023年03月29日(水)19 tweetssource

3月29日

@sinsoku_listy

神速@sinsoku_listy

機能要望(feat)とバグ(bug)は起票しつつ、雑用(chor)は一切起票しないくらいが良かったりするのかな🤔

posted at 17:15:06

3月29日

@sinsoku_listy

神速@sinsoku_listy

Issueの粒度は技術力に依存する気がしていて、人によって簡単に終わる(起票するまでもない)範囲が違って合わせるのは難しい気がする。

posted at 17:15:05

3月29日

@sinsoku_listy

神速@sinsoku_listy

Twitterのハッシュタグで投稿されている内容からプロダクトのバグを見つけてGitHub Issueに起票するAI欲しい。

posted at 14:32:27

3月29日

@sinsoku_listy

神速@sinsoku_listy

Issueを書くよりもSlackで質問する方のハードルが低いのはたしかにある。ChatGPTがSlackの会話からプロダクトの課題を見つけて、良い感じにIssueとして登録してくれないものか...

posted at 14:31:33

3月29日

@sinsoku_listy

神速@sinsoku_listy

Slackで質問ではなくて、GitHub Issueに「プロダクトの課題」として起票するのが良い気はするものの、そういう環境を整備するのがまず難しそう。

posted at 14:31:33

3月29日

@sinsoku_listy

神速@sinsoku_listy

@kameike まぁ、最初にWhyを適切に書くのが難しいのですが...。ただ、Howは相手に出してもらいたいし、進捗(終わりそう、ヤバそう)も相手に判断して欲しくて、こっちで「ヤバそうと判断して助ける」をすると相手の判断力が高まらないかなと。

posted at 14:20:28

3月29日

@sinsoku_listy

神速@sinsoku_listy

@kameike タスクに関してはWhyと期限をいくつか切って任せるのが良いのかなと思っています。
最初の期限で大まかな方針を出してもらって、次の期限で...と複数のチェックポイントを設けて、それ以外では相手を信頼して一切の口を出さない方が委譲できそう。

posted at 14:18:35

3月29日

@sinsoku_listy

神速@sinsoku_listy

仕事を委譲するにも工数がかかるので、普段から委譲できるように仕事を進めるのが大事そう。タスクを抱え込み過ぎると委譲するための時間まで無くなる。

posted at 10:12:24

3月29日

@sinsoku_listy

神速@sinsoku_listy

仕事の手が回ってない感あるけど、チケット書くのも時間かかるわけで、結局は速度を高めるという身も蓋もない結論。

posted at 09:31:30

3月29日

@sinsoku_listy

神速@sinsoku_listy

民主主義的な進め方はメンバーの納得感や属人性の排除を重要視していて、必ずしも成果のために実施してないと認識してる。

posted at 01:44:11

2023年03月28日(火)8 tweetssource

3月28日

@sinsoku_listy

神速@sinsoku_listy

コンフリクトしないのが自分にとっては楽だけど、どのPRがいつマージされるかも分からないし、色んな人が改善を容赦なく投げるのもそれはそれで良い気もしてきた。

posted at 13:45:58

3月28日

@sinsoku_listy

神速@sinsoku_listy

ただ、最近は blame.ignoreRevsFile あるから、cosmetic changesのリジェクトは緩和される余地はありそうな気もする。

posted at 13:16:23

3月28日

@sinsoku_listy

神速@sinsoku_listy

改めてRailsの「課題はIssue、機能要望はプルリク、cosmetic changesはリジェクト」は理にかなってる運用だなと思う。

posted at 13:14:25

3月28日

@sinsoku_listy

神速@sinsoku_listy

@chiastolite 全PRを見ていれば誰が、どの辺りのコードを触っているのか分かるので、その近辺を変更するPRは後回しにする感じでしょうか。
RuboCopのStyle/StringLiteralsのような優先度の低い、しかし広範囲を変更するcosmetic changesは特に考慮していると嬉しい。

posted at 13:09:14

3月28日

@sinsoku_listy

神速@sinsoku_listy

わりとコンフリクトするプルリクを作られることが多くて、たぶん他の人のプルリクを読んでる人が少ないんだろうなぁ...というのを感じる。
粛々とリベースして直すわけですが。

posted at 12:46:04

3月28日

@sinsoku_listy

神速@sinsoku_listy

プルリクのタイミングを考えて出して欲しいと思うのは他人に求めすぎなんだろうか...。自分が全てのプルリクを見た上で、できるだけコンフリクトしないように作っているので、それを他人にも求めてしまう。

posted at 12:31:00

このページの先頭へ

×