TokyoGirls.rb Meetup vol.2セッションでの学び

ほっしー

昨年参加したTokyoGirls.rb Meetupの、セッションでの学び、感想をメモ。

Ruby on Rails 最初の一歩

ドキュメントの歩き方、デバッグの仕方、PR（プルリク）の書き方について。

公式ドキュメント見よう。正しい書き方を確認するってすごく大事。
byebugないと私開発できない・・・！
プルリクは、「やりたいこと」「対応したこと/してないこと」を明記する。ソースコードのコミットフローなんかも今一度勉強したい・・・。

事業知識を深掘りし、より人の役に立つサービスに改善する

事業知識＝ドメイン知識。
この辺がちゃんと理解できていないと、DB設計なんかもイマイチになってしまう。
わかりみが深かった。

Rackミドルウェア入門のためのRackミドルウェア

TracePoint使ったことないので、勉強したい。

エンジニアとチームを組んで見えないものをデザインする

文脈＝コンテキストの共有の大切さ。
デザイナーはユーザの流れを知りたいし、
エンジニアはデータの流れを知りたい。
このすり合わせが大事。Figmaは俯瞰して画面遷移を評価するのに良い。

プロジェクトマネジメント沼にようこそ！

技術者同士の1on1おもしろそう。どんなことを話すのかな。
OKRの共有を朝会でしてるのも良さそう。

いつもの開発のようにOSS開発をしよう

毎朝rails/railsのIssueやPRを1つ以上見ているとのこと。尊敬・・・！

時短勤務ママエンジニアの要件ヒアリング力

エンジニアの本質は問題の発見と解決。
そのためには背景を知るのが大事。
システム開発の背景を理解しないまま進めちゃってること、確かにある・・・。それじゃあ問題解決にならないよね。

しめきりは相手の都合。
納期について、いったんは聞くが、恐れずに期待値調整しよう。

強いエンジニアという灯

強いエンジニアとは。
強いエンジニアになるための学習法など。

とにかく「覚える」！
そうすることで調べる時間が短くなり、速くなる。
法則を覚え、法則に沿ったコードを書こう。

自分がやったことへの評価もしよう。
絶対大事だってわかってるけど、なかなかできてないやつですね・・・。

これ最近実感する。時々は正しい書き方をちゃんと認識しなおす機会を設けていきたい。直近で勉強になったやつ↓

エンジニアの本質は問題解決。

「コード書いてると、なんでマネージャーになっちゃうのかな」なんて話もありましたが、コードを書くことも、マネジメントすることも、問題解決に通ずるものがあるからですね。

さいごに

共通したキーワードは

「コンテキストの共有」「背景を知る」「エンジニアの本質は問題解決」

スポンサーのみなさんのLTも楽しかったです。
特にCI&Tさんはトラブルでスライドが表示できなかったのですが、自社のミッション、ビジョン、バリューを熱く語る様子は印象的でした。
人材開発＝to develop people

私は今後なにをDevしていこうかなぁ。

この記事が参加している募集

イベントレポ

25,306件

この記事が気に入ったらサポートをしてみませんか？