最近思ったことの雑メモ
目次
- 目次
- 根底を理解して、そりゃそうなるよねって思えるようになりたい
- 自分で考える
- 文を読む前にコードを読む・書く
- これ何やってんのを自問自答する
- 根底を作る
- 全体で何やっているのかを理解する
- 書いて動かして作るが一番身につくなと感じた
- 他人の悪いところ、良いところ、自分の悪いところ、良いところを見る
- 本は消化しきれない
- 迷いをなくす
- お腹が空いていると人はイライラする
- 本来、自分が考えるべきことを、本やyoutubeから得ようとしている時点で「自分スタイル」はできない
- 人の意見を聞かない時点で、自分の意見も聞いてもらえると思わない方が良い
- 今やりたいこと以外のものに対して、無駄に情報収集しない
- 作り出すことに力を入れたい
- お金が原因でやりたいことができないような状況にはなりたくないなと感じた
- 文脈を大切にする
- 言語のコーディングルールはなるべく守る
- 他の人が使いやすいかでコードを書く
- 抽象的なものを実装する力をつける
- 自分が自分を信じる。人を信じる(信じる心)
- 最先端の情報って、結局英語だから、英語をより話せたり、読めるようになりたい。
- セキュリティをもっと知りたいなら、自分で実際に実装してみて、違いを知る。
- なぜ、どのようにして、何を作るかにフォーカスしたい
- 状況に応じた適切なプログラミング言語を使う
- 参考記事
根底を理解して、そりゃそうなるよねって思えるようになりたい
レゴブロックで一からものを作る感じ。これ以上分解できないものから、構築する感じ。これを0から作りたいなら、こう作れば良くね?っていう大まかな全体像がぱっと出るようになりたい。
自分で考える
仕様や公式ドキュメントから、自分で考えれるようになりたい。できれば本とかのサンプルコードとかも写経するんじゃなくて、最後に答え合わせする前提で最初は自分で考えて書けると良いんだけどね。正解は1通りじゃないから。自分で書いた方が頭に残る
文を読む前にコードを読む・書く
結局文を読んで内容を理解しようとするのは無理があるなと感じた。文を読む前に、実際に動くコードを見て、コードを読んだり、動かしたり、作ったりして実際に体験した後に、文を読んだ方がより正確に理解できるなと感じた。論より証拠見たいな感じ。文だけで理解しようとすると、どうしても間違った理解になりがちなのと、いまいち記憶に残らないと個人的には思う。
これ何やってんのを自問自答する
作業の一部分に没頭していると、結局今自分は何をしたいんだろう、何をしているんだろうがわからなくなってくるので、結局今何がしたいの?とかそもそも何がしたいんだっけを自分自身に投げかけて、全体の中で自分が今どこにいて、今何をしているのかを客観視するのが大事だなと感じた。
根底を作る
低レイヤーにいきすぎないだけど、高レイヤーすぎない部分をもっと理解する。
全体で何やっているのかを理解する
全体の各パーツが何をやっていて、それらのパーツがどのように組み合わさって、全体として動いているのかをもっと理解する必要があるなと感じた。
書いて動かして作るが一番身につくなと感じた
コードを自分で書いて動かして、なんか作るのが一番身につくなと感じた。なるべくコードで一から自分の手で自作できれば良いなと思った。
他人の悪いところ、良いところ、自分の悪いところ、良いところを見る
人は常に誰かと比べがちです。比較するんじゃなくて、良い面と悪い面を見たうえで、優劣をつけるんじゃなくて、個性として捉えた方が良いでしょう。上を見たり、自分のしたいことに集中していると、人と比べている暇なんかなくなると思われる
本は消化しきれない
本は消化しきれないし、血肉になりづらいので、本当に読みたいって思うやつだけ買うようになりました。
迷いをなくす
テレビが6チャンと8チャンしか見れないので、チャンネルに迷う時間が減ったなと思いました。それと同じで、選択肢が多いと迷い、そのせいで突っ走ることができない時もあるので、どうでも良いものほど選択肢は少ない方が良いなと思いました。どうでも良くないものは選択肢が多めの方が良いです。例えば仕事とか。
お腹が空いていると人はイライラする
お腹が空いている時ほど、イライラしがちなので、なるべく空腹状態は避けようと思います。
本来、自分が考えるべきことを、本やyoutubeから得ようとしている時点で「自分スタイル」はできない
本やyoutubeに何か大きなヒントがあるんじゃないかと思わない。自分で思考や経験した延長線上に自分のスタイルが存在する。世間一般的な理想に特化したスタイルを求めるんじゃなくて、自分での思考と経験を繰り返してその延長線上に存在するスタイルに到達した方が良い。自分スタイルを作った方が良い。OSS のオリジナルのコードをもっと読み、なんなら作った方が良い。不出来だとしても自分で思考して作ることに意味がある。簡単に答えを見ない。てか一つに定まる答えは存在しない。自分自身の答えっぽいものを自分で考えて作る。思考プロセスが伴わないでできても、実践で役に立たない。本を読んで自分が思考した方が良いものをとっぱらって何か得たとしても、その人自身の思考力が養われるわけではない。
読書の落し穴 | 戦略|DIAMOND ハーバード・ビジネス・レビュー
あなたが人生で、辞めて良かったことを教えていただけますか? - Quora
人の意見を聞かない時点で、自分の意見も聞いてもらえると思わない方が良い
なんかの本で読んで「ハッと」したので、この考え方は大事にしようと思いました。意見とその人自身は切り離して考えた方が良いでしょう。
今やりたいこと以外のものに対して、無駄に情報収集しない
そのエネルギーがあるなら、今やりたいことに集中した方が良いからです。もしくは寝た方が良いです。
作り出すことに力を入れたい
旅行とか体験も好きだが、やっぱ作り出すことが好きだなと、どう作ればリアルに見えるかとか人をびっくりさせられるかとか思考して作るのが好きだなと思った。
お金が原因でやりたいことができないような状況にはなりたくないなと感じた
一つの稼ぎどころにだけ依存するっていうのが、むしろ危険なんじゃないかなと思ってきた。
文脈を大切にする
こういう文脈があったからこういう考え方をしたって理解をする。文脈を忘れて、考え方にだけフォーカスしがち。
言語のコーディングルールはなるべく守る
言語特有のコーディングルールは全開発者共通で理解しているものなので、なるべく守った方が良いでしょう。
他の人が使いやすいかでコードを書く
チーム開発だと特にその意識は大事。
抽象的なものを実装する力をつける
ある程度慣れてきたら、本の文を見たり、図を見たり、仕様を見たりして、それらをコードに落とし込む練習をした方が良いな。正解は一つじゃないので。ただ、最適なものは存在する。答えを見ない。答えは答え合わせの時にだけ見る。自分で考えて解く癖をつける。あと、仮に答えを見たとしても理解すれば一応OK。
自分が自分を信じる。人を信じる(信じる心)
信じられると、人はよりちゃんと行動しようってなる。信用されていないのかって相手に思わせない。
最先端の情報って、結局英語だから、英語をより話せたり、読めるようになりたい。
セキュリティをもっと知りたいなら、自分で実際に実装してみて、違いを知る。
文だけ見ても、記憶に残らないし、実践的な知識にならない。インフラも同じ。テラフォームとかで実際にコードに起こしてみて、初めてわかるものがある。
なぜ、どのようにして、何を作るかにフォーカスしたい
結局言語特有の仕様を深掘りしていくってよりかは、アイデアを考えて、それを実現して良い影響を与えられるのが自分の力で実行できるのが好きだな。言語というか仕組みをもっと知りたいって感じ。だけど、拡張性や保守性のあるソフトウェアとか、他の開発者が使いやすい仕組みを作ったり、インターフェースを作るのも好きだから、速さを犠牲にしてそこをおろそかにするってタイプではない。
状況に応じた適切なプログラミング言語を使う
プログラミング言語ごとに特性があって、その特性に応じて得意不得なものがあるわけだから、状況に応じた適切なプログラミング言語を使う
参考記事
一人でサービス作ってわかった、個人開発における3つの重要なこと - paiza times
こころの中で人を見下してしまう癖を治したいです。どうすれば全ての人に敬意をもって接することができますか?皆さんの意見をお聞きしたいです。 - Quora