在宅になった2020年からいままでバランスボールで仕事してきて、まだぜんぜんいけるんだけれどたまに椅子に座ってだらっと仕事したいときはある。
— シャングリラ (@tomohi_ro) 2022年12月15日
椅子を買いたいと思って早幾年。
尊敬する元同僚はものすごくのけぞって仕事をしていて、めっちゃかっこいいと思っていた。 真似して僕ものけぞって仕事をしていたりしたのだけれど、在宅になってからはバランスボールなので出来ていない。 むしろ前屈みになってしまっているので肩がこりやすいし目にも悪い。
ただし、椅子があるとだらっとしてしまって運動にならないし今よりもさらに太りそう。 悩ましい。
チームの昼会で日替わりでLTをしていて、今日は自分の番だったのでコーヒーのハンドドリップについて話した。 話したといってもそんなたいしたことは言えないので一般的な話と自分がどうしてるか見たいな感じ。
その中でそう言えば最近使っているドリッパーをブログに書いてなかったことに気付いたのでさらっと触れておく。
ちょっと前から ORIGAMI の Dripper Air を使っています。
まずいいのがめちゃくちゃ軽くて頑丈というところで、毎日使うドリッパーとしては雑に扱っても大丈夫なのですごく楽。 そして見た目がいいのでテンションも上がって良い感じです。書いていて別の色も欲しくなってきてしまった。。。
毎日使う道具、見た目がいいとやる気が出るのでなんか良いやつを買いましょう。
文章を書くのが苦手、もっと一般化すると人に何かを伝えるのが苦手で、面倒だと感じてしまう。 仕事だと伝わらない方が面倒なことを学んでいるので伝える努力をしているが苦手なことに変わりは無い。
今の会社はドキュメント文化がしっかりしていて、リモートワークでもうまくいっている理由のひとつなのだけれど、つまり自分も文章を書く必要がある。 すでに文書を書く機会が何度もあったのですが、毎回苦労しながら書いていて、苦手意識から着手までに時間がかかっていたりする。
こんなことではいけないのでまずは文章を書くことに対する苦手意識をなくしたい。 そのために毎日ブログを書くのはどうかということで最近は毎日書いている。
気張ってなんかテーマを考えて書いたりしているのだけれど、多分続かないので雑な日記とかを書くようにしていくつもりです。 (昔は毎日日記書いていたのだけれどいつの間にか書かなくなってしまったので復活)
界隈ではよくソフトウェアエンジニアのことをエンジニアと略して怒られが発生している。 ソフトウェアエンジニアという狭いくくりをさもエンジニアの全てかのように言うのだからそれは怒られる。
いっぽうでソフトウェアエンジニアがエンジニアであることは間違いがない。 エンジニア(＝技術者)の仕事は専門の技術を持ってそれを実践することである。
めちゃくちゃ曲解すると技術を実践するとは何らかの問題を解決することと捉えられそう。 そして問題を解決するためには見える形で専門の技術を披露するだけではないと思う。
何が言いたいかというとソフトウェアエンジニアはコードを書く仕事だと思われがちだけれど、一行もコードを書かずに問題を解決出来ればそれが一番なのではないかということ。 コードを書く前に解決出来ることはたくあんありそうだし、それが出来るのがより力のあるソフトウェアエンジニアなのではないか。 それが出来なくても出来るだけシンプルで分かり易い小規模のコードで解決出来た方が良いはずではないかと思うのです。
なんでこんなことを書いているかというと、どうにも解決策が思い浮かばなくてどんどん複雑な設計になってドツボにハマっているので自戒のために書き下したという次第です。
現代においてはソフトウェアの開発はチーム開発となることが多い。 つまりコミュニケーションが大切になる。 ソフトウェアエンジニアの各人はコミュニケーションについても意識的に気を付けていたり、場合によってはそれについて学んでいたりする人もいると思う。
しかしながらプルリクエストでのやり取りにおいては端的で目的だけを優先したコミュニケーションをする人が多い気がする。 たしかに間違っているところや、読みにくいところを修正して、バグの発生防いだり、メンテナンス性の確保、ひいては将来的に開発速度を保つための手段なのでそれでも間違っていないのかもしれない。
具体的にはレビュワーとしてはたんたんと指摘だけをしたり、問題なかったら無言で Approve だけしたり。 レビューとしても何の説明もなくコードだけぶん投げたり、コメントに特に返信せずに修正だけを入れる、そして無言でマージしたり。
ソフトウェアの健全性は保たれるので合理的なのかもしれない。 けどチームの健全性は保たれるのだろうか。 保たれる場合もありそう。それはチームの特性によるのでなんとも言えない。 すくなくとも自分なら怖くて泣いちゃう。
いっけん無駄のように思われるかもしれないけど、ちょっとだけコミュニケーションを意識出来ると良いのになと思ったりします。 言葉遣いを普段のコミュニケーションと同じようにしたり、コードの良いところとか興味があるところに雑談でコメントしてみたり。 アプルーブやマージのときに無言をやめてみるとか。
実のところは害もあると思っている。 例えばコメントに返信せずに修正するケース。 レビュイーは本当にレビュワーの意図を理解出来ているだろうか。 その修正方針はレビュワーの想定とあっているだろうか。 ふつうに仕事の進め方としてすり合わせてからやった方が手戻りが少なくて有益だと僕は思うのです。 ちょっとだけ時間を使って、こういう風に直しますねとか書くだけでだいぶ時間の節約になるんじゃないかと。
別の話題としてプルリクエストのコメント数は少ない方がいいという向きがある。 これは書いたコードの対して指摘だけが入るという前提を置いている気がしていて、たしかにそれだとコメントは少ない方がよい。 しかし、コミュニケーションの場なのだとする僕の立場からすると、コメントは多ければ多い方がいい。 チームがコードについて共同所有の意識を持てている、言い換えると興味を持てているということでもあって、そしてコミュニケーションは活発な方がチーム開発にとっては断然良い。
自分が常に意識出来ているかというとそうでもないのだけれど、プルリクエストでのやり取りもコミュニケーションの一環なんだという意識を持てると気持ちよくチーム開発が出来るのではないかなと思います。
なかなかgo初心者から抜け出せない。中級に行くにはどうすればいいんや。
— ラムネ (@tomohi_ro) 2022年12月9日
最近は仕事で Go を書いているのだけれど、初級から抜け出せない感がずっと続いている。 ツイートでは初心者って書いてしまったけど、初心者は抜けた感じがあって普段はあんまり困らずに書けている。
けれど、例えばちょっと難しいことをしようとしたときに手間取ってしまったり、なぜこうなっているのかと疑問に思ったときにパッと調べられない。 文法とかの知識はあってそれを使えるのだけれど、イディオムとかの Go を書くうえでの常識があんまり分かっていない。それの調べ方が分かってない。 問題の切り分けが出来てないのでなんか解決せずにもやったままになってしまう。
Goのsliceとかmap、加減が分からないので必ず `len` か `cap` を指定しているのですが、何か基準があったりするんですか。
— ラムネ (@tomohi_ro) 2022年12月9日
例えばこういうのがどう調べていいのか分からなかったりして困っている。 Rubyだとなんか適当に調べて良い感じを見つけられる自信があるのでやっぱりそこにはたどり着けていない。
中級というのは自分で目的の情報にたどり着けることだなって書いていて思った。
なんかどうすればいいかは前に書いていたとおり地道にやっていくといいだけなのだけれど、出来てないのは怠慢なのだと思う。 最初の分かっていることと分かっていないことの切り分けをやってないので永遠に足踏みをしている。 こんなブログを書いている時間があったらそれをやれば良さそう。
入門したから7年も経っているので絶望しそうになるけどまあやっていこう。
