自分の上司は仕事ができる。 なぜできるのか考えたい
間違いない。 細かいことも知ってたりする
ドキュメントを漁ったり、他人の話を聞いてきたんだろうなーと思う。 ドメイン知識ベースで物事を理解している節がある。 ショートカットできると思うし
な感じがする。 人の話を聞いて潜在的な需要や、起こっている事を理解する力が強いように思える。 今起きている事を知りたいのでそれをくれ、と言ってる気がする。
どういう人がどういう情報持ってて、どういう動き方するか知ってる気がする。 それにより、仕事の進め方が上手なイメージ
これらが能力の成長を助けてきたんだと思う。 自分もここを目指したい。
プロダクトはビジネスの手段でしかない。 ユーザーと繋がるインターフェイスでしかない。
売れないと意味がない。 売れるとは払う価値がある、と思わせる事である。
綺麗事だけでは上手くいかない。
株主や経営陣から市場で勝つための期日を求められる。 その中で最善を尽くすために、テストを省略するのは当たり前。
学ばざるを得ない環境は素晴らしい
人は怠惰な生き物だから
コードは基本的な書く力はいる。
ピュアな実装を知ってた方が良い(解決策思いついたり、) ブラウザで出来る標準機能を知るのが良い
マニュアルを読み解く力もいるし、ピュアなものではどういう事ができるのかも知っておいた方が良い
ブラウザとサーバーの標準的な機能を知っておいた方が良い
目にみえるアウトプット出さないと評価されにくい。
が求められている。 肌感として、AIがリポジトリの文脈を読み解いて正確なものを出すイメージはない。
なので、それを修正する能力が求められている。
いるが、単体は簡単でもリクエストはめんどくさいケースがある。 単体は単体なので簡単だが、リクエストは集合体なので書くのが面倒。
依存しない単体はプログラムで必要である。 それをまとめるユースケースやサービス層はある。 それらのテストはめんどくさい。
基礎的なアルゴリズム能力はいる
需要がある、というのは大切なのでこれからも使われるが、ほとんどのケースではオーバースペックになる。
Svelteは中&小規模なら十分な機能である。
プロダクトは負債化するし、ライブラリアップデートは大変なので、依存しすぎない方が良い。
フレームワークの進化の方向性、というのは大事。
間違った方向に進むとパフォーマンスの悪いフレームワークになる。
もっとメンタルに気を配ること。 自分はメンタル強くない。
苦手な事は断って良い。 最初から約束しない。
自分には苦手な事があるから、それを意識すること
大体は実際何とかなる。 けど断ってもいい。 相手の言いなりにならなくて良い。
話を聞いていると、その時の納期や予算、リクエスト数、捨てやすさ、保守しやすさ、人の集めやすさ、などを考慮して決めている感じがする
動的言語だと開発しやすい。 開発速度も上げやすい。 無難なサービスで情報もたくさん手に入って、後からレガシー化しないように無難なやつを選ぶのが良さそう。
アップデートが多いとアップデートコストがかかる
また、クエリを発行する必要がないものはview、メモリで処理したいのはredis、高速に動かしたいならnoSQLと、そこら辺も選べるようになっていた方が良さそう
要求を実現できるアーキテクチャを考えないといけない。 その際に障害が起きないように、バッチ処理した方が良いものは非同期処理でバッチサーバーにやらせる、SQSを使う、障害検知のためにモニタリングも大事なのでその知見もいる、AWSサービス等のコスト最適化、CICDの整備、テストケースの洗い出し、アジャイルな開発ができるように良いコードを書くようにするのが大事な気がする
読んだ時に理解できるようにしないといけない。
コードの書き方や、分かりやすい名前をつける、複雑にならないように実装できるスキルをつける、等が大事だと思う。
ifの条件はハッシュを使えば引数を私てバリューを表示、とかできる。
人の話を理解することも大事。 相手が求めている事がなんなのか理解する。 相手が気づいていない事を掘り出す能力もいると思う
また、アンテナを立て続けて、キャッチアップしていくのも大事だと思う。
技術動向を知っていると解決できる事もあると思う
そう思っている。 自分の人生をもっとコントロールしたほうが良いように思える。
断ること大事だと思う。
自分に自信を持って、断った方が良い。
コミュニケーション端折ろうとして失敗するケースがあるように思える。
自分からコミュニケーション取ろうとして嫌な対応される事あるので、話かけるのは躊躇しても良い。
けど、気を利かすと損をするケースがあるなと思える。
なので気を利かすのは辞めようと思う。
無視をすれば良いと思う。 無視しよう
うざいこと言われる可能性もあるので、発言を慎めば良いと思う
