Lambdaカクテル

京都在住Webエンジニアの日記です

Invite link for Scalaわいわいランド

僕もコードを書くのが遅い、なぜだ

今年入社した新人ソフトウェア開発者界隈で、先輩をも巻き込んだ創作&向上意欲のグルーヴが発生しているので、日頃同じようなストレスを感じている僕も交じるしかないと思ったので書く。

  • あらゆる職場で業務としてコードを書くエンジニアの開発速度を上げたい

masawada.hatenadiary.com

stefafafan.hatenablog.com

blog.sushi.money

自分の場合

さいきん2ヶ月のエンジニアとしての進歩をここで棚卸し。

コード書き始め遅い問題

僕がまず問題視するのはコーディングに入るまでの初動の遅さ。よくあるパターンは次のようなもの。

  1. 前日にやっていたことをまず思い出す
  2. やることを脳内に意味のある形で再構成する(デシリアライズっぽいかんじで)
  3. 作業する

これが頻繁に発生すると、どんどん切り替えに必要なコストが大きくなって本質的な時間が減る。 別々の仕事を頻繁に往復すると思い出すのが大変。できれば1つのことをやりたい。

対策として、退勤時に翌日のために残すToDoや日報の充実、常時開いているタブを減らすなどを行ったところ、それなりに効果があった。

コードの構造把握していない問題

入社から2ヶ月が経過したので住処の近所の道や店は覚えたものの、肝心のコードも同じ状況で、よく通る道もあれば、通らない道もある。 よく使う箇所はよく覚えているが、一度しか使っていない部分は曖昧にしか覚えていないし、そもそもこの部品は何に寄与しているのか?という程度の理解度しかもっていない箇所が散在している。

また別の切り口としては、プログラム自体のアーキテクチャがよく分かっていないので自分が今何をしているのかよく分かっていない、という問題がある。初めて高速道路でインターチェンジに乗った人みたいなかんじで、よくわからないけどカーナビに従っているみたいな感じ。 これはもう慣れるしかなくて、慣れてから「なるほど、そういうことだったのか」となるのが一般的なあり方だと思う。

ただもう一歩考えを推し進めると、慣れながら基礎知識を別途学習するアプローチがいいのかなと思った。 イメージとしては、山を挟んで互いにトンネルを掘っているようなかんじ。片側は計算量理論やドメイン駆動設計みたいな基礎理論で、もう片側は実際に使っているコードの知識や、モナドでシュッと処理をキメるといった実践的な知識。 そのうち掘った穴がつながって、相乗効果が起きて爆発的に成長してお得になるはずという期待をもっている。

その一環として、情報系の定番教科書みたいな本を会社から借りて読むことにしている。

ハマり問題

自分が死んだことが分からないまま幽霊になったみたいな話では、自分が死んだことを受け入れるとその幽霊は消えてしまうことが多い。

プログラミングをしていても同じで、自分がハマっていることに気付かないでいると、そのまま思考が止まって時間が過ぎるという現象がよく起こる。 自分では生産的に問題を解決しようと奮闘しているように思っているのだけれど、基本的に自分の思考ほどアテにならないものはなくて、そういうときはただ悩んでいるだけ、という悲劇がまことに多い。

そういうわけで、僕は考えはじめてから15分くらい止まっていたら機械的にメンターの先輩に相談することにしている。 15分つまっているということは客観的にハマっているといえるので、その時点でメンターや人を呼ぶことで割かれるリソースと悩むことで浪費されるリソースとを天秤にかけたほうがよい。要は損切りですね。

結果的に生産力は増しているようなので、新人は初期投資だと思ってガンガン質問するとよいと思う。

一挙一投足の手間問題

gitのブランチ名を入力したり、変更したファイルを一気にステージングしたり、定番のコミットメッセージでコミットするような処理は、日常的に頻出するが、それに手間が取られているときがあった。 当然、よくある手順はできるだけ素早く簡略して行うべきと思う。

