エンジニアとして成長するための考え方

今回は技術的な質問ではなく、エンジニアとしての考え方に関する質問となります。

最近、技術の勉強※1をしていて、

「これで本当に勉強になっているのか？成長速度は遅くないか？」

と自問しております。

この自問の背景には、以下の仮説があります。

より正しい考え方ができていないと、勉強しても何も身についていないのでは？

延いては、エンジニアのスキルそのものにも大きな影響を及ぼすのでは？

「より正しい考え方ができていないと勉強しても何も身につかない」という仮説※2を真とした場合、
その考え方とはどんなものがあるでしょうか？

※1
技術の勉強というのは具体的に、以下のことをしています。

・技術書を読む
・サンプルコードを書いてみる
・オリジナルアプリケーションを作って、実際に動かす
・質問する（御助言下さる方、本当にありがとうございます）
・VMでLinuxを動かす

※2
一例を挙げますと、

2時間勉強に使って、なんとか「Hello, World!」を出力できた

とします。

しかし、私の仮説においては、これでは全く勉強になっていません。その理由は、

仕組みを理解してこそ勉強であり、なぜ「Hello, World!」を出力できたのか、その仕組みの理解に全く時間が割かれていないため

です。

------------追記------------
貴重な御助言を下さいました皆様、ありがとうございます。

この質問に対してベストアンサーを決めることは、技術的な質問に対するそれとは異なり、
本質的な意味を持たないと考えております。
このまま勉強を続け、個人的に一番成長できたと思う考え方をベストアンサーとさせてください。

------------追記2------------
そもそも前提がおかしい、など、是非ご意見を頂きたく思っておりますので、お気軽にご回答ください。

m.ts10806

2018/08/13 13:23 編集

特定の言語のプログラミングにおける質問ではなく、「考え方」そのものを聞きたいのであれば具体的な言語名をタグに並べるのは微妙です。質問内容を読む限りどの言語も関係なさそうですし。もっと適切なタグをつけてください。（次の質問も同様）

行動規範の内容に同意します

回答13件

ベストアンサー

40歳近くなる私が気づいたこと、気を付けていることを書いておきます。

気づいたこと
・必要となるタイミングに間に合うことが肝要であって、早さ・速さはその次。
・持っているものを知っている事が、足りないものを知る時に最も役に立つ。
・なぜという動機・理由こそが行為や結果のすべてを物語る。そこの理解が氷解点。

気を付けていること
・普通人は見える（見れる）ものを見る。だから自分は見てないところ（見るべきもの）を見る。
・普通人は出来る（やれる）方法を採る。なので自分は人が避ける方法（面倒でも必要な手順・手段）でやる。
・物事の本質に迫ると、説明は抽象的か極端にシンプルになる。少数派が口にする奇異な意見は聞き逃さない。

syoshinさんの疑問は多くの人が持つものだと思います。勤め先の新人や若手も持ってます。
いわば不安だと言えると思うのですが、この不安が効果的に働いたケースを見かけません。
不安を持つ気持ちは、私自身持っていたので察してあまりあるのですが、あえて
『不安を持つくらいなら、「何ができたか」「何がわかったか」を「これ」と思えるまで把握しろ』と言ってます。
なぜなら、人は新しいものを理解する時、自分が知っていることを拠り所にして理解するからです。
ある種の優れた人たちは、理解する範囲を広げ、想像力を働かせて動機や理由まで押さえきって本質を突いてしまいます。
本質を突いてしまった人は、不安にすら理由を付けられ説明でき、場合により行動に移してしまいます。

syoshinさんは『「これで本当に勉強になっているのか？成長速度は遅くないか？」と自問している』とのことですが、それは『なぜ、そう思ったのですか？』
漠然としているのであれば、それはただの杞憂であって、益のない無駄な焦燥かもしれません。
もし「これ」とか「こうだから」いう理由がわかれば、不安の感じ方はだいぶ変わる気がします。

追伸

・Why do you do that?（なぜそれをするのか）

多くの仲間がマネジメントに進み、技術力の重要性を説くも、技術力の不足に嘆いている姿を見てきました。
私は彼らのように昇進や昇給は得られない日陰ではありましたが、人の苦労を見て「そうならない為に必要なことは」ということを試行錯誤をしてきました。結果「日本で一般的に言われることをやると、普通に一般的な悲哀に到達する」ことと、「一般的に言われることを逆手に取ると悲しまずにすんだ可能性が高かった」ことが分かったのです。
なので、効率・簡潔・拙速とは逆を行き、コストダウンよりも払ったコストを無駄にしない事を求めました。
無駄なことはしたくない。だから私は書いたように行動しています。

