楽したいソフトウェアエンジニア

週一でなんか書きたい

今年の四半期が終わった

もう4月ですね

今年の記事を振り返ってみると大体仕事の進め方のようなことを気にしているようでした。あとは学習をコツコツする、みたいなことですね。

具体的な技術よりもそっちの方が気になっていたんですかね。あんまり自覚はなかったですが。

メンタル(?)的なことばかり考えてもなあ、という気がするので来週はこれまでのRustの学習の進捗でも振り返ってみようかと思います。

ちょうど The Rust Programing Language も切りがいいところですし。

ああすれば良かった?とか考えがち

なかなか話が具体化せずになあなあで時間が過ぎてしまったプロジェクトがありました。

以前から中々話が見えないな、でも誰か見えてんだろうな、と思っていたらみんな見えてなかった。という事象でした。

で、もっと早く自分がなんかしてたら良かったのかな?と考えてしまっていたのですがそれって精神衛生上あまり良くないなと思い直しました。

別になんとかできなくても良い

まあできた方がいいんですけどあまり気にしすぎるのは嫌ですね。

とりあえず不安とかぼんやり気になっていることはTodo(やるとは言ってない)にでも入れておくくらいはするといいかな、とは思いますけど解消は必ずしも自分ができなくてもいい、の精神でいたいなと思いました。

達人プログラマーに書いてあるアジリティの本質

のプラクティスの1段階目が「自らの現在地点を見つけ出す」なのでその習慣はつけてみようかなと思いました。その先の解決とかは、、、また別の話で一旦そこで区切るとメンタルが楽になるかもなと思いました。

コードリーディングの練習

プログラマー脳」を読んだ影響で先週からコードリーディングの練習をしようとしているんですが、まあ忘れちゃいますね。

仕事の始めとかレビューの時とかに練習してみようと思っているんですが気づいたらいつも通り進めてしまっています。

まずは習慣化ですね。

ところでこういう「正解」がない演習ってやりづらいなぁと思って避けてきたことが多いんですが、どんな結果であれ自分で考えて答えを出すという行為は大事なのかもしれない、と「プログラマー脳」の演習をやっていて思いました。

プログラマー脳が面白い

https://www.shuwasystem.co.jp/smp/book/9784798068534.html

プログラマー脳を読み始めたのですが、これが面白いです。

まだ前半終わってないくらいですが、プログラマーがコードを読む時に脳にどのように負荷がかかっているかなど、普段なんとなく感じていたことがちゃんと説明されてる感じがします。

もっとコードを読もう

書籍の中で「プログラマーはコードを書く練習はするが読む練習はしない」と書いてあってなるほど、と思いました。

よくコードを書く時間より読む時間のほうが多い、と言われますが、それなのに読む練習をしないというのは耳が痛いと思いました。

また、読みやすいコードを書くように考えるのに読むのが下手というのはおかしいというか、それで読みやすいコードが書けるわけないかもと思いました。

というわけでまずは読むためのコードを探そうと思います。書籍の中で読む練習の方法が色々書いてあるので実践してみたいと思います。

サボり気味

危うく2週間飛ばすところでした。。。

今週は旅行に行っていたので少し分かるのですが、先週はなんでだっけ。。。

ソシャゲに時間使いすぎ問題

で、この2週間何があったかな、と考えていたら1番はこれな気がします。
最近ソシャゲに使う時間を減らしたくてプレー時間は少し減ったと思うのですが、
攻略サイトとか見てる時間を考えると相変わらず多いなあ、と。

頑張ってやめよう!というやり方だとなんだか効果もイマイチなことが多いので
別の角度から考えてみたいと思います。

費用対効果を考える

ここでいう費用は時間です。で、効果はそのままで結果として得られるものですね。

自分の場合はなるべくアイテムを使わないで攻略できないかな、と考えて
攻略サイトとかをみてしまうことが多いのでそうすると効果はアイテムの消費を抑える、
費用は何回か攻略サイトを見る時間(15分*4、など)になるわけです。

で、結構ケチっていたアイテム自体はまた10分とかで取れるものだとすると
大分損失の方が大きい!となって素直にアイテムで殴る、みたいな方向に行けば時間は節約できるな、と。

とりあえずコストを測る

まずはコストである時間をどれくらい消費しているかを記録したいと思います。

プレー時間はスマホが測ってくれてるので攻略サイトを見てる時間ですね。
これもサイト毎に記録を見れれば早いのですが、、、

目標は「効果の割にすごいコストがかかっていてゲンナリしてソシャゲに使う時間が減る」です

目標は達成できなくても良い

先週に続いて「私達はどう学んでいるのか」を読んでいたのですが、読んで色々考えていたら目標は達成することに力を注ぐよりもっと考えることがあるのでは?と思いました。

現状との差分

書籍の中に「現状とあるべき姿との差分を埋めるために問題を創発する」というような箇所があったと思います。

あるべき姿=目標、と考えると目標は達成するよりも解決するべき問題を作るために考えるべきものなのかもしれないと思いました。

目標には近づければ良い

目標をそれに近づくための問題を作る手段と考えると色々余計なことを考えなくてよくなりそうだと思います。

中長期目標を考えると、途中でその目標が陳腐化してしまったり、別のことの重要度が上がったりすることをしょうがないと思えるようになります。

それまで解決した課題は自分の役に立っているはずですし(この部分は日々検証が必要そうですが)、目標が変わったらまた解くべき問題を考えればいいので。

今週末は読んでいる本について書く

今週から「私たちはどう学んでいるのか」という本を読んでいるのですが、スキルアップについて思うところがありました。

https://www.chikumashobo.co.jp/product/9784480684318/

ここまで読んだ内容

大雑把にいうと下記の通りだと自分は認知しました

  • 能力というのは特定の文脈のもとで発揮されたりされなかったりする不安定なもの
  • 知識というのは有用に使えるのもであり、そうでなければ単に情報を覚えただけ
  • スキルというのは最初はレベルアップ度合いが大きくてどんどん小さくなる。また、ずっと上り調子ではなくて下る時もある。ただしそれは次のステップアップの準備である

自分は、能力はいつも発揮できて、覚えれば知識となり、スキルアップは取り組んでいれば常に上り調子だと考えていたんだな、と思いました。

そしてその考えはなんだか無駄に労力を使いそうだなと思いました。

いまやってるRustの勉強は?

今だとRustBookを読んでいるだけなので、単に情報を詰め込んでいるだけになってますね。

情報を有用にするためには…なんか作る時に、ですかね。

RustBookを読むのは続けようと思いますが、どんなことが書いてあるかの把握くらいにしておこうかなと思いました。

並行してなんか作るものを考えたいと思います。作る時にRustBookを効率よく参照できるようになっていると良いのかなと思います。

作るもの?

作業用の何かとかだと分かりやすいんですが…

とりあえず普段の自分を俯瞰して繰り返しやっていることとかないか、それをプログラミングできないか、考えられると良いですね。

追記

スキルについて重要なことが認識できていなかった気がします。

一時的な後退はなにか新しいやり方を取り入れたために前後の繋ぎが悪くなってしまうことによる、という考え方です。

つまり、どこかを改良したとしてもすぐに全体が良くなるわけではなく、むしろ一時的には全体的に悪くなったように見えるかもしれない、ということです。

そこを解消するにも、やはり練習したによって前後の繋ぎを作り直す(?)必要があるかもしれません。

ゲームみたいに単純にパワーアップ!みたいなことはない。ということかもしれません…