コーディング前に何を考えていますか？

考えが浅いと評価

具体的にどういった点が不足していると言われているのでしょうか？まずはそこの言語化が必要だと思います。
そこを伝えられていないのだとすると、評価する側にも課題があるような気がします。具体的な課題として言語化できないのであれば、「評価」とは言えないのではないでしょうか。

例えば、あなたから見て「考えが浅くない人」はどういった点が違うでしょうか？自分の周りにいる人の仕事を観察することで、不足ている点がわかるかもしれません。

どのようなことを考えているのでしょうか？

まず第一に「何を解決したいのか」という点を考えます。そこを掘り下げずに言われたことを実行すると、的外れな回答になったりします。目的をよく考えることで解決へのアプローチがいろいろと検討できます。そもそもコードを書く必要は無いかもしれません。

コードを書く形でのアプローチが必要だと分かったなら、解決のために必要な要素を考えていきます。
合わせて保守性やセキュリティなどの非機能要件についても考えていきます。
その他にはスケジュールであったり、プロジェクトやチームの状況も考えます。

またどの段階まで考えることができたらコードを書き始めているのでしょうか？

ぼんやりと必要な要素が見えてきたら書き始めます。
事前の設計も重要ですが、同時に机上の空論でもあります。コードを書かなければ見えてこないものもあるので、「準備を完璧にする」のような意識はありません。

質問に対して回答してみましたが参考になるでしょうか？
最初にも言いましたが、まずは具体的な課題を明らかにすることが必要だと思います。それは「言語や設計に関する知識」かもしれませんし、「非機能要件の考慮」かもしれません。あるいは「コードを書く目的」かもしれません。思い当たるものがあれば、記載されるのが良いでしょう。そうすればより具体的な回答が得られると思いますよ。

新規作成ではなく、不具合修正や機能追加が中心なんですね。
その時は
「既存のプログラムの設計思想を理解する。」
から入りますね。
複数人の手が入っているときによくあるのが元の思想をぶち壊す改造ですが、なるべくノイズを排して元の思想を汲み取りましょう。

既存の思想と使えそうな部品を把握したら、自分が入れようとする修正をどうするのか考えます。
・元の思想にあっていること
・既存の処理に影響を(なるべく)与えない
・今後の修正などに利用できる処理を作る際は部品として整備しておく
あたりが、改造や不具合修正のときに特に考慮してる点ですね。

設計は「シンプルに」を意識して、一番無駄のない形にまで絞り込めたと思ったらコードを書き始めています。

試験まで意識した設計や、仕様変更も考慮する設計など、全工程通して楽できるように考えていくと、コーデング前にも色々仕込むことができるようになりますよ。