投稿2018/08/02 13:36

編集2018/08/08 21:17

Hiroshi-Aoki

総合スコア804

退会済みユーザー

2018/08/02 14:02

ありがとうございます。なぜこのような自問をしているかと言いますと、・より正しい考え方ができていないと、勉強しても何も身についていないのではという仮説をもっているためです。一例を挙げますと、この考え方も意識しているのですが、・2時間勉強に使って、なんとか Hello, World! を出力できたとします。ですが、これでは私の仮説においては全く勉強になっていません。その理由は、・なぜ Hello, World! を出力できたのか、その仕組みの理解に全く時間が割かれていないためです。こういった考え方が勉強という過程に大きく影響を及ぼすのでは、という仮説を元に今回の質問をさせて頂きました。

Hiroshi-Aoki

2018/08/02 14:49 編集

おっしゃること尤もだと思います。私の場合は「仮説においては全く勉強になっていません。」に対し「良い結果は得られない」という見解になります。・「Hello, World! を出力できた」ことは２時間かけた結果の利益としてシッカリと認識すべし・「Hello, World! を出力する仕組みを知る時間が必要だとわかった」をことも利益と考えるべし次に・「仕組みを知るにはどれだけ時間を割く必要があるだろうか」と考えてみるのが良いと考えます。うちの若手だったら『「仕組みを理解するのに時間を割くこと」が最重要な事だったのか？』と聞いてみて『２時間で仕組みまでわかるとたかをくくってたのか？読みが甘かったな！反省だな！』と叱咤し『管理職みたいな。。。工場の製造ラインの機械じゃないんだから時間で終わらんて』とフォローする感じです。「正しい考え方」「正しい手段」というのは現実的には存在しなくて、唯一絶対に正しいといえるのは、「勉強して何も向上がないなんてことは絶対にない」といことです。多くの人は、時間を基準にして効果を測っていて、時間を基準に考えることは大切ですが、時間を基準にすることで、得たはずのものを「何も身についていないのでは」と切って捨てる愚はそれこそ「勉強という過程において大いに悪影響があるのでやめるべきだ」と私は思います。「かかるものはかかる」という現実を侮蔑して軽視するのは日本の文化みたいなものかもしれません。（こうなるのには、こうする側の視座・視点における理由が存在するものですが。）例えば、それでも「全く勉強になっていません。」と若手が言ってきたら… その時は「その目的のために２時間使ったのなら、時間の無駄遣いしてるの？」から「地に足のついてないことしてるんじゃないよ。暇じゃないんだから」とガチギレし「かけた時間からは、ちゃんと利益を得ないと時間に価値がなくなるから。利益を得るのが一番大事！」と言ってみると思います。

退会済みユーザー

2018/08/03 00:02

2時間かけて勉強した結果、何も身についていないということは全くなく、その利益は確かにある、ということでしょうか。何も身についていないと考えることは、確かに悪影響かもしれませんね。。気をつけます。御助言ありがとうございます。

Hiroshi-Aoki

2018/08/03 14:48 編集

