色々有りますが、その中で特に「これだ」と私が思うのは、

「プログラミングでやりたい事をイメージする」事と、「そのイメージを実装する」事との乖離が大きい

という点ではないかと……。

初学者であっても、複雑で多機能なソフトウェアをイメージする事は出来ます。　しかしそれを実際に実装するとなると、とても面倒です（この点は、他の創造的な分野、たとえば絵画制作や作曲編曲、建築などにも共通している事だが）。

たとえば twitter がどんなものかをイメージするのは——つまり、何が起これば twitter はどういう挙動をするのか、である——、たとえプログラミングを学んでいなくたって、多くの方にとっては難しくは無いでしょう。
もしそれが難しかったら、こんなに多くの人が twitter を使う事は出来ないはずです。

しかしそれを実際にゼロから実装するとなると——規模を小さくしたり、機能を絞ったとしても、最低限度「twitter と呼べるもの」を実装するとなれば——、かなり多くの事柄について、たとえばデータについてだけでも、持つべきデータの種類、データ間の関係、データが変更される契機とタイミング、データの正しさの保証、それらデータの持ち方、……等々を決めてゆく必要があるわけで、データ設計だけでもかなり面倒だ、という事は、プログラミングを学び始めた方でもお分かりでしょう。

つまり、「プログラミングが難しい理由」とは、たくさんの面倒な事柄をひたすらに積み上げてゆかねば実装が出来ない、という事だと私は考えるのです。

言い方を換えるならば、実は難解な事は何ひとつ無いのだけれども、とにかく面倒過ぎるので、それが「難しい」と捉えられるのでしょう。

コンピューターという機械は、かつて人類が作り上げてきた機械の中でも、複雑な部類に入ると私は思っておりますが、その基本的な機能を実現する仕組みは、１つ１つを取って見ればきわめて単純で簡単なものです。
しかし、単純で簡単な要素を、膨大な個数組み合わせて、大量に積み重ねた結果、コンピューターは複雑な機械になっているのです。

プログラミングもそれに似ていて（※１）、目指すモノを作り上げるには、ひたすら面倒な事をやり続けなければなりません。

複雑さと難解さは必ずしも同一ではありませんが、
「複雑な物事は、その全てを正しくやろうとする事、それが難しい」のです。

※１　コンピューターにおけるソフトウェアとハードウェアは、どちらも「論理機械」であるという点では同一である。　両者は、論理機械としての動作を、ハードウェアで実装しているか、ソフトウェアで実装しているかの違いしかない。　だからこそ「ソフトウェアをハードウェアで実装して高速化」なんて事が出来るし、逆の事をやれば「仮想化」が出来るのである。

思った通りに動かないし、思ってたとの違うからでしょうね・・・

まず、エンジニアに必要な要素を考えた時、以下のようなものがあるかと思います。(もっともっとありますが本題ではないので思いついたものを…)

・専門知識の幅広さ、深さ

・インプットに必要な情報の検索力、読解力

・変化への対応力、柔軟性

・常に求められる論理的思考力、問題点解決力

・関係者とのコミュニケーション力

・尽きない興味心と探究心

・挫けない忍耐力

エンジニアという職業は、ハードスキル・ソフトスキル含めて、とにかくキャッチアップすべきインプットが多く、幅広く、深さもある。更にインプットをアウトプットに変えてモノとして完成させなければならない。そういった職業だと捉えています。プログラミングはその内の一要素に過ぎないのですが、根幹の部分でもあります。

ここから本題です。実務でもそうですが、散見されるのが「学習ハードルの高さによる挫折」です。実際、あるプログラミング初学者は「難しいプログラミング学習」に挫折し「手早く作れるノーコード」へ行き着いたようです。(これは非難ではなく、興味深い事実です)

プログラミングして行くとおおよそ次のような事象が起こると考えています。

・難しいこと、わからないことが多すぎる

・少し変えただけでエラーにつまずく、自力で解決できない

・自分が何をやってるかわからない、何がどうなってこう動くのか理解できない

・既存あるいは他人のコードが読めない、理解できない

・学習が進んだと思ったらまた別なことを学ばなければならない、結局ずっと学習が続く、並行してモノを作らなければならない

・やっとできた成果物も「不具合」 と指摘され修正しなければならない、調査にまたインプットが必要になる

・技術文書は英語。日本語も難しい。(実際は読めるだけの前提知識が不足しているため難しく感じる)

