テキストやカリキュラムを見ながら打ち込んだ、そのコマンドの意味を正しく理解していますか？

今日言いたいのはこれです。
プログラマーになりたいなら、間違っても動くコードを教えてくれなんて言ったらダメです。
コピペで貼り付けたそのコードは、あるいは写経したコマンドはいま本当に動かす必要があるコードなのか、しっかり分析しましょう。
関数の振る舞いやコマンドの意味、場合によってはライフサイクルを知る必要があります。
Web系のプログラマー（フロントエンド・バックエンド問わず）ならブラウザの挙動や仕様まで事細かに把握しなければなりません。

間違いだらけのプログラムのイメージ

スクール生に向けて書いているので、ここでは「ブラウザで表示されること」をゴールと設定します。
Webサーバー（apacheやらnginxやら）立ち上げて英語書いて保存して表示されたら次へ進む、なんて事をやっていてもスクールに通う意味はありません。
テキストに書いてある文字はどういう意味なのかを考え、試行錯誤する必要があります。
特に、ブラウザに表示される事を確認するのがゴールなので、JavaなりPHPなりRubyで書いたそのスクリプトが、どうやってブラウザで表示されるhtmlになったのかぐらいは知っておかないとマズいです。
この作業はフロントエンドで発生する事が多いですが、スクール生の間では

• HTML: テキストファイルに書いたものが表示される
• JavaなりPHPなりRuby: 表示命令(echo なりprint なり)に書いたものが表示される

というような認識をされているような気がしてなりません。

HTMLについては極端な話、その理解でもいいですがプログラミング言語やスクリプトについてはその理解ではダメです。
そもそも間違っています。
確かにecho なりでブラウザに出力できますが、ブラウザがecho を理解しているわけではありません。
各言語がコンパイル時にecho の内容をブラウザに理解できるようにしている、というのが正しい考え方です。

初心者あるある：プログラムが何をやっているか分からない

たとえば、

hoge = 1;
print hoge;
print hoge + 1;
hoge += 1;
print hoge;

みたいな内容があったとします。
print じゃなくてecho だったり、print(hoge) だったり書き方は色々ありますが、ここでは出力を意味します。

これが何をやっているか分かりますか？という事です。
フローチャートを使って図にしました。

このように、プログラムの処理を日本語で書いて意味を理解する事が大事です。
どこもecho とかprint みたいな簡単なものを言語化しますが、たとえばif やfor でも考え方は一緒です。
if とwhile やswitch は（フローチャートで書くと）同じだと理解しますし、for とdo-while も同じものです。
ちょっとレベルを上げると、foreach やmap なんかもここに該当しますが、このレベルになったらフローチャートなんて面倒くさくていちいち書かないようになります。
このように、ワケのわからない文字の羅列を図形に直して理解する事が肝要です。

構文が理解できない

引数が一つしかない場合はいいのですが、引数が複数存在するケースがあります（とても多いです）
SQLなんかは引数まみれです。

create database [db_name]  # [db_name]という名前でデータベースを作る
use [db_name]  # [db_name]というデータベースを使う。データベースがなければエラーになる

この辺りはまだいいです。
問題はcreate table もセットで教える事が多く、これが混乱の元になってしまっている事です。

create table [table_name]  # [table_name]という名前でテーブルを作る
(
  id int,  # idという項目をint属性で作る
  key varchar,  # keyという項目をvarchar属性で作る
   varchar  # valueという項目
)

大体の場合、英語を読めない人を考慮していない のでこういう問題が起こるわけですが、英語が読めないと技術・品質の高いプログラムは書けない ので、スクールにいる内から英語を読む癖をつけておく必要があります。
また、SQLではじめて引数を２つ以上入力する場合などは苦手意識ができやすいですが、SQLの問題ではないのでご注意ください。

何をやっているか分からないけど動いた

これが一番たちが悪いです。
とりあえず動いたからもういいや、となるタイミングがどこかで必ずあります。
苦手意識が出来てしまったのでもうやりたくない、という気持ちは分かりますがスクールのカリキュラムの単元として取り上げられる事なので、実務でも使う機会は多くなります。
その度に苦手意識が出てきてしまうと工数増を招いてしまうため、スクールにいるうちに苦手意識を解消しておいた方がいいです。
苦手なことほど、理解した後の自信につながります。

図形で理解するプログラミングシステム

要するにフローチャートの事ですが、システム設計とかその辺りの話になると今度はシステム間連携という、もっとよくわからない規模の話をされます。
データをどこに送って、どこに保存して、いつから動き始めるとか複雑な話がいっぱい出てくるんです。
参考：このブログが全自動・一部半自動で動いている仕組みを解説

スクールプログラミングのように書けば正解のものから、動いているが結果や内容が正しいか分からない世界に突入します。
主にデータサイエンティストと呼ばれる人たちは、このデータが正しいことあるいは正しそうな根拠を探すという事をやり始めます。
動けば正解のプログラミングの世界は簡単だなと、内心で思っている人たちがいてもおかしくはありません（私はそう思ってました）

この人たちも、頭の中でフローをイメージして運用や試験について考えている事が多いです（私は思っています）

なぜスクールで教えてくれないのか

タイトルを読んで疑問に思った人も多いと思います。
なぜなら、フローが分かってもプログラミング言語で言うところの何が該当するのか教えるのが大変だからです。
カリキュラムにしたらすごいことになります。
また、フローが分かってもシステムは作れないからです。ただし、システムを理解する上でフローチャートは重要な役割を持っています。

システムの実装だけやれば良いプログラマーならフローチャートのような設計図は必要がない事がほとんどですが、システムの設計を考え始めるとフローチャートは必需品です。
パワーポイントで資料を作る際もよくでてきます。
ただし、パワーポイントで資料を作る現場SEを私は知らないのですが…。