伝えたいと思っていたことを理解してくれたようで嬉しく思います。私の経験上で得た、現時点での「勉強を学びとして実感することになる「最も身につく効果を最大化させられる勉強方法」』を書いておきます。それは、「手段がわかった（Hello, World! を出力できた）なら、なぜその手段が生まれたのかを考察して自分なりに理由（仮説）を立てる」ことです。私が回答に書いた「なぜという動機・理由こそが行為や結果のすべてを物語る。そこの理解が氷解点。」のことです。プログラマやシステムエンジニアとしての基礎として以下は知っておくと良いです。・プログラミングは「入力を出力にするためにデータを加工してるだけ」・システムは「人が行うことを代わりにやってるだけ」・システムは「人の手より速く動き、人よりも物忘れすることがなく、人のようなミスやまぐれはない」の3点と・プログラミング言語としてはC言語が人間が人間的に扱える言語の元祖だったのだよの1つを押さえていればOKです。どんなプログラミング言語も、C言語を皮切りにして臭いものに蓋をしたり楽をしようとして生まれてきています。「何が臭くて生まれたのか」「何を楽したくて生まれたのか」を知れば、プログラミング言語の存在意義に気づき、使い道や使い方をはじめとする学ぶべき事柄がわかります。例えば、なんでPythonが流行るのか。Rubyはなぜ流行ったのか。PHPは？Javaはと。すべての言語には生立ちがあり、それを知れば効果を最大化できます。（知らないと旨味を享受できない）プログラミング言語や技術は、それをそのまま捉えようとすると難易度は高いです。書き方も違えばできることも違う。でも、根っこは同じで、見かけや癖・得意分野が違うだけ。やってることは同じなんです。ゲームのような異世界を体験させてくれるようなものは別として、その他のほとんどは人間世界、つまるところ身近なことを人の代わりにやってるだけ。（Hello Worldは「呼んだら返事する的な」。オブジェクト指向あたりは現実世界をほぼそのまんまシステムとして再現しにかかってる。）何故その技術やシステムは作られたのか、そして人間が行う何を代替していることになるのか。それを発想した人は何を目的にしていたのか。ここらへんが分かれば、後はプログラムを各スピードの差、熟練度の差だけの話になってきます。技術は数珠つなぎ。1つ1つの理解が意味のないものに感じたとしても、別の1つの理解がビリヤードのように、脳のシナプスがつながるように理解同士を結びつけます。その時こそ成長を成し遂げ、ステージが上がる瞬間。「あ！わかった！！！」と成長を実感するでしょう。他にも、自分が得た理解を他人に話しても理解を得られない時、相手が理解できない理由に察しがついたなら、自分のレベルが他よりも上がってしまった状況に気づき、悲しい思いをするかもしれません。周りよりも早く成長する最速というのも、度が過ぎると孤独を産みます。価値のあるシステムやプログラムは、一人で作ったり維持したりするには無理があるものですからね。

退会済みユーザー

2018/08/04 00:24

なぜその手段が生まれたか仮説を立てることは、意識して実践していきたいと思います。最後までアドバイス下さり、本当にありがとうございます。

行動規範の内容に同意します

私の経験だけの範疇になりますが、

適切な難易度の問題に取り組む

自身のレベルにあった、ちょっと難しい問題に取り組んで解決する、という経験が大事です。
簡単すぎてもダメ、難しすぎてもダメ。
スライムばっかり倒しても経験値にならないし、かといってLV10そこらでダースドラゴンには勝てないでしょ。

成果ではなく、過程を勉強する

「できたモノのすごさ」に目を奪われがちですが、個々の成長として最も大事なのは「それを作る過程でどんな行動をしたか」です。
具体的に言うと問題解決のための調査能力です。
熟練者はなぜ熟練者たるのか？　それは困難な問題を解決するための知識を探す術を知っているからです。

回答する

質問だけではなく回答もしてください。
回答するには、その質問、疑問に対して正しい知識と正しい伝え方を身に着けていなければなりません。
どちらも場数と経験で向上していきます。ぜひ回答者にクラスチェンジを。

成長速度は千差万別です

自分の成長が遅いと感じるからと言って、気に病まない。
前に進む速度は人それぞれです。常に全速力で走る人と比べて自分が劣っているなんて思わないことです。

参考になれば。

投稿2018/08/02 12:36

hope_mucci

総合スコア4447

退会済みユーザー

2018/08/02 12:39

ありがとうございます。少しでも取り入れるよう意識致します。

行動規範の内容に同意します

自分の知っている勉強法が「最速」かどうか判断できるほど私は道を究めていないので、あくまでも部分的な回答となりますが、

2時間勉強に使って、なんとか Hello, World! を出力できた

とします。ですが、これでは私の仮説においては全く勉強になっていません

確かにこれだけでは不十分かもしれませんが、「勉強になっていない」は言い過ぎと考えます。

人間の頭は、経験のたくさんの蓄積があってこそ、物事を肌感覚で理解できるようにできています。「この考え方では問題が解けない」という経験も立派な肥やしです。仮に3時間目にあなたの考える本質的な勉強が成就できたとしましょう。無駄に思える2時間があったからこそ残り1時間でそこにたどり着けたのだと考えるべきです。

しかし、常に問題意識をもちながら勉強を進められている姿勢は素晴らしいものと思います。安易に質問を投げかけては表層的な「理解」に満足し、しばらくするとまた同じレベルの安易な質問を投げかけてくるというタイプの方々もたくさん見受けられますが、質問者さんはそれに比べて何百倍も有望であると思います。あまり短期的に目に見える成果を追い求めず、あせらず勉強を続ければかならず目標は達成できるでしょう。

投稿2018/08/02 14:58

KojiDoi

総合スコア13671

退会済みユーザー

2018/08/03 00:06

