はじめに

前回の続きとなります。
stylelintのエラー解決のステップにあたり、
たったひとつのことで、必要以上の時間をかけてしまいました。

この記事は反省備忘録です。

前回

エラー発生にあたり、解決ステップを書いた記事となります。
要約します。

修正には何十分もかかりました。
時間をかけていた要素を抜粋します。

ググりすぎ
実際には、検索を行った後、複数のページを閲覧しています。
あれも違う、これも違う、となり、再度、検索文字列を変えての検索を行っているのです。検索文字列はエラーメッセージだったので、文字列が完全一致の記事があってもよさそうですが、ありませんでした。
なかったのにもかかわらず、一生ネットサーフィンしてました。

公式ドキュメントを調べた経緯
「検索にひっかからなかったなー。じゃあ公式ドキュメント見るかー」
という経緯ではなく、
調べていたら偶然「The "string-quotes" rule is deprecated」という文字列があり、そこではじめて「Unknown rulesって怒られてるんだから、普通に非推奨とか廃止されている可能性あるな」と思いました。そこでようやく公式ドキュメントを見るという発想になりました。

思えば、なぜ最初から公式ドキュメントを参照しなかったのでしょうか？

エラーメッセージには「Unknown rule string-quotes.Stylelint(string-quotes)」と書いてあったのだから、廃止されていたりするドキュメントを探せば良さそうです。

おそらく、無意識に解決ステップを楽にしたかったのでしょう。調べて、完全一致のエラー解決記事が出ればそれを参照すればいいのだから。
ここまでは、おそらくですがそこまで問題はない気がします。
一致する記事があれば、それと公式ドキュメントを比較し、問題なければ適用すればいいですしね。

一致する記事がなければどうすればいいのでしょうか？
ここからが問題です。
私はググり続けました。
この時点で思考は
「なぜこのエラーが起きているか」
ではなく
「エラーを直さなきゃ」
にすり替わってしまっていた気がします。

「なぜこのエラーが起きているか」を考えていれば、
エラーメッセージから、何を参照すべきかが明確になるはずです。

それが「エラーを直さなきゃ」思考になってしまったせいで、次に行うべきアクションが曖昧になり、結果本能的に身についている「ググる」を選択してしまった気がします。

最近流行しているエンジニア読み物で、
「世界一流エンジニアの思考法」という書籍があります。
牛尾剛さんという方が書いている本です。

その中には「生産性の高さ」として

が挙げられていました。

試行錯誤は悪である
今回私は試行錯誤してエラーを修正したわけではなかったので、完全に一致するわけではありません。
しかし、「試行錯誤は悪である」ことで紹介されていた、
「仮説　→　仮説の証明」をしていればもっと早く修正ができたと感じました。

理解することに時間をかける
もう一つ思ったことは、
仮に私が同一事象のエラー解決記事を発見したとして、果たして、そこから公式ドキュメントも参照したのでしょうか？ということです。

私を含め、多くのよわよわエンジニアの皆さんは、エラー解決を、記事のとおりそのままやってしまう、ということがあります。
でもそれは今回のケースのみ解決できるだけ（もしかしたら本当は解決できていないかもしれない）で、次に似たようなケースでエラーが出たとしたらもうダメです。
この思考の修正が「公式ドキュメントをよく見る」につながりそうですし、加えて「理解することに時間をかける」にもつながりそうです。
今回のケースでは、公式ドキュメントを見ることで「string-quotes」が廃止されていることを知り、しかも実はその他項目も、何十種類か廃止されていたｋとも知れたのです。
このような解決策をとることで「理解」の一要素「応用できる」が満たせる感じがしそうです。

エラーを修正していて、何十分もかかってしまう自分が嫌になると同時に、ハッとすることもありました。

エンジニアという職業を楽しめるようになるため、少しでもいいエンジニアになるために、少しずつ自分の思考を改善しようと思ったいいきっかけとなりました。