エンジニアの立ち居振舞い:過度に仕組みを作らない
特に仕事でコードを書く場合で意識してることだけど、過度に仕組みを作らないというのを大事にしている。
ここで、過度な仕組み
とは例えば最初から以下のような実装をすることを指すことにする
- 1つのクラスでしか使われないコンテキストの上に成り立つ実装をグローバルなクラスに切り出してそのクラスを他のクラスからも使えるように実装する
- テンプレートメソッドパターンを適用して部分的に実装を差し替えられる用に実装する
- 例えばjavaとかで実装クラスは現時点で一つしかないのに最初からインターフェースを用意する
要するに、万人が使うようなフレームワークやライブラリを実装するかのように拡張性の高い
コードを実装してしまうことを指す。
過度な仕組みを作れば作るほど、仕組みの動作を保証するのに必要なUTの量は増加し、実装量も増えてレビューは大変になり、またその部分を修正する人はロジックそのものに加えて仕組みそのものの仕様理解にも時間を取らされたりと、色んな人の工数を大量に消費する。
それでもまだ本当にそんな仕組みが必要だろうか?自分たちが今必要としているのは動く実装でありフレームワークではない。
自分が過度な仕組み
を持つ実装をする場合は、今から作ろうとしている実装において、明らかにコピペできるレベルの実装がいくつもあるなーと感じた時だけにしている。これもしかしたら他でも使うかもなーと思うこともあるのだが、それでも一箇所でしか使われないコードならグッと我慢してベタッと実装する。
もちろん機能的な分解点やUTの書きやすさを意識してメソッド自体はあれこれ分割したりスコープを考えたりクラスを分けたりといったことはするが、しょっぱなからサブクラスを作ってそのクラスをオーバーライドするところから実装を始めたりはしない。
なぜか?今作ろうとしている目の前の機能こそが一番大事だからだ。
今作ろうとしている機能を過不足なく、他のメンバーが理解しやすい形の落とし所に納めて、リリースすることこそが一番大事だからだ。だから無駄なことはしない。早く作って早くリリースする。
そして時が経って、必要になったらその時初めて抽象化でもなんでもする。
大事なことは常に「今」必要最低限のものだけで始めて、「必要なとき」に素早く拡張できることだと思う。
今読んでる本とか
完全に自分用のメモ。
平行してその時の気分で読む本を選んで読む癖があるのでたまに何読んでたか忘れて最初から読み直すハメになったりする。
今読んでる
Google PageRankの数理 ―最強検索エンジンのランキング手法を求めて―
- 作者: Amy N.Langville,Carl D.Meyer,岩野和生,黒川利明,黒川洋
- 出版社/メーカー: 共立出版
- 発売日: 2009/10/10
- メディア: 単行本
- 購入: 4人 クリック: 249回
- この商品を含むブログ (29件) を見る
Googleを支える技術 ?巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)
- 作者: 西田圭介
- 出版社/メーカー: 技術評論社
- 発売日: 2008/03/28
- メディア: 単行本(ソフトカバー)
- 購入: 47人 クリック: 1,166回
- この商品を含むブログ (374件) を見る
- 作者: ジョン・L.ヘネシー,デイビッド・A.パターソン,成田光彰
- 出版社/メーカー: 日経BP社
- 発売日: 2014/12/06
- メディア: 単行本
- この商品を含むブログ (2件) を見る
- 作者: マイケルマローン,Michael S. Malone,土方奈美
- 出版社/メーカー: 文藝春秋
- 発売日: 2015/09/12
- メディア: 単行本
- この商品を含むブログ (1件) を見る
積んでる
- 作者: 渡辺佑基
- 出版社/メーカー: 河出書房新社
- 発売日: 2014/04/14
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (5件) を見る
ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装
- 作者: 斎藤康毅
- 出版社/メーカー: オライリージャパン
- 発売日: 2016/09/24
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (18件) を見る
ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化
- 作者: Ilya Grigorik,和田祐一郎,株式会社プログラミングシステム社
- 出版社/メーカー: オライリージャパン
- 発売日: 2014/05/16
- メディア: 大型本
- この商品を含むブログ (4件) を見る
HTTP: The Definitive Guide (Definitive Guides)
- 作者: David Gourley,Brian Totty,Marjorie Sayer,Anshu Aggarwal,Sailu Reddy
- 出版社/メーカー: O'Reilly Media
- 発売日: 2002/09
- メディア: ペーパーバック
- 購入: 1人 クリック: 34回
- この商品を含むブログ (1件) を見る
- 作者: 平井有三
- 出版社/メーカー: 森北出版
- 発売日: 2012/07/31
- メディア: 単行本(ソフトカバー)
- 購入: 1人 クリック: 7回
- この商品を含むブログ (5件) を見る
今年読んだ本で面白かったやつ(ソート順は適当)
- 作者: スティーブン・レヴィ
- 出版社/メーカー: CCCメディアハウス
- 発売日: 2012/08/31
- メディア: Kindle版
- 購入: 1人 クリック: 16回
- この商品を含むブログを見る
- adwordsのアイデアは最初からあったと思ったんだけど、当初はマネタイズ手段としては検索エンジンのライセンスビジネスを考えていたというのと、adwordsと似たようなアイデアが他社検索エンジンにすでにあったのは初めて知った。
- googleのproductの強みはオリジナリティよりも泥臭い努力に裏打ちされた愚直な性能の高さにあるんやなってはっきりわかるんだね。
- googleの中国撤退の話は多分ほかのメディアよりずっと詳しかったのではと思った。
サーチ・インサイド・ユアセルフ――仕事と人生を飛躍させるグーグルのマインドフルネス実践法
- 作者: チャディー・メン・タン,ダニエル・ゴールマン(序文),一般社団法人マインドフルリーダーシップインスティテュート,柴田裕之
- 出版社/メーカー: 英治出版
- 発売日: 2016/05/17
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (6件) を見る
- googleの宣伝的な文章が結構多くて最初の方はもどかしく感じたが、その後に続くマインドフルネスの具体的な内容については割と詳細に書かれている。
- 個人的な感想としては瞑想に対する敷居がかなり下がった感じ。今でも忘れない限りは寝る前に瞑想をしている。
- 運動と瞑想の習慣がない者の末路は(ry
データ解析のための統計モデリング入門――一般化線形モデル・階層ベイズモデル・MCMC (確率と情報の科学)
- 作者: 久保拓弥
- 出版社/メーカー: 岩波書店
- 発売日: 2012/05/19
- メディア: 単行本
- 購入: 16人 クリック: 163回
- この商品を含むブログ (29件) を見る
- 作者: ジョン・ソンメズ
- 出版社/メーカー: 日経BP社
- 発売日: 2016/06/02
- メディア: Kindle版
- この商品を含むブログ (7件) を見る
- 作者: 五木田和也,青木健太郎
- 出版社/メーカー: 技術評論社
- 発売日: 2016/09/27
- メディア: 単行本
- この商品を含むブログ (3件) を見る
- 作者: 川上量生
- 出版社/メーカー: KADOKAWA / 中経出版
- 発売日: 2013/10/10
- メディア: Kindle版
- この商品を含むブログ (21件) を見る
- 作者: 齋藤ウィリアム浩幸(さいとう・ウィリアム・ひろゆき),William Hiroyuki Saito
- 出版社/メーカー: 日経BP社
- 発売日: 2012/10/04
- メディア: 単行本
- 購入: 2人 クリック: 6回
- この商品を含むブログ (6件) を見る
- 作者: 山田胡瓜
- 出版社/メーカー: 秋田書店
- 発売日: 2016/04/08
- メディア: Kindle版
- この商品を含むブログ (6件) を見る
- 作者: 得能正太郎
- 出版社/メーカー: 芳文社
- 発売日: 2015/03/27
- メディア: Kindle版
- この商品を含むブログ (13件) を見る
- 作者: 森井ユカ
- 出版社/メーカー: 主婦と生活社
- 発売日: 2015/08/28
- メディア: 単行本
- この商品を含むブログ (1件) を見る
チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ
- 作者: エイミー・C・エドモンドソン,Amy C. Edmondson,野津智子
- 出版社/メーカー: 英治出版
- 発売日: 2014/05/24
- メディア: 単行本
- この商品を含むブログ (3件) を見る
- 作者: 石塚千尋
- 出版社/メーカー: 講談社
- 発売日: 2013/12/09
- メディア: コミック
- この商品を含むブログ (20件) を見る
- 作者: サカーイ
- 出版社/メーカー: サカーイ
- 発売日: 2013/02/09
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: 森博嗣
- 出版社/メーカー: 幻冬舎
- 発売日: 2015/12/18
- メディア: Kindle版
- この商品を含むブログ (10件) を見る
- 作者: 板垣政樹
- 出版社/メーカー: 秀和システム
- 発売日: 2016/03/09
- メディア: 単行本
- この商品を含むブログ (1件) を見る
Java 謎+落とし穴 徹底解明 (標準プログラマーズライブラリ)
- 作者: 前橋和弥
- 出版社/メーカー: 技術評論社
- 発売日: 2001/12/01
- メディア: 大型本
- 購入: 8人 クリック: 40回
- この商品を含むブログ (21件) を見る
- 作者: アラン・W.ビアマン,Alan W. Biermann,和田英一
- 出版社/メーカー: ASCII
- 発売日: 1993/06
- メディア: 単行本
- 購入: 6人 クリック: 184回
- この商品を含むブログ (30件) を見る
cでwebサーバを書き始めた
趣味でcでwebサーバを書き始めた。 8月末ぐらいからちょっとずつ作業を進めていたのだが、とりあえずhtmlファイルをレスポンスするところまでは実装できたのでgithubに公開した。
名前の由来は旧日本海軍が第二次大戦時に開発したオートジャイロの名前を拝借した。何となく、サーバー系プログラムには空を飛んでる何かの名前を付ける習慣があると思っているのでその習慣に倣ってみた。
書き始めた理由は今年開催のいくつかのカンファレンスでOku Kazuhoさんのhttp2のセッションを聞いてhttp2の実装に興味が湧いたからなのだが、それ以前にhttpもよく分かってない。ということでhttpの勉強も兼ねてまずはhttp1.1サーバを書いてみようと思った。また、せっかく新しいものを書くなら使ったことがない言語にしよう、ということでcで書くことにした。あとパタヘネ読んでたら低レイヤーを触れる言語を1つはちゃんと書けないと理解できないことが沢山あるという危機感を感じたという理由もある。
今はまだhtmlファイルしか返せない(.htmlか.htm以外の拡張子を指定すると415を返す)し、 ../../tmp/hoge.html
みたいなパスにアクセスされると一発でアウトみたいなセキュリティホールだらけなのだが 、一般的な静的ファイルを置いて使う程度には困らない程度のものに仕上げたいと思っている。実装予定のfeatureはREADME.mdに記載した。
あとcのノウハウが全然ないので手探りで書いてる感が半端ない実装状態である。char配列のバッファサイズとかかなり適当だし、どういう時にmalloc使うべきでどういう時に配列使えばいいかもよく分かってない。どう最適化すればよいのかも併せて勉強していく必要がある。あとMakefileも適当に書いているしgccのオプションも言われるがままにホイホイコピペしてきたものである。とりあえずgdbでデバッグするために-g o0
は付けているが、これもホントはmake debug
みたいなdebug用taskに分離して置いた方がいいのだろうか。周りにcでプロダクト書いてる人がいないのでこの辺の知見が得られなくて中々に辛い。
余談だが、趣味プロダクトが一つでもあると心が落ち着くというか、仕事で辛いことがあったり退屈していても、家に帰ってからあのバグを直そうとかあれを実装しようというポジティブな予定が持てて、精神衛生上良いのでオススメである。
自分にはもう一つの趣味プロダクトslidesearch.jpというwebサービスもあるので、こちらについてもたまにrailsとかgemのバージョンを上げたり細かいバグを直したりという作業を日課としている。大したUIはないのだが、自分の勉強のためだけにフロントをangular2で書き直してSPAにするかとか色々考えている。
周囲からの期待値を自分で決めて自分で動くということ
今の会社に入ってから新たに増えたタスクとして、「周囲からの自分に対する期待値を自分で決めて動く」というタスクがある
今までの会社でいえば、「お前に期待することはこういうことだから」というのを教えてくれる人がいた。その上で自分がやりたいことを踏まえてどういうことをやっていくかを決定してきた。 だから周囲の期待値は何となく見えていたし、自分でもそれについて納得しながら仕事をしてきた。言い方を変えれば「走るべきレールが決まっていてその上でいかにパフォーマンスを出すか」ということに集中していた。
それが今の会社では、誰もレールを引いてくれない状態になった。これは会社の方針として開発チームに意図的にマネージャーを置いていないからなのだが、この状況に当初は戸惑った。 自分の期待値は当然伝えられず、何をすべきか分からず、何を期待されているかすら分からず、さらに言えば、何故自分が今の会社に採用されたのかすらわからなかった。(一応聞いてはみたが、まぁそこまで自分である理由はなかった。)
ということで、「どうすれば自分がこの会社で価値を発揮できるか?」を自分で考える必要が出てきた。
入社して最初の3か月でやったことは、サーバーサイドチームの開発体制の見直し。 デプロイ頻度の固定化、相互レビューの導入、エラー監視のためのBugsnag導入、CircleCIの導入、定例ミーティングの導入、Hubot導入などなど、これまでいた会社でやってきて上手くいったことを導入して足場を整える仕事を中心に行った。「誰かにやれ」と言われたからやったのではなく、「今これをやれる知識があるのは自分しかいない」という自己判断の元行った行動である。誰も文句は言わなかったし、多少抵抗があった項目もあるが説得して導入していった。今でも適宜チーム内で話し合ってやり方は都度見直している。
また、もう一つの自分の役割として「コードの品質を担保する」というのがあると思っている。スタートアップならよくあることなのだろうが、今までスピード重視で書かれてきたコードベースは必ずしも綺麗ではなかった。Rails純正の機能を使えば解決できることを自前で処理していたり、そもそも問題を抱えたまま運用していたり、課題を結構抱えていた。
しかし、それは「課題」として認識されていないものが多かった。要するに、それを「課題」だと気づける人間がいなかった。自分は気づける人間だったので、その課題を直していくことが自分の役割だと今も考えている。
普段やりたくてもできないタスクを1日かけて消化する「改善部」イベントを企画してrubocopを導入したり(もちろん.rubocop.ymlは意味のある指摘だけに絞るようにいじり倒した上で)、普段からコードベースをいじるときに既存のコードでリファクタできるところはリファクタし、新規に書くコードは後から入ってくる人が真似したとしても負債が残らない、変なコードにならないようにすることを第一に考えてコードを書くようにしている。
レビューは自分一人だけでやってる訳じゃないのですべてのコードを見られる訳ではないが、自分がレビューするコードはなるべくそういう観点で見ている。もうスピードだけでコードを適当に書き殴ってプロダクトを作っていいフェーズの会社ではないからだ。ユーザーが増えるにつれて安定稼働への責任に重きをおく必要が高まっている。もちろん、この認識は自分がセールスやサポートの人と話をしていて思っているだけであるが。
今のところ、普段のタスクをやりつつ上記のようなことを念頭において仕事しているが、今のところ誰からも「それよりこういうのやってよ。」「お前最近価値のある仕事してないよ。」と言われることはないので周囲からの「実際の期待値」も「自分が考える周囲からの期待値」とそこまでズレてないようだし、自分の仕事はそこそこ会社に貢献できているのではないかと思っている。 この辺も誰からもフィードバックをもらったことがないので分からないが、とりあえず誰かから何か言われるまで、あるいは自分の仕事が意味がないと自分が感じるようになるまでは、今やっている草の根活動を続けようとは思うし、今後も必要そうなタスクが見つかったら開発チームに提案して自分でやってみようとは思う。
VP of Engineeringみたいなポジションの人がいる規模の開発組織だと、この一連の作業はそういうポジションの人がやるんだろうけど、ウチみたいなスタートアップにおいてはまだ自律的に各メンバーが考えて行動する必要がある。自分は少なくともそう考えているし、他のメンバーもそれぞれ必要だと思うことを自律的に考えてやっている節がある。どこまで今の体制で開発チームがスケールできるか分からないが、少なくとも自分で何が必要かを考えて動くというのは、自分の経歴としても良い経験だと考えているので、とことん必要なことを考えて自律的に動いてやろうと思っている。
転職にまつわる昔話
- この文章は、昔某サービスで書いていた日記を改めて読んでみたら結構面白かったのでそのサービスが無くなる前にこちら転載したもの。
- 一部修正済み。
こういう話、する相手も居ないけど自分の備忘録代わりに書いておく。
時は新卒で、SIerでSEやってていた頃。
なんとかして「エスイー」から「エンジニア」になりたかった俺は、片っ端から面接受けまくっていた時期があって、その中にはエンジニア派遣の会社もあった。正社員として雇用しつつも実質的には派遣、みたいな。社名は控える。
んで、書類送ったら普通に面接に来いと言われたので行った。
これこれの理由でエスイーからエンジニアになりたいんですよねぇという話をしたら、「そんな大手に勤めてるのにプログラマになりたいの?変わってるねぇ」と言われた。まぁそうだよね。下流に降ろうとしてるし、給料も下がるの覚悟な訳で。
その面接はなんか適当に終わって、その次は部長クラスが出てきた。
したら開口一番
「私、御社(自分の当時の勤務先)と仕事させて頂いてますよ」
まぁそうなるな。大量に派遣使ってる上流エスアイアーなので。
それはさておき、わたしゃエンジニアになりたいのですよ。
「うーん。紹介できなくもないですが、ホントに作業みたいな感じですよ」
構わんよ。コードが書けりゃ。
「うーん。。そうですねぇ。でもかなり貴方だとオーバースペックかも」
でもXXXのYYYでしょ。悪くないと思いますが。
「うーん。場所もZZZ県ですし。いや、いいとこですけどね。会社からも近いとこにマンション借上げしてますし。」
良さそうじゃなイカ。
と思った矢先
「でも私はおすすめしません」
マジかよ。
「今日私はseri_kさんと話してね、思ったんですよ。あなたのような人と直接仕事がしたいって。だからこの仕事は紹介したくないんですよ」
わしゃヒラのエスイーで、外注手配する部署じゃないぞ。。。
「seri_kさんは今の仕事に非常に悩んでるみたいですが、それは仕事に真剣に向き合っているからだと思いますよ」
人材会社らしいことをおっしゃる。
「だからもっかい考えてください。今日は結論を出しません。」
ということで終わってしまい、その後自分でも考え直して、時間がかかっても普通に正社員としてjoin出来るクチを探そうと思い直して自分から辞退した。
なお辞退するために送ったメールの返信でも「賢明な判断だったと思います」という返事をくれた。
それ以来、その部長クラスのオッサンとは一度も会ってないが、適当な担当者が面接していたら自分は今頃ZZZ県でYYYの開発しかできないオッサンになってたかも知れないしワープアになってたかも知れない。
安易な選択をせずに考え直させてくれたあのオッサンには感謝している。
あの人からしたら、ひとりでも多く派遣の頭数を揃えてクライアントに紹介出来た方が良かったはずだ。
しかしそれをせず、自分にとって結果的に良い選択をさせてくれた。
社会に出てから何度かこういう不思議な出会いがあったが、全く知らない人に対しても気をかけてくれることもある、という人の業の深さを知ったはじめての出来事だった。
キャリアを積み直せ
あまり過去を振り返って後悔していることはないんだけど、一つだけあるとしたら高校時代に将来の職業について何も考えずに大学を選んだことである。
某大学農学部に行ったのは、前提として高校を出たら国立の大学に行かないと親が許さない状況(考えてみれば姉二人は私立だったのだからおかしな話だ)、しかし興味のあることが生物ぐらいしかない。じゃあ農学部か、ぐらいの感じであった。結果としてどうなったかと言えば、卒業研究でリンドウの花弁の画像計測+判別分析を用いた予測モデルの構築という今の機械学習への興味に繋がる貴重な経験はできたのだが、結果としてそれを元に就職するほどの学術的知見はなく、SEとして就職してその後サービス開発屋になって現在に至る。
これまでのキャリアに何も不満はない。SIerで新卒入社→事業会社に中途入社というのは、数年前に流行ったSEのキャリア転換の典型そのもので、自分のキャリアは客観的に見ればうまく行っているのだと思う。幸いにして、現在は転職時にこちらが会社を多少選ぶくらいのことはできるぐらいのスキルも身についた。
悪くない。しかし、自分がここまでスムーズにキャリアを積めた要因は、これまで周囲から言われた評価を統合すれば、結局のところ「よく働く」以外の何者でもなかった。 単に会社員として優秀、というもの以外の何者でもない。実際、エンジニアとしてのスキルは非常に平凡で優れているとは決して思っていない。 エンジニアリングだけで見れば自分より優秀な人はたくさん見てきた。自分には、言ってしまえば、既存のフレームワークの上でビジネスロジックを実現するだけのスキルしかない。言語やフレームワークを乗り換えることはできる。むしろ得意な方だが、ゼロから何かを実装するスキルはない。だから誰かが作った環境の上に乗っかるしかない。ついでに言えば結局webアプリケーション以外の実務経験はないから知識が酷く隔たっていることも自覚している。
今の職場環境を考えれば非常に贅沢なことを言っているのはわかるのだが、今はそれが今後のキャリアにおける最大の不安である。結局のところ自分のような会社員として評価されるような人間はマネージャーになるしかないと薄々感じているが、正直に言えば「会社員として優秀なエンジニア出身のマネージャー」で終わりたくないと感じている。
今はエンジニアとして本当に難しい問題を解決する力が欲しい。最近、仕事でもパフォーマンスが問題になっている箇所について取り組んでいても、効率のいいデータ構造もアルゴリズムも知らない自分にはマシンリソースを増やすことで力技で解決することしかできないケースが増えている。費用対効果を考えたら時間をかけるよりマシンリソースを増やすことで対応する方が良かったりするのでビジネス的には間違ってないかもしれないが、永遠にマシンリソースを増やしていくことが本当に正しい解決策なのか。本当はもっと優れたアルゴリズムを書いて解決できそうな問題もあり、実際社内では将来パフォーマンスが問題になりそうでなんとかして書き直せないかという議論が度々起こるメソッドがある。しかし自分にはそれを解決できない。
上記を踏まえた上で、今年に入ってからもう一度本当に「エンジニアとして」のキャリアを積み直すために動いている。具体的にはこのブログでも何度か書いてるが、具体的にパタヘネ本とその他資料で大学のCS専攻の学部卒業と同レベルの知識を積み直す。だいぶ忘れている高校数学をやり直す。(今は数ⅡB辺りか。この辺の勉強方法についても別途記す)TopCoder,Hackerrankの問題解きつつアルゴリズムについて勉強する。昔とった杵柄、機械学習をゼロから勉強し直す。データサイエンティストになるつもりはないが、今関心がある大量のデータを効率的に処理する処理、及びそこから必要な知識を得てデータを活かすことをスキルとする場合において機械学習は必須であると考えた。また、機械学習と統計の違い、ディープラーニングとNNの関係すらちゃんと理解していないエンジニアが多いということに最近気づいたので、まだこの分野では頭一つ抜けるチャンスがあるのではないかという打算もある。
その先に何があるか。独学では正直限界があるのと、時間が十分に取れないということから、一度サービス開発屋としての仕事から離れて時間を取って勉強したいと考えている。具体的には大学院進学を真面目に考えている。問題は果たして金銭的になんとかなるのか?というのと、卒業後にちゃんと再就職できるかという点。この2点については今後対策を検討していく。幸い、前者については試算した限りでは今のペースの貯金で数年貯金すれば学費を払いつつ引っ越しもしつつ2年間無職でも食いつなぐことができそうな目処が出ているので、どちらかと言えば問題は後者か。
普通30にもなれば結婚して家庭を持って、そんな大きなチャレンジはできなくなる年齢かも知れない(でも最近は晩婚化進んでるしそうでもないか?)。幸い自分には今は仕事しかない。仕事しかないのなら、できるところまで突き詰めて生きていくしかない。
会社で朝活を始めた
一人でも相変わらず何か勉強的な何かを続けてはいるのだが、社内slackで朝活の機運が高まったのでオフィスで朝活をやることにした。毎週水曜日の朝9時から10時まで。
朝活といっても今の所はただ集まって各々がやりたいことをするのみに留まっている。自分はひたすら高校数学の問題集を解いていた。他の二人はhackerrankの問題を解いたり朝lintをしたりしていたようだ。参加者も自分を含めて3人しかない。いつ無くなるかも分からない。人が増えればなにかテーマを決めてLTをする時間を取ってもいいかもしれない。
仕事以外のことをする時間を取ることが今の自分には必要だと感じる。仕事だけをしていると人生が不安になる。今後何をして生きていけばいいのか、もはや分からなくなりつつもあるのだが、仕事だけではなく何か一心不乱に取り組めるものがあると救われる気がしている。今の自分にとってそれがCSだったり機械学習だったり数学だったりギターだったりする。