ありがとうございます。全体として3時間かかったとすれば、最後の1時間で理解できたことは、最初の2時間の経験があってこそ、ということでしょうか。使った時間は必ずしも等価ではないということを肝に命じておきます。

行動規範の内容に同意します

・技術書を読む
・サンプルコードを書いてみる
・オリジナルを作ってみて、実際に動かす
・質問する（御助言下さる方、本当にありがとうございます）

これでいいと思いますし、独学するのにこれ以上のことはないと思います。
仮にこの方法で成長速度が遅いと感じているならば、単純に勉強量が少ないだけだと思います。

なぜ Hello, World! を出力できたのか、その仕組みの理解に全く時間が割かれていない

どこまで波及させますか？
OSのネイティブな実装部分や、ハード部分の電子回路まで原理を勉強しますか？
当然知らないよりは知っている方がいいと思いますが、
一度に多くを望むと、いつまで経ってもどの分野の進捗も良くなくモチベーションが下がるだけです。

「この関数やメソッドを呼ぶとコンソールに出力される」「こうするとファイルに出力される」
という事が分かればいいと思います。

大事なのは・・・

【予想】100
【結果】200

なぜ、100ではなく200と表示されたのか？
分からないからteratailで聞いてみよう。
教えてもらったように書けば200になった。

なぜこの書き方だと200になるのか？
ここを、さぼらずにコードの全行を理解することです。

「より正しい考え方ができていないと勉強しても何も身につかないのでは、という仮説を前提とした場合、その考え方とは何か」

まず前提として、「知っている」と「身につく」は別次元のものです。
そして「身につく」のは自身の考え方の問題ではありません。
今やっている事が「必要にせまられているかどうか」です。
いくらやっても身につかないならば、それは今のあなたに不要なものだからです。
問題に直面し、それを乗り越えた事しか、中々身にはつきません。

様々な分野の問題に出会うために

問題は起きるのを待たなければならないものでもなく、自らぶち当たりにいくことができます。
その方法は、何かアプリケーションを作ることです。
簡単なものではなく、それなりの規模のものがいいです。
簡単なものでは問題に直面しないか、もしくは容易に乗り越えれるからです。
最小限で作って、後からドンドン機能追加していくのもいいですね。

だから勉強方法としては冒頭の方法で全く問題ないと思いますが、
１冊入門書が終わった時点で何かを作りましょう。
詰まった時にはteratailがあります。

ちなみに、僕が１年目の時は何を作っていいのか分からなかったので、
現実世界のものをGUIで作ってみたりしましたね。
「自動販売機」とか「エレベーター」とか作りました。とても楽しかったです。
あとWindowsのメモ帳の完コピを目指すとかもしました。

自動販売機も最初はレイアウトを作ってボタンを押すとジュースが出る部分だけ。
そこからお金投入を追加。買いすぎると売り切れるように在庫を追加。
当たるともう一本買えるようにスロットを追加。（ここでスレッドを初学）
在庫はメモリーにだけ持っていたが、永続化したいため在庫情報をファイルに持つようにした。
（ここでプロパティファイルやXMLなどのファイル形式と、読み書きの方法を学んだ）
などなど。

今だとスマホアプリとかが始めやすいかもしれませんね。
Webアプリでもいいですけど、難しいのでグッとハードルは上がります。

投稿2018/08/03 01:44

root_jp

総合スコア4666

退会済みユーザー

2018/08/03 11:19

ありがとうございます。確かに勉強量が少ないだけかもしれません。また、もっと多くのアプリケーションを作っていきたいと思えるようになりました。

行動規範の内容に同意します

一次情報

より正しい考え方ができていないと、勉強しても何も身についていないのでは？
延いては、エンジニアのスキルそのものにも大きな影響を及ぼすのでは？

ネット上には多くの情報がありますが、中には「誤った情報」「不正確な情報」もあります。
書店にある書籍をパラパラとめくっても、「誤った情報」が散見される事は珍しくありません(特に初心者向けの平易な文章で書かれた参考書は高確率でそうです)。
誤情報に惑わされない為には、「絶対に正しいと確信できる情報」が必要です。
それは「作った人が書いた情報」で一次情報と呼ばれます。

HTML Standard

例えば、HTMLの一次情報は下記リンク先にあります。
(※英語が原文ですが、読むのが辛い場合は日本語訳を併用します)

HTMLはここに書かれている情報が全てです。
「ここに書かれていない情報」は別の仕様に分化しているか、各々のブラウザが独自に決定しています(実装依存)。