…そりゃ楽しくないですよね。(あ、私は楽しいですし好きですよ？)

「手早くモノづくりしたい」「アイデアを早く形にしたい」そういった人たちにとってはプログラミング学習が苦行になり得るようです。

勉強嫌いな人は続かないかもしれません。嫌なことから逃げ出したくなる人もそうかもしれません。「楽をするためのプログラミングは苦労しないとできない」ということを受け入れられない、あるいは乗り越えられない人たちが一定数いるようです。

最近では「エンジニアは気軽になれる・稼げる」が売り文句みたいになってる風潮がありますが、結局は専門職であり職人なんだと思うんです。

常に技術は進化しますし、需要も変わり、ノーラーニングでは決して続けられません。どんどん置いていかれます。そこに健全な危機感を持って追従を保てれば良いですが、憂鬱になるとメンタルリスクも上がります。仕事ではそこに人間関係も絡むので、更にカオスです。

プログラミングを論理の設計・構築・実装と抽象化して捉えるとしても、思考し続けることが苦な人には耐えがたい行為ではないかなと思います。

Hata Yujiさんの回答で、次のようにありましたが

・難しいこと、わからないことが多すぎる

これに尽きると思います。

見知らぬ言語で仕事をしはじめると、全くわからない状態になります。

私は JavaScript で React の仕事をいくつもしてきたので、それなりにその手のコードは読めるのですが、WordPress上のPHPとか、RailsのRubyとかみると細部が読めないためにさっぱりわからなくてコードの数行を理解するにもかなり時間がかかります。

また、慣れた言語であっても、世の中にあるWebページや書籍で紹介されているコードの書き方だけではなく

その仕事現場で誰かが書いた仕組みにそってコードを書く必要があり、それがより一層、物事を複雑にします。

自分で最初から作るならそれなりに迷いなく実装できますが、前任者が書いたコードを読み解いて、その上でルールにそってコードを書かなければならない、となる場合があります。前任者の思想や癖を相当理解しないとコードがかけなかったりします。

そもそも、前任者が完全に理解した上で書いているのか、前任者も苦しみながら混乱しつつ書いたのか、その前任者のスキルレベルはどうなのか、とか、そういうのがわからないで引き継いでコード書かなければいけなかったりして、それをを読み取らないとより全体的に統一された正しい改良・修正ができなかったりします。

こうなると、その思想などを読み解くのが大変すぎて、ひどくわけわからない状態に放り込まれて1日中悩んでも何も成果がでない、という事もあります。結構つらいです。

人の書いた小説になんかしらの矛盾があったりするので引き継いで矛盾なく新しい要素を加味した上で素晴らしストーリーにしてくれ、とか言われてやりこなせる作家さんとか、そんな仕事あるのかどうか知りませんが、プログラマが要求されるのはそんな仕事が多いです。

極めて難しい仕事だと思います。

プログラミングをお仕事にしている、みなさん！

たぶんみなさんがんばって仕事されていると思います。自分もがんばります。

難しいけど、がんばってやっていきましょう！

追記
あと、前任者が難しく考えてしまっているって場合も多々ありそう。経験つむと物事を極力シンプルにとらえるようになっちゃうのかも。

他に書いていた記事と、ニュース記事リンクしておきます。

オブジェクト指向のプログラミングの問題点は何ですか？ - Quora

余計な「念のため」でプロジェクトが死に至る「オーバーエンジニアリング」の問題とは？ - GIGAZINE

「プログラミング」は、「文章を書く」みたいなものです。

文章を書くのは難しいですか? ツイッターに飯の内容を書いたり、Quoraでこうしてすぐ答えられそうな回答を書くのはさほど難しくありません。でも大勢の心を動かすような物語を書くのはとても難しいでしょう。

プログラムにも、プログラマが「使い捨てスクリプト」と呼ぶような、目下の面倒な作業をちゃちゃっと済ませるためにほとんど考えもせず書く数行のコードもあれば、どうやって解くのか見当もつかない問題にアプローチしようとするコードもあります。

プログラムが難しい理由その１は、「難しいのは解こうとしている問題の方だ」というものです。こちらは、人類の知が進んで問題の構造を明らかにしてゆかない限り、プログラミングそのものでどうにかなる話ではありません。漢字が難しいから全部ひらがなにしよう、とか、動詞の活用なんて面倒だから無くしちゃえ、としたって、小説を書くのは簡単にはならないでしょう?

