あえて一度距離を置くことで、見えてくるものもある
スポーツの世界などでは、数日練習を休むとリカバリーに2・3週間かかると言われたりしています。それくらい反復練習が重要だということなのでしょう。
ただ、プログラミング、特に設計やシステム・インフラのアーキテクチャなどでは、「あえて距離を置く時間」を作ってもよいのかもしれません。
一度離れたことで、視点が変わる
AWSなどでアプリケーションを開発していると、自身の情報アンテナが「今使っているサービスに関連する情報」に偏ってくることがあります。それ自体は、膨大なアップデート情報やドキュメント・ユースケースから効率的に仕事に使える情報を抽出するための重要な効率化です。しかし時に「実はもっと便利な製品が新しく出ていたこと」に気づくことが遅れることにもつながります。
あえて一度離れた視点から見ることで、「あれ、こんな製品・機能いつからあったっけ?」という気づきが生まれます。経験上ありがちなのは、「あれ、ローンチ時にはこんな機能なかったよね。これあるならこっち使ったほうがいいやん」というケース。製品ローンチ時のニュースや記事などは、好奇心から読みにいくのですが、そこで「あー、使うにはあの機能が足りないな」となった場合、その製品のアップデート情報まで追いかけることをやめてしまうことがあります。そうなるともう、欲しかった機能がサポートされても気づくことはありません。
また、他のサービスをあえて触ってみることで、「この使い方は応用できそうでは」と気づくパターンもあります。AWS Amplifyをさわったあとに、NetlifyやVercelをみてみるような感じですね。
自分の仕事に関連するものに集中するのも大事ですが、あえてあまり関係のなさそうなものに触れてみるのも、キャリアやスキルアップを考えると大事かもしれません。
関連記事
生成AIコーディング時代の認知負荷問題とフラクタルアーキテクチャによる解決策
生成AIによるコード生成が開発現場に急速に浸透する中、表面的な生産性向上の裏で深刻な問題が顕在化しています。コード品質の低下、レビューコストの増大、そして開発者自身がコードの詳細を把握できなくなるという事態が広がっていま […]
生成 AI の考えを理解するために、ADR を作成する
最近オライリーの「ソフトウェアアーキテクチャの基礎」を1章ずつですが読んでいます。その中で見かけた「アーキテクチャデシジョンレコード(ADR)」に生成 AI を開発者・アーキテクトとして迎え入れる際のヒントを感じたので、 […]
一度に書き上げず、段階的に書き進める
ブログを書く時間を作るのは、正直かなり難しいことだと思います。特に書き始めた頃は、そもそも書き上げるまでに時間がかかることも多い割に、そこから得られるものが何かの実感もあまりない状態で、「時間を作ってまでやらないとなのか […]
「イベント後」を見据えたLT登壇を考える
この記事は「LTアドベントカレンダー」2日目の記事として作成しました。 LT登壇を目的から逆算する 5分間のショートセッションのことをLT ( ライトニングトーク )とIT界隈の勉強会などでは呼称します。運営側でこの枠を […]
