mm1995tk

Webプログラマーをしています。何度目かの圏論入門中。

[トデス子'\ @todesking]

コードを書くことが減った代わりに、ハーネスを制御するためのmarkdownを書く機会が激増した。これ再現性もテスタビリティもないし状況悪化してない？

[naoya @naoya_ito]

現場が問い合わせで忙殺されているから AI チャットボット作ろうみたいな短絡的思考をやめろ、という話を先週 3回した

[りよ @ymdfield]

これは前から薄々感じていることですが、「操作的意味論が現在普及しているので理解しやすく"なってしまっている"が、あくまで歴史的・社会的経緯であり、表示的意味論のほうが原理的にわかりやすい」という論法自体は一つの可能な方法な気がしています（あまり深くはわかっていませんが）

[谷本 心 (Shin Tanimoto) @cero_t]

QUERYメソッド、ついに来るのか。

[mm1995tk @mm1995tk]

共感しかない

[Haruki Yano / Haruma-K @harumak_11]

仕事では何もしない時間を作るべき、という記事
https://t.co/hTU59Pesx3

・エンジニアはデフォルトの稼働率を80%に抑え、プレッシャーの高いプロジェクトがない限り労働時間や作業のペースを落とすのがよい
・テック企業では努力の量ではなく、適切なタイミングで適切な問題を解決するといった例外的な出来事によってパフォーマンスが決まる

・大規模な組織では、大きな契約を後押しする機能追加やインシデントの早期解決など、莫大な利益を生む些細な仕事が存在する
・これらの仕事はタイミングが命であり、チャンスを掴むためにはその時に忙しくない状態を保っている必要がある

・バックログの優先度が低いチケットをこなして常に100%稼働していると、他の仕事に気を配れず重要な仕事を見逃してしまう
・また、常に忙しそうにしていると、重要な仕事の情報を多く持つマネージャーから仕事を任せてもらう機会も失ってしまう

・常に全力でプレッシャーの低い仕事に取り組んでいると、いざインシデントなどの高プレッシャーな事態が発生した際に疲弊して対応できなくなる
・インシデント対応時も、すぐに手を動かさずに深呼吸をしてゆっくり思考することで、事態の悪化を防ぎ、他のエンジニアよりもうまく対応できる

・脳を休ませることで新しいアイデアが生まれやすくなり、重要なタスクを任された際にも全力を注ぐことができる
・エンジニアは役立ちたいという心理から目の前のタスクをつい片付けようとしてしまうが、何もしない時間を作るためにはあえて手を出さないよう自制する必要がある

・組織が優先していないドキュメント更新や技術的負債の解消を自ら引き受けてしまうと、自分が消耗するだけでなく組織が問題を放置する原因になる
・調整作業をやらないことで深刻な結果が生じるとしても、あえて介入せずに組織に痛みを感じさせて方針を変えさせるべきだ

・非公式なルートでデータ抽出やコード作成などを頼んでくる人に対しては、断ったり返信を数日遅らせたりして無報酬の仕事を避ける必要がある
・仕様が頻繁に変わるデザインの実装や中止になりそうなプロジェクトに対しても、すぐに対応せずに時間を置いてから一度だけ作業をして投資を最小限に抑えるべきだ

・エンジニアとしての成功は作業量を増やすことではなく、普段は力を温存して適切なタイミングで正しい行動をとる能力によって決まる
・常に全力を出すのではなく、非常に見返りが大きい年に数回の時期だけ限界まで働き、残りの期間は余裕を持たせることで高いパフォーマンスを発揮しやすくなる

[mm1995tk @mm1995tk]

昼マック690円高くないすか

[Hacksore @Hacksore]

BREAKING: these are not the same companies

[こと @kotolabdev]

TSなら純粋になろうなどと思うな
純粋になるのはPureScriptとElmだけでいい
TSなら死ねい

[mm1995tk @mm1995tk]

拡張機能は極力公式が公開してるもの絞ってるの、先見の明ってやつかもしれない。

[mm1995tk @mm1995tk]

なんか久しぶりにサイゼ行きたくなってきたな

[ଳゆきくらげଳ @yukikurage_2019]

Algebraic Effects ってそんな難しくないし、変に Result とか Option とか定義してその組み合わせで爆発するよりは Algebraic Effects で解決したほうが良い

[mm1995tk @mm1995tk]

きれいなコードが不要になるの、エンジニアが廃業するときなんじゃないかな。

[デジタル競争の敗者 @Lugendre]

「マクロを使えばできる」はこれ「貧弱な言語仕様をマクロで補わないといけないのでカス」派閥の人間としてもな……

[sat @satoru_takeuchi]

え〜、彼女さんlibc〜

[🈶うひょ🤪✒📘 TypeScript本発売🫐 @uhyo_]

コードの読みやすさとかって、
論理が破綻しているコードとかやりたいことがとっ散らかっているとかそういうのが問題なのであって、
「自分が知らない言語機能が使われている」とかは「勉強しろ」で済む話だからコードの読みやすさに数えないほうがいいですよ（？）

[mm1995tk @mm1995tk]

モジュロ終わったし明日以降のジャンプ買うか悩む。

[すえなみ @a_suenami]

仕様駆動開発がダメというよりも、仕様記述を全部自然言語でできる（それが効率的である）と思うな、構造化できるものは構造化しろ、ってことだと思うなぁ。

[mm1995tk @mm1995tk]

そんな難しい機能使う必要が本当にある？という問いの前にそれ本当に難しい機能か？という問いが必要そう。

[mm1995tk @mm1995tk]

関数型を無理やり持ち込んだんじゃね？と言ってる人いるが、再帰、ラムダ、カリー化使ったくらいで関数型とか言ってたら、最近主流の言語は全部関数型プログラミング言語になってしまうのでは。

[あいや🐕aiya000 @public_ai000ya]

僕が低賃金の頃に受けたパワハラ選手権を発表するよ！

1.「ラムダ式って何？」と問われる（軽症）
2.再帰関数呼出しを使ったら緊急1on1に呼び出され、長時間問い詰められる
3.カリー化関数をつかったPRに「これはなに？？」と言われ、レビューを拒否される（その人にApproveされないと作業続かない）

[tsuemura @tsueeemura]

「一行もコード書かずにアプリが作れた」とか「自分では全く記事書かずにnote毎日更新」とか、書かないことは価値なのではなくアプリや記事などの成果物に価値があるはずなのに、労力の方をアピールしちゃうの、端的に好きではない