仕組みの理解

なぜ「Hello, World!」を出力できたのか、その仕組みの理解に全く時間が割かれていない

一次情報となる仕様書を読めばいいでしょう。
予め、「どのレイヤーまで仕組みを理解するのか」を決定しておく必要があります。
例えば、JavaScriptは次の手順で実行されますが、

ブラウザがWebサーバへHTTPリクエスト
ブラウザがhtmlファイルをDL
ブラウザがHTMLをパース
ブラウザがHTMLパース上でscript要素を確認し、外部JavaScriptをダウンロード
DLしたJavaScriptファイルをパース
JavaScript実行
DOMContentLoaded
window.onload

どのstepまでを理解しますか。
step6も更に落とし込めば、ECMAScript, DOM, その他API...のように多数の仕様書が集まって出来ています。
適切な仕様書を確認する事が重要です。

分割統治法

前節で「どのレイヤーまで仕組みを理解するのか」と書きましたが、分割統治法を使って、レイヤーを分けて考える事から始めると良いと思います。
分割した後は、パズルのピースを組み立てるように、アルゴリズムを考えるように私はしています。

Re: syoshin さん

投稿2018/08/04 00:33

編集2018/08/04 01:06

think49

総合スコア18162

think49

2018/08/04 01:07

余談なので、コメントで。私は「正しい知識」「正しい調べ方」はあると思っていて、それが「正しい考え方」に到達する道だと考えています。それは唯一の「正しい考え方」ではありませんが、「正しい情報」がなければ到達できない「考え方」です。

退会済みユーザー

2018/08/04 01:40

ありがとうございます。一次情報としてまず仕様書を確認するということは明確に意識できておりませんでしたので、意識していきたいと思います。

think49

2018/08/04 02:40

それも大切ですが、分割統治法で仕組み理解を期待するレイヤーをはっきりさせる必要があると思います。なぜ「Hello, World!」を出力できたのか、を具体的に考えてみるといいかもしれませんね。

think49

2018/08/04 02:43

分割統治法を使うのは、期待している仕様書が何かを見極める為です。 2018/08/04 10:05 に親記事に追記しています。

退会済みユーザー

2018/08/04 03:02

ありがとうございます。確認致します。

行動規範の内容に同意します

悟り、ではないですが、反復練習をしていて、ある日突然殻を割ったように、理解度が急上昇することがあります。ではその場合、それまでの愚直な反復は果たして無駄だったのでしょうか？

むろん、そんなことはありません。基礎を疎かにしてはブレイクスルーもあり得ないのです。

あと、自分の理解度を知る指標としては、「人の質問に答える」というのが割と効きます。
人の質問に的確に答えるためには、よほどしっかりとした理解をしていないとダメなのです。

余談：下記のプログラム、いろいろ突っ込みどころがあるんですが、はたして何が悪いのかわかりますか？
これをきちんと説明できる人、意外と少ないですよ。

C
1void main() {
2  printf("Hello world\n");
3}

投稿2018/08/02 23:44

編集2018/08/02 23:45

tacsheaven

総合スコア13703

退会済みユーザー

2018/08/03 11:13

ありがとうございます。基礎的な知識を積み重ねていくようなやり方で勉強していきたいと思います。また、余力があれば回答の方もしていきたいと思います。余談に関しまして、main()メソッドの戻り値はintのようですので、成功のexitStatusである0を返すようreturn 0; が必要になるのではないでしょうか（すみませんCは全くの素人です。）

行動規範の内容に同意します

反対に "エンジニアとしての成長を妨げる考え方や習慣" を列挙してみては？

たとえば、無意識にやっている？自分の成長を妨げてしまう7つの悪習慣
https://www.career-rise.info/blog/lazy-8custom/

...
最悪のことを考えすぎる
言い訳をする
他人の評価を気にする
完璧主義である
睡眠時間が少ない
楽な道を選ぶ
受け身体質である
...

楽な道を選ぶについては、逆にエンジニアにとっては美徳かもしれません。
プログラマーの三大美徳
https://moneyforward.com/engineers_blog/2016/02/08/engineers-virtue/

...
1.怠慢(Laziness)
2.短気(Impatience)
3.傲慢(Hubris)
...

同じ作業を繰り返さない、なるべく自動化を考えるなど。

投稿2018/08/04 13:19

katoy

総合スコア22324

退会済みユーザー

2018/08/05 07:59

ありがとうございます。いくつか思い当たるものがありましたので、なくしていきたいと思います。