ただ、その「解こうとしている問題」のひとつに、「プログラムの複雑性をいかにして制御するか」というものがあるのは確かです。「プログラミングをわかりやすくする」という問題そのものが、これまで情報工学でずっと取り組まれてきたにもかかわらず解決されていない、難しい問題なんです。(もちろん、「漢字は難しいからひらがなにすればいい」みたいな話はたくさんありました。でもそれでは解決にならなかったわけです)。

ただ、問題の記述方法や解決方法がある程度わかっている分野、例えば「日頃から繰り替えしているPCの操作を自動化したい」みたいな部分では、昔に比べればはるかに簡単になっていると思いますよ。最近ではやってほしいことを自然言語で指示したらコードを出してくれるAIも出てきました

脚注

4段階で説明してみます。

1: 人間があまり得意ではない「厳密な論理」でまず考える必要がある

「いい具合にしといて」という指示が効きません。「いい具合」を厳密に定義してあげるか、あるいは数学・統計学の文脈で「誤差〜〜で」のようにちゃんと指定してあげる必要があります。「思ったように」ではなく（プログラムを）「書いたとおりに」実行されるため、人間への指示とは根本的に違うアプローチを要求されます

2: 機械の都合に合わせる必要があり、理想的な数学的世界を記述しきれない

「厳密な論理」ということであれば言ってみればある種の数学の記述通りに動作してくれればまだ良いのですが、「CPU」「メモリ」「ディスク」のようなハードウェアや、隙間のない「実数」をプログラムでは表現できないといった制約によって、1番で一度要求された「厳密な論理」をさらに、ある意味で「めっちゃ不完全」な「コンピュータ」の言葉に翻訳する必要が生まれます。

0.00…1のような小さい数字と同様の小さい数字を割ったりすると理想的な実数では起きないようなことが起きます。コンピュータの部品は完全に壊れたり、中途半端に壊れたり、宇宙線でデータの中身が入れ替わったりします。

3: 1番と2番の「人間の脳と理想世界とコンピュータのギャップ」を埋めるツール群がまだ十分でない

昔よりも「プログラミング」を行う人を助けるツールについて大きく進んでいると思います。それこそ、今のPCは昔のスパコンを凌駕する性能を持ちますので、印刷した紙の上で「レビュー」するといった必要もなくユニットテストを書いて都度実行できますし、人間が分かりやすいように「このプログラムは危険な匂いがします（「匂い」にはコンピュータが分かるルールが定義されている上で）」と伝えてくれるツール群まで発達しました（例えば「統合開発環境（IDE）」なんてのは昔からするとすごいものなのではないかと思ったりします）。

極論するとExcelもまたそのようなギャップを埋めるツールであり、ある種の普通の人々が対応しなければならないプログラミングはむしろ「簡単」になっているものもあるようにも思えます（例えばアンケート調査とその集計とか）。

しかし、1番と2番を根本的に人間が無視できるほどにはツールは有能になっていませんし、問題領域によってはなれる見込みがあまりありません。そのため、以下に述べる4番とセットで誰もが「簡単」と思う段階になっていないのだと思います。

4: どんどん異なる要素が「プログラミング」という言葉に詰め込まれてきており、その状況が加速している

エニグマ暗号解読の時代からすでに「難しい」世界のはずですが、今は更にそれに加えて「世界中の異なる文化圏に属するユーザに配慮する」であるとか「ペタバイト〜エクサバイトのデータを処理する」であるとか、要求がどんどん上がっているという側面もあると思います。CPUの周波数を上げれば良いという時代も、発熱がヤバすぎてとうの昔に終わっているため、以前であれば単一プロセスに丁寧にロジックを書けばよかったのが人間がおそらく不得意とする並列プログラミングを前提にしないと速度が上がらないなんていうのも関係しているかもしれません。

さらに、数学・計算機科学の領域だけでなく、最近は現実のユーザに配慮することまで「プログラミング」の仕事に含むことがあります。そうなるとデザイン・アート、経済情勢、国際情勢（リアルタイムのサイバー攻撃に強いサービスを作る）など、人間が触れるありとあらゆる側面が総合して「プログラミング」を取り囲んでおり、さらにそのペースが加速しているかのような印象を持ちます。

上で記述した3番の「ツール群」がそのような周囲の要求速度に全く追いついていないので、いわゆるAIに任せきりにするしかないなんていうレベルまで今後「プログラミング」は難しくなるかもしれません。

ご質問を拝読すると、まるでこう訊かれているように感じます。

「法律の運用、立法・行政・司法が難しいのはなぜですか？というか、政治家・自治体・法律家なら司法そのものを簡単にして、わかりやすくする事も出来ますよね？『難しいままにしておくんだ！』みたいな、忖度が働いているのですか？」

……これは私個人の考えですが、政治家、特に立法者は、ある意味、プログラマーに似ていて、社会という大きなマシンを動かすためのプログラムを作る「社会的技術者」である、と思います（そのような自覚を持つ政治家を見た事は無いが）。　そう考えると、行政とはプログラムに従って同時並列で動く実行者であり、司法とはプログラムに問題が有ったときにどうするか決める調停者である、と言えましょう。

そう考えた時に、１億人とかの規模で「動く」プログラムをきちんと作ったり、正しく運用したりする、というのは、とても大変で、簡単にする事など夢のまた夢である、という事はお分かりいただけるかと思います。

仮に１００人くらいしかいない小さな国家ないし自治体で、立法・行政・司法を置いたとしても、それらを円滑に運用してゆくのは、決して簡単とは言えますまい。

プログラミングの難しさの本質の一面は、たぶん上記のような事だと私は考えます。

また、上記とは別の難しさの一面は、人間とコンピューターが、あまりに違いすぎる事によるものです。　よくコンピューターと脳は対比され、似た部分を論じられる事が多いのですが（どちらもディジタル処理されている、など）、今のところは相当異なるものです。

プログラムとは、コンピューターという単純労働者に対して、間違い無い作業をさせるために、厳密に書かれた手順書です。

ここで注意しなければならない事が２点あります。　コンピューターは、人間の単純労働者と違って、手順書に書かれた事は、たとえ変な事であっても必ず忠実にやり遂げてしまう、という点（コンピューターは疑問を抱くという事が無い）、および、それが超高速に（つまり一挙に大量に）実行される、という点です。

この２点があるため、プログラム作成者は、プログラムをきわめて緻密に作り上げなければならなくなるのです。

「思い通りに動かなかった」なんて、ザラにある事ですが、その程度で済めばかなりマシな方で、それが超高速・大量に処理された結果、「想像もしない悲惨な出来事」になる事もままあります。

法律なら、行政の現場で誰かが疑問を持ったりして、そこでいったん止めてみる、とか、裁判所に訴えてみる、という事も出来ますが、

プログラムは、いったん実行されれば、コンピューターは何の疑問も持つ事無く、忠実に、高速に、大量に、一挙に、処理を遂行し続け、自身の判断で止めてみるとか、調停者にお伺いを立ててみるとか、そういう事が出来ません。　そもそも現代のプログラミングには、司法に相当する機能が充分ではありません（三権分立とはよく考えられたシステムであるとつくづく思う）。

そのため、プログラミングは、どうしても緻密な作業にならざるを得ず、１字間違えただけで動かない（とよく言われるが、より正確に言うなら、「コンピューター的には、間違いが明確に在るものは動かしてはならない」のである）、という事になるのです。

プログラミングが簡単にならない事について、何らかの忖度が働いている、と、強いて言うならば、それは、コンピューターに対して、人間が大きく忖度しなければならない、という事情に依るものです。

……と、まあ、以上のような事情から、プログラミングは簡単にはならない、と私は考えています。

過去数十年にわたって、「コードを書かなくてもプログラミングできる」などと謳う IT 製品が何度も出現しましたが、ついぞプログラミングが不要になった事はありませんでした。　たぶん今後もそうでしょう。

もちろん、簡単な命題については、プログラミングは簡単です。　たとえば１０００未満の自然数のうち３の倍数だけの総和を求めよ、なんていうプログラミングは、義務教育を負えた者なら、誰でもできるでしょう。

しかし、社会の未解決問題や、新しい何かを産み出す、という事柄については、プログラミングはどうしても簡単にはならないでしょう。

誤　義務教育を負えた者なら、
正　義務教育を終えた者なら、
(2021.07.30-22:34)

難しそうに見えるからです。左がコード、右がアウトプットです。

実際には左側には大したこと何も書いてないのですが、プログラミング初心者には難しく難解に見えます。誤解です。

自分は高校2年生の時に授業でプログラミングを習ったので、初心者の気持ちを多少覚えています。まずはその視点から。

操作上の難しさ

まず始めに、誤字脱字に異常に厳しいという点でつまずく人が多いと思います。コンピューターは（今のところ）間抜けで気が利かないので、厳密な命令にしか従いません。この厳密な命令がプログラミング言語ですが、そこで使われる見慣れない記号を一文字も間違うことなく打ち込むのはかなり非直感的な作業です。思考上の厳密さについては他の回答者もあげていますが、操作上の厳密性も一つのハードルでしょう。

例えば、ピアノなどの楽器の操作を覚えるのに少し似ているかもしれません。モチベーションを高めて集中するのみです。

思考上の難しさ

抽象的思考が必要です。プログラミングで使う変数、関数やオブジェクトと言った概念は実体がなく、定義や性質で理解するしかありません。目に見えずイメージし難い概念を扱うのはまさに抽象的思考でしょう。その点では数学の代数の習得と似ています。実際、中学レベルの代数の理解がなければプログラミングは難しいと思います。

プログラミングが抽象的な理由として、複雑なコンピューターのしくみを全部理解せずとも使えるよう設計されているからです。コンピューターは機械なので実体はありますし、全てのプログラムはコンピューターの中のシリコンが「作動」して動いていると考えるべきですが、現代のプログラミング言語ではその難しい部分の多くがブラックボックス化されています。ブラックボックスよる簡潔化の引き換えに実体感が薄まり、抽象的になっているのです。

厳密な思考については他の回答者が書いたとおりです。具体的な例を使えば、「数列を大きい順に並べる」という一見簡単なプログラムでも、実際に書こうと思えば大体こうなります。

1. 列の中から一番大きい数を選ぶ
1. 列を通過する際、一番大きい数（暫定王者）を記録し、次の数字と比べる
2. 次の数字の方が大きければ新王者誕生、王者を更新。でなければ王座防衛成功
3. aとcを列の最後まで繰り返す
2. 一番大きい数を最初に持ってくる
1. 元々最初にあった数と入れ替え
3. 一番大きい数はもう最初にあるので、列の二番目の位置からスタートし1と2を繰り返す。

これは最もシンプルな方法なので効率のいいアルゴリズムではありませんが、ここで分かるのは、「大きい順に並べる」という簡単な目標でも、実際にプログラムで実行しようと思えば細かいロジックまで組み立てなければならないということです。これがプログラミングの難しさであり、醍醐味でもあります。

抽象的思考と厳密な思考は普段使わない頭の動かした方ですが、プログラミングでは二つ同時に求められるので、色々慣れが必要でしょう。

コンピューターサイエンス

質問はプログラミングに関してですが、関連することなのでコンピューターサイエンス（CS）との区別について少し。

CSが経済学ならば、プログラミングがビジネスでいうセールス。つまりCSは理論の体系であり、プログラミングは実用的なスキル・作業です。経済学を専攻しなくても物を売れる（セールス）ように、CSの知識なくともコードは書けます（プログラミング）が、経済学が物を売るだけではないように、CSもコードを書くだけでありません。

具体的にCSの分野をいくつかあげると、

• ソフトウェア工学：プログラミングでシステムをいかに構築するか。車を作る際に各部分を作ってから組み立てるように、プログラミングでもパーツを作ってから組み立てます。その管理や方法論を扱う分野。
• コンピューターアーキテクチャ：ハードウェア設計。コンピューターの仕組みを扱う分野。
• システム系：プログラミング言語、分散コンピューティング（並列処理、オペレーティングシステム、ネットワークなど。（少し語弊はありますが）ハードウェアとソフトウェアを繋ぐ分野。
• 人工知能：複雑な問題を解くアルゴリズムの設計。現在では機械学習が主で、それ以外の人工知能は進展が少ないです。ディープラーニングなど。
• 理論CS：ほぼ全部数学です。理論物理学が物理世界の数学的モデルを扱うように、理論CSではコンピューターで処理できる構造の数学モデルを扱います。組み合わせ数学、情報理論、暗号理論、アルゴリズム理論など。
• 応用系：コンピューターグラフィクス、科学計算、ウェブ工学、HCI等。

上記のCSの知識を駆使してシステムを作る仕事が「ソフトウェアエンジニア」と呼ばれています。当然プログラミングは基本ですが、それ以外の役割もたくさんあります。例えを続けるなら、「ビジネスマン」にとってセールスは基本ですが、それだけが仕事ではないのと同じことです。

プログラミングで大きな物を作りたければCSの知識が必須になります。そう意味では、CSという学問もプログラミングが難しい理由の一つと言えるでしょう。

興味深い観点でプログラミングについて問われていて、考えさせられました。

突き詰めて考えると、「難しいままにしておくんだ！」という忖度や意志が働いているというよりは、一般の人から見て難しい状態の方が、ハードウェア（CPUなど）が作りやすいからだと思います。

結局誰が頑張るか、という事になるのですが、別にプログラミングというスキル自体、ほとんどの人にとって生命を維持するのに必要なスキルではないので、プログラミングをする人が頑張ればより効率の良いハードウェアが作れる、という面があり、その結果今のようにITが発展してきたとも言えると思います。

プログラミングしやすいハードウェアを作るという試みもありましたが、今はすたれていますから、今の状態の方が相対的によかった、という事なのだと思います。

一方、ノーコードと呼ばれるような、プログラミングを簡単にする手法も開発されていることは、もしご存じなければ調べてみてはいかがでしょうか。それはプログラミングそのものを簡単にする、というアプローチです。ただし、プログラムが簡単になった分、相対的に難しいプログラムをするよりはそんなに大したことはできない、というトレードオフがあります。

結局のところ、ご質問にある「難しい」というのは相対的なものであって、おそらくほとんどの人にとって現状プログラミングは、非日常なものでしかないわけですから、余計に理解しなければという必然性もほとんどなくて、難しいと思いがちなだけです。なぜなら先に書いたように、生きるのに全く必要のないスキルですから興味がないのは当然ですし、興味がなければ難しく感じるのは当たり前なのです。そういう面もある、という事はご認識いただければと思います。

私にとってみたら、最近のゲームはやたら小難しくて、もっと簡単なルールにすればいいのに、と思いますが、子供たちはいとも簡単に進んでいくように見えるわけです。でも実は子供たちだって日々そのゲームを研究しているから進んでいくのであって、プログラムだって書ける人はそれなりのことをしているからできるのです。何事も、できない、苦手な人から見たら難しく見えるのですし、一方簡単にできるようにできることは簡単にしていっているわけで、それでもまだ簡単になっていない事柄にはそれなりの理由があるのです。

例えばパソコン自体は、昔はマウスもありません。いちいち何かキーボードから命令を入力したり、何ならプログラムを組まないと何もしてくれませんでした。ですがプログラマーもハードウェア開発者も頑張った結果、スマートフォンのように簡単に操作できるようなものができました。そこは別に頑張ってできることなので頑張っているのであり、プログラミング自体を簡単にすることは、優先度が低いし、先に申し上げたようにハードウェア開発との絡みもあって、効率が良いほうを選んでいる、という事だと思います。

プログラムを教える事もあるので。

人にもよるでしょうが、教えてて思うのは、新しい思考の枠組みを導入しなくてはならないので、それに時間がかかるというのはあると思います。

例えば、卵焼きのレシピを作るにしても、普通は対人間用の手順を前提にして考えます。

レシピ中に「かき混ぜる際は泡立て器ではなく菜箸を使用して、ボウルを左腕に乗せるようにして落ちないように、逆時計回りで、ボウルの直径より２から３まわり位小さい円をイメージして一秒間に1から3回程度の割合でかき回して下さい」とは普通描きませんが、プログラムではこれに近いような考え方をする必要があったりします。

普段の生活では使用しない考え方なので、こういった思考パタンが身に着くまでにある程度の時間がかかるというのが習得のネックになっている気はします。

あと、プログラムを学ぶ大抵の動機が「ゲームが作りたい」ですが、初心者はコマンドプロンプトという文字だけしかでないプログラムを延々と組むことになるので、派手さがありません。

その為モチベーションの維持もしにくいという状況が発生している気がします。

他には、絵やイラストみたいに、人に見せて意見を聞くという事がしにくい環境もあると思いますし、そういうノウハウの情報が意外と少ないというのもあると思います。

とはいえ、今は大分環境も良くなりました。

独学でもプログラムの基本だけならCodeIQやPaizaでゲーム感覚で学べるサイトも出てきています。これらのサイトだけではスマホゲームを作るスキルには届きませんが、プログラミングの基礎的なスキルの習得だけなら問題ないとは思います。