実際に実践したことは、日常的にやっている手順を観察して「この工程にはショートカットがあるのではないか」と気付く、というサイクルの回転だ。historyコマンドを使えば頻出するコマンドは統計的に割り出せるし、IDEやtmux、emacsなどの「ちゃんとしたソフトウェア」では、我々がよく行う作業には必ずといってもいいくらいに既にそのためのショートカットキーが用意されている。どんどん作業はカッコで括り出して、簡単化していきたい。 「おっ、この作業前にもやった!」みたいな気付きに対しては、常にアンテナを立てておくのがよいと思う。

眠い問題

よくある一日。

  • 朝: 当然眠い
  • 昼: ごはんで眠い
  • 夕方: 血圧下がって眠い

プログラミングというかソフトウェア開発の全般において眠気はあまりに重大で、眠いとそれだけで何もできなくなる。頭が働かん。

職人は道具を大事にする。優れたエンジニアはハードウェアや椅子にこだわるけど、そもそも最も繊細なハードウェアは自分の身体ではないか。 実際すぐにイライラしたりお腹が痛くなったりするから、これをうまくコントロールしたい。

とはいえ常にエンジンが全力で稼動している、絶好調の状態を維持するにはそれなりの手間がかかるので、まずは「ちゃんと夜は寝て朝は起きて適度に運動する」みたいな、ふつうすぎる目標を立てている。

勝手に集中力が続く!!みたいなことはなくて、調子がいいときはそれなりの理由があるはず。

コードで考えちゃう問題

何かやらないといけないときに、とにかくまずコード書く、みたいな愚策をやってしまうクセがある。段取り八分という言葉もあるし、手を出したらもう止まれないので、改善したいと思っていた。

具体的な改善案としてやったのは、手元にメモ帳を置いて図がすぐに描けるようにしたことと、社内のGHEのIssueやプルリクにガッツリ思考の軌跡を残すことで「やらなければならないこと」を明確にするということ。 やることがわかれば後は実行するだけになるので気持ちが楽だし、思わぬ変更があってもそのリストを修正することで、どういった影響が出るのかを「見る」ことができる。また、すぐに図を描けることは思考のゆとりを広げるので、リストの操作が楽になる。

まずやることを明確にしてから、あとはそれだけを考えるというスタイルを続けているが、これが一番役立っているように感じる。

ほかの仲間や先輩のエントリを見て

id:masawadaくんがSlackで時間が減るといってて、常時なんかが表示されているのは確かによくないと感じた。わかるよ・・・

Slack見がち ついつい見がち 他人の分報を眺めると時間が飛ぶ 普段閉じていればこんなことにはならない Slackが悪いのではなくて,ツールを使えていない自分が悪い

なぜコードが書けないのか,あるいは仕事が遅いのか - masawadaの日記

id:stefafafanくんも同様の意見で、具体的な施策を考えていてよいとおもう。

これは私もある。とりあえず #general チャンネルや #engineer チャンネル、あとは自分のチームに関連するチャンネルのみStarして、他は未読あっても暇になったときだけみるようにしてる、けどそれでもみすぎかもしれない。

なぜ私もコード書くのに時間かかるのか - すてにゃんのガチ勢日記

先輩たるid:hitode909くんさんはslackをよく消しているみたいで、確かにたいていのチャットは自分とは関係無いし、本当に用事があるならメンション来るはずだから消すのも悪くないと思う。

あと,集中してコード書きたかったときはSlack閉じて,スマホに通知が来たら開いて返事する,とかしていた

Slack見がち問題 - hitode909の日記

番外

インターン

株式会社はてなでは、こういった話もできるエンジニアを募集しています。もうすぐインターンがあるのですが、ソフトウェア開発を視野に入れている学生諸君は参加しませんか〜。(ダイレクトマーケティング)

hatenacorp.jp

★記事をRTしてもらえると喜びます
Webアプリケーション開発関連の記事を投稿しています.読者になってみませんか?