root_jp

2018/08/06 00:25

僕もいくつか思い当たるものがあるので、改善する努力をします。。。

行動規範の内容に同意します

エンジニアとして成長した先にどうなりたいのかが重要なのではないでしょうか。
プログラミングは目隠しをして手探りで概念的な理解を深めていくようなものだと思います。
とはいえ環境構築が自動化されていっていますし、より優れたフレームワークもどんどん出てくるでしょうから、
その概念的な理解自体、仕事をする上で必要ではなくなるかもしれません。
たとえば機械学習を使う業務でさえ数学的な思考をほとんどしないのが普通になってきています。

投稿2018/08/04 01:41

s_diff

総合スコア107

退会済みユーザー

2018/08/04 03:00

ありがとうございます。アプリを使うことの敷居はどんどん低くなっていくと思いますが、そのための仕組みを作る側になりたいと考えております。

行動規範の内容に同意します

・Why do you do that?（なぜそれをするのか）

そうすると助かる人が居るから。
まあ、現実の何割か(もしかしたら大半)は自己満足ですが、正しいコード、理想のコードよりも使えるコードです。

・なぜ Hello, World! を出力できたのか、その仕組みの理解に全く時間が割かれていない

はあまり悩まないようにしています。車を運転するのに、エンジンの仕組みがどうとか、ハンドルを切ると曲がるのはなぜか、その都度、考えませんよね。
同じ事です。ただ、仕組みを知っていると色々と都合の良い事も多いので、勉強するようにはしていますが。
今のコンピュータも同様と思います。高級言語を使っている範囲で、CPU内部の構造を考えますか? という事です。

あとは、問題があった時に、目の前の問題を単純に解決すれば、良いのか、それともそれ以前の問題なのか、注意する事です。

期待される回答とはちょっと違うかも知れませんが。

投稿2018/08/02 23:48

pepperleaf

総合スコア6383

退会済みユーザー

2018/08/03 11:16

ありがとうございます。確かに全てのレイヤーを都度考えている訳ではありませんね（勉強はしていきたいと思っております）。問題があった場合、目の前の問題なのか、それ以前の問題なのか、こちらはまさに仰る通りだと思います。

行動規範の内容に同意します

「コードを読む。コードを書く。それを繰り返せ」が基本ですが、
成長速度が重要、成長を実感できることが重要であればさらに追加で、

「コードを読んでもらう。コードを実行してもらう。それを繰り返せ」

先人、達人、さらにお客様に見ていただくことが重要です。
客観的に認めてもらう、あるいは批判される、
胃から何か出ちゃうようなプレッシャーはいつも嫌ですが、
本当に成長できているか判断するためにはとても重要です。

投稿2018/08/02 13:12

daisuke7

総合スコア1563

退会済みユーザー

2018/08/02 13:14

ありがとうございます。コードを読んで頂く機会を増やしていきたいと思います。

行動規範の内容に同意します

タイトルそのものへの回答ではないです
以前した質問で、非常にためになる回答をいただいているので紹介します。
プログラミングにおける精神的ブレイクスルーポイント
今読んでも新しい刺激がある回答群なので面白いです。

追記
追記見ると、質問の方向性がおかしなことになってますね＾＾；

成長を実感するには、それを測るモノサシが必要です。
とりあえず、モノサシに関して、質問したこともあるので参考まで。
プログラマーの生産管理

投稿2018/08/02 12:36

編集2018/08/02 16:39

退会済みユーザー

総合スコア0

退会済みユーザー

2018/08/02 12:38

ありがとうございます。読ませて頂きます。

行動規範の内容に同意します

しかし、私の仮説においては、これでは全く勉強になっていません。その理由は、

仕組みを理解してこそ勉強であり、なぜ「Hello, World!」を出力できたのか、その仕組みの理解に全く時間が割かれていないため

です。

「コンピュータはなぜ動くのか」という意味でしょうか？
それともコンパイラやインタプリタの動作の仕組みでしょうか？
いずれにせよ、視点を変えて勉強してみてはどうでしょうか。

求めている方向性とは少し違うと思いますが、
ソフトウェア開発者としての考え方を学ぶというのも重要だと思います。
最近の本であれば
「プリンシプルオブプログラミング 3年目までに身につけたい一生役立つ101の原理原則」
がいろいろ書いてあります。
これには出典書籍も豊富に載っているので、気になる本をいろいろと読むというのがお勧めです。
あとプログラムの本としては
「リーダブルコード」
も簡潔でお勧めです。