はじめに

最近になって業界未経験の新人さんと接する機会が増えました。
彼らの様子を見ているとうまくいかないのは自分も昔そうだったなぁ😢と思うことや、それよりもっともっとポンコツだったなぁと思うなど、、
気づけばエンジニア歴も10年近くになってしまう🥶ので、しっかりサポートできるように自分の考えをまとめておこうと思います。

自分のやろうと思ってることを伝えよう

仕事がはじまりますと、まず上長からこれこれこういう仕事をやってほしい、とタスクが割り振られると思います。
その際、自分なりに要求を解釈して対応方法を考え、さあやるぞ！…と始める前に少し立ち止まり、上長に自分の対応方針を伝えるといいかもしれません。

私の経験上もほかの方を見ていてもですが、仕事をどんどん進めてしまって大分形になったなぁというところで見せたところ、
「いや、こっちのやり方よりこう進めてほしかったな、、」
ということは往々にしてあります（n敗orz）

経験の浅いうちは先の見通しができず、こういう方法でいけるだろうと思ったことが迷走していたり途中で壁にぶち当たったりするものです。（私もいまだに見知らぬ技術にふれたときはやってしまいます、、）

一生懸命つくった成果物が水の泡となって消えてしまう前に
「こういう風に進めようと思うのですが、、」と一度考えを伝えてみると早いうちに方向を修正してダメージを最小限に抑えられるのでおススメです！
上長としてもあなたが最短時間で納得のいく成果物を出してくれるようになるので、トータルでの満足度は高くなってきっとご機嫌で過ごしてくれるはずです。

（…というようなことを以下の本から学んだ覚えがあります。おススメ）
職場の問題地図 ~「で、どこから変える?」残業だらけ・休めない働き方

行き詰ったら相談しよう

作業をしていると行き詰って「どうやって解決したらいいんや、、」となることはありませんか？ありますよね？
そんなとき、ついつい何とか事態を打開しようと頑張って気づけばn時間、、☠️
しかもそんなことが2回や3回では済まないと思います。済むわけがない😢

もちろん自分で粘り強く問題解決に取り組むことは自分の糧となるのですが、
残念ながら仕事には時間の制約というものがあり、のんびり自分のペースで、、というわけにはいきません😭

上長に声をかけて時間を奪うことに遠慮してしまう気持ちもわかりますが、
上長からしてみればパッと解決できる問題にn時間かけてしまうのも辛いところです。
勇気を出して相談してみましょう。

エンジニア界隈では「15分ルール」と呼ばれる15分考えてみても無理なら人に聞きましょう、という有名なルールがあります。
これはちょっと短すぎるという意見も聞くところではありますが、最初の一度目はこのルールに従い、相談後に上長に独力でがんばるべきか早めに聞いたほうがよいかのお伺いを立てるのがよいと思います。
（これも相談ですね、、相談大事）

ちなみに相談するときは以下の順序で話せると伝わりやすいかなと思います。
いきなり2から話してしまうこと、あると思います。

何に取り組んでいたのか、何をやろうとしていたのか
起きている事柄について
試したこと

しっかり休もう

責任感をもって仕事に取り組むあまり、寝不足はては徹夜で仕事をしちゃったりしていませんか？
当然ですが寝不足や疲れが残っている状況だと人間は普段よりもパフォーマンスが落ちてしまいます。
そうなると当然成果物への質にも影響が出てしまい、疲れた状態で書いたコードを後日読み直すとなんじゃこりゃ状態になることもしばしば、、

また、プログラマーの業務の中でプログラムを書くこと以外で大事なこととして人とのコミュニケーション（質問、設計やコードの説明など）があります。
自分の体感としても人の様子を見ていても感じますが、寝不足状態で質問したり説明をしたりすると、残念ながらトンチンカンな具合になってしまうことがしばしば、、

一生懸命仕事をするのは大事なことですが、生き急ぐ必要はありません。
サステナブルなエンジニアライフを送るためにもしっかり休養を取るようにしましょう🛌💤

デバッガを使おう

いきなり毛色が変わって実務的なところです。
初心者さんを見ているとデバッガの使い方がわからないからか、プログラムをわざわざデバッグなしで実行していることが多々見受けられます。

デバッガでブレークポイントを張るとデバッグの生産性がぶちあがるのでまずブレークポイントの張り方を学びましょう。
（デバッガの使い方は世の中に素晴らしい記事がありまくるのでここでは割愛、、）

デバッグのコツとしてはエラーが起きてそうな個所の前後にブレークポイントを張って、確認したい値の内容を比較してみるとよいでしょう。
nullじゃないと思っていた変数になんかnullが入っとる、、ということは割とよくあります🥶
ある程度、問題が起きてそうなコードが絞り込めたらさらに範囲を絞ってブレークポイントを設定して確認して、、を繰り返しましょう。

なかにはデバッガがなぜかうまく機能しないという場面もあると思います（typescriptとか、、

そんな場合は代わりにログを使うのがよいですね！
ブレークポイントよりは扱いづらいですが、それでもうまく使えるのと使えないのとでは雲泥の差が出ます。

終わりに

気づけば10年近くエンジニアをしている立場として、新人さんにはなるべく自己効力感を保てる範囲（いわゆるラーニングゾーン）で仕事をしてもらえるようにしたいな、と感じます。
自身が新人だった頃には右も左もわからずビクビクしてたことを思い、目の前の人にはそんな思いをせず伸び伸びと働いてほしいですね、、
在りし日の自分を供養する思いで新人さんには優しくしたいです。

~~ゆくゆくは私が困ったとき助けてほしいし🤤~~

新人さんに伝えたいことの言語化