一つもやったことないなw
データストラクチャとアルゴリズムは割とガッツリ手を動かしてやった
O(N)はこんなの当たり前だろと思ったら世の中考えてないエンジニアが山ほどいた
Builderだののパターンはまあ見ればわかるっしょ
DDDだのTDDだののデザインパターンは大体Wiki
OOPは英語のJavaのチュートリアル
Web ServiceはSunの本社で計3週間くらい
勉強は仕事中にやる方針
残業はしない方針
こんな感じ
]]>実際はそのまま使われることはあんまないけど現実の仕事でどう考えるかとかもあるし
デザインパターンとかもあるし
大体の新人はそこまで行くはるか手前の環境設定とかでつまるし
]]>毎月給料もらえるからまあいいかくらいのかんじで当然仕事はやる気はない
正直何も理解してなくて雰囲気でコピペしてなんとなく動かす感じ
技術書買って覚えようなんて気は一切ない
今から思うとレガシーな現場ばかりで周りも似たようなマインドの人ばかり
で、今年の4月から別の現場に移ったんだけどそこが意識高い高いの人の集まりで
仕事の内容も何言ってるかわからないし早くクビにしてくんねえかなと思ってた
ある日OAuthが必要になるから会社のPDFの本読んでおいてくださいって言われて
最初は無視してたんだけど、何度も読みました?って言われたからうざくて観念して読んでみたんだよ
どうせ読んでもわかんねえだろと思ってたらなんか内容が理解できたんだよ
理解できると面白いのな
周りが言ってる仕事の内容もわかるようになってきて仕事も楽しくなってきて
コードレビューもしてくれて最初は殺したいくらいうざかったけど
こういうときにこのデザインパターン使うと分岐が減るのか!とか感動したり
調子に乗ってそのあたりの本を立ち読みしたり買ったりしたら
やっぱり読むたびにわかってきて楽しいんだよ
仕事って楽しいんだな、早く仕事したいって思うくらい
おれのこの無駄にした10年はなんだったって思う
もっと真面目にやってればなあ
]]>レベルの低いフリーランスエンジニア多すぎ
ギリ動くっぽいものを書ける程度で、うちじゃ仕事にならないんですけど?
デザインパターンとかアーキテクチャーの説明しても話も理解できず
聞いたことありませんがお決まりの回答
もうまかせられる仕事がないのだが
フリーランスといえど、契約前の技術試験は必須やね
詐欺の斡旋業者が増えすぎて、この市場は崩壊した
]]>ディストリビューションロックとかAIはもっと突っ込んだアルゴリズムの話だよね
「マスター」してるなら当然出来るだろ?
その上で圧倒的なコーディング能力とか新しい物を身につける早さとかも勝負だぞ
じゃなきゃ若い奴に舐められるだろ
]]>なんでエンジニアなのに矜持が技術じゃないねん
”Web”エンジニアってなんや
それだけやっててフロントちょっと弄れますとかならそりゃ職ないぞ
大学院でてるならアルゴリズムとかデータストラクチャとかOOPとかアッセンブラとかデザインパターンとかはがっちり出来るのか?
]]>そんなの勉強のうちに入らなくて廃れたらすぐ他のを覚えられるということ自体がスキルなのと
アルゴリズムやらデータストラクチャやらAIモデルやらプログラミングパラダイムやらデザインパターンやらの実際の勉強とトレーニングもいるのとでまあいろんな職種のなかでトップレベルに覚えること訓練することは多い職
ワードプレスでサイト作れますレベルの「ITエンジニア」も確かにいるけどそれだと数年で全く通用しなくなって他のをやり直す羽目になることが多いので勉強云々になるんだろう
そんな数年で変わらない業界のが多いわけで
]]>例えばフロントならReactなどのフレームワーク 10年前はJQueryあたりで法改正どころではないくらい違う
そもそもフロント自体がテンプレートエンジンからSPAへと大きくかわっている
スマホも10年前なら普及率1/4くらいでサイトのターゲット自体がPCからスマホに
2013だとJava7だけどJava7と8も大幅にちがうので8やった事ない人が今の俺のコード読んでも読めない
いまはクラウド当たり前だけど10年前ならまだまだオンプレでこれも法改正どころではないくらい違う
AIも全然話題じゃなかったしこれは線形代数や微分からやり直したけど何ヶ月もかかった
これにからんでPythonの興盛 まあ新言語1からやるのが大きな法改正くらいだろうか
C++がRustになんてのも俺はまだ手を出してないけどある
開発手法で言うとこの10年のウォーターフォールからアジャイルへの移行で仕事の進め方が他業種に転職以上に変わってる
このほか変わったことではないけれどアルゴリズムやデータストラクチャーデザインパターンなんかは本ちょっと読むだけじゃなくて実際に手を動かして体に身につくまでやる必要がある
普通に大量にあるな
「ITエンジニア」もピンキリだけど「自己啓発の本読むのも勉強」のレベルでは確実に俺の仕事は無理
そっちこそそういうのは中高生で卒業しよう
]]>このコードを見た他人はこれでコードがやってることや意味がわかるだろうか?
それをわかりやすくするためにはどのようにコードを書けば良いのか?
こんな書き方をしたら後任が何か変化点を加えるときに不具合に繋がらないか?
そういうことに思いを馳せることができる人って要はコミュ力高い人、共感力の高い人だよね
で、その力が足りない人はデザインパターンや各種原則の重要性を理解できなくて、テキトーにやり始める
結局どの業界も人の立場に立って考えられる人が重要なんだな
]]>COBOLでコーディングすらできず、GoFデザインパターンすら理解して無い奴がシステムエンジニア名乗ってんだぜ?
]]>「この説明、よくわからないな」と感じたときにふとChatGPTを使ってみるかと思い
"プログラミングのデザインパターンであるBridgeパターンのサンプルコードをRubyで書いてください”
と入力してみると、なんと購入した技術書と同じくらいのコードが返ってきた。
しかも言語までこちらの都合に合わせてくれる。
ただ、理屈がまだわからないから文章で説明してもらうことにした。
入力中に先程の回答の文章部分が英語だったことを思い出したので
"プログラミングのデザインパターンであるBridgeパターンについて教えてください
日本語で"
と最後に適当に要求をつけて送信。
するとわからない部分が腑に落ちるような回答が返ってくるではないか。
この体験からふと入門書は必要ないのではと思った。
もう少し詳細に指定するならば
「入門書レベルの、知らないことを知ってる事柄の理解に関してはChatGPTで十分に学習可能」
ではないだろうか。
このデザインパターンにしても
例えばFacadeやらBridgeやら名前だけは知ってるが
詳細についてはつかめている気がしないという状態の人間は多く存在すると思う。
これらの名前についてはデザインパターンとググるか、ChatGPTあたりにでも確認すると
恐らくすべて確認することができるだろう。
そんな中で「デザインパターンを猫でもわかるように解説するぜ!」
みたいないわゆる入門レベルの書籍、記事はそういった情報が欲しい人にとって必要だろうか。
私はそうは思わない。
とはいえ、技術について語り合える友人は少ないし、ほぼ独学でデザインパターンも学び始めたばかりで
視野が狭い状態でもあると思っているので自分の中でこれが覆るまでは自分は入門書の購入は止めるようにしようと思った。
]]>もしくは「(旧システムの)○○画面みたいにしてよ」という老害の一声でクラサバ時代に逆戻りするカビの生えた職場の話
]]>低レイヤは解像度が悪いのでまるでボロボロかもしれん、分散処理も同様
色々ご指摘ありがとう
RISCVでもそうだけど網羅的に書こうとすると収まりきれなくなるので、あえて選別してるものもある(デザインパターンの項目とか統計とかセキュリティの項目とかは)
線に関しても、本当は派生・具体化・細分化などによって線の種類も変えるべきだろうけど、このツールではそれは限界だった。
]]>まあ PHP はその「新しいアイディア」をどん欲に取り入れ続けている言語だから、けっこうそれだけで満足してしまう気持ちは解る。でも「今の自分の知識だけで、たいていのものは作れるからなあ」と思ってしまうと、たぶん勿体ない。あなたが将来、未知のプラクティスやデザインパターン、アルゴリズムを発明しないと断言できないのだから。
PHPer ならマニュアルの例文で散々お世話になっている「干し草の山」と「針」のたとえ話で言うと、次のような感じ。
https://kenbi.ti-da.net/e3637076.html
アインシュタインはあるとき、
「博士とわたしたちその他大勢との違いはなんですか?」という質問を受け、
こう答えました。
「たとえば、干し草の山から針を探さなければならないとします。
ほとんどの方はたぶん、針が1本見つかるまで干し草の中を探すでしょう。
私は、針が全部見つかるまで探し続けると思います。」
※ PHP ですでに作られたものは膨大なので、そのメンテナンスも今後何十年は無くならない。仕事にあぶれることはないと思う。
]]>・切削加工はけがき、フライス盤、ボール盤、くらいならできるが複雑な形状は作れる気がしない。そういえば旋盤は使わなかった。耐久性を考えなければ3Dプリンタでなんでも作れるらしいが、3Dプリンタは触ったことがない。
・CADは大学の演習でSolidWorksを触った程度。もうすっかり忘れている。手書きの製図とかは調べて思い出せば簡単な形状ならできるかもしれない。
・シミュレータはANSYSをマニュアル通り触った程度。動力学解析とか連成解析とか仕組みは全くわかっていない。
・電気工学はだいぶ勉強不足。簡単な回路図はチップの製品情報を睨めっこしながらINとOUTと接地をどうすればいいかくらいはわかったが、複雑なものになるとダメ。ArduinoとRasberryPiは買ってみたが埃かぶっている。論理回路の読み方はすっかり忘れているが調べれば思い出せると思う。
・化学系は全くの無知。大学受験で知識は止まっている。物性物理的なところも無知。
・数値計算はPythonやMatlabでちょっとできる程度。ライブラリを使った行列計算や簡単なニュートン法くらいなら書けるが、精度や速さが必要だったり複雑になるとダメ。解析は微分積分や常微分方程式を調べて思い出せばできる程度。測度論とか特殊な積分とかいわゆる大学数学的な道具が必要になる解析はできない。
・競技プログラミングはちょっとかじったがやめてしまった。むずかしすぎた。
・機械学習や統計はなんとなく知識はついているが、手を動かして何か作ったことはない。この前統計検定1級落ちた。
・バックエンドはSQLをそれなりに書いてとりあえず動くものなら書ける程度。可用性とかパフォーマンスとか考えられるレベルではない。JavaはJavaEEを横展開的に書いた程度。理解できている自信はない。保守性高めたりデザインパターン的に綺麗な書き方とかできない。C++は一瞬だけ触ったことがあるが、環境構築ハマった&謎のSegmentation Faultで苦手意識を残したまま。Go?Rust?なにそれおいしそうだね。
・クラウドはAWSをマニュアル通りに使っている程度。1から設計なんてできない。なのでAWSのソリューションアーキテクトを勉強中。AzureやFirebaseは触ったこともない。
・ネットワーク系とかセキュリティ系は全く勉強不足。応用情報をギリギリ合格できる程度の知識しかない。わかるようにはなりたい。
・フロントエンドはFlutterを勉強中。Flutterむずかしい、どんな言語でもそうだけどチュートリアルから業務レベルまでの乖離がありすぎてよくわからない。javascriptはjQuery一強時代にちょっと書いた程度。VueとかReactとかなにもわからない。TypeScript?なにそれおいしそうだね。
・ハード系だったりファームウェア系だったりコンパイラ系は何もわからない。わかるようにはなりたい。
全部中途半端だな、、、
]]>278あとで/1848users セガがjavascriptでぷよぷよを作るプログラミング講座を出しているが、とても良いプログラミングの教材になっている「写経はとても大事」 | Togetter
238あとで/1666users ジャズのコード進行の原理 - アラクー Arakur
228あとで/1260users ソフトウェアエンジニアなら3秒で理解できる NFT 入門 - Okapies' Archive
220あとで/1885users Adobe製品と同じような事をフリーソフトでやりたい場合の対応表がすごく使える→他にも高機能なフリーソフトが集まる | Togetter
211あとで/1407users 「Visual Studio」の中の人が作ったプログラマー向け十徳ナイフ「DevToys」/今までググって探していたツールがひとまとめに | 窓の杜
210あとで/3113users ゲームの勝敗でかんしゃくを起こす子どもにできることは大人げない大人になること|フィンランドワークショップomena|note
201あとで/1188users 総務省「誰でも使える統計オープンデータ」無料オンライン講座スタート | ITMedia
198あとで/960users プログラムがメモリをどう使うかを理解する(1) | rita | Zenn
196あとで/1262users 仕様書の参考例と、こんな内容を仕様書に最低書くといいというお話|田辺めぐみ|note
189あとで/973users フロントエンドのデザインパターン | Shinya Fujino | Zenn
187あとで/1551users 英語面接で5歳児みたいなことしか言えないからカッとなってWebサービス作った【個人開発】 - Qiita
187あとで/1563users TOEIC満点ホルダーがやっているおすすめ英語学習法(2022年版)|Shin|note
177あとで/1554users 207で1年間磨き続けた1on1のフォーマットを公開します|207株式会社|note
171あとで/1530users エンジニアの"有害な振る舞い"への対処法 - Qiita
170あとで/1316users 顧客との打ち合わせが上手い人がやっていること|いまにし|note
165あとで/1551users 「この会社は詰んでます。潰れました」で気づいた“恥ずかしさ” DeNA南場智子氏がエンジニアから学んだこと | logmi Tech
158あとで/1342users 「勝手に学ぶ人」と「期待されて学ぶ人」の差が埋められない|柴田史郎|note
153あとで/1343users 強いエンジニアになるために英語が必要と聞いたので4ヶ月でTOEICスコア400→900まで上げた話 - Qiita
148あとで/1190users なぜ40歳を越えると「やる気」が出ないのか? 「中年の危機」を乗り越えるためのエンジンの回し方 | 野水克也, 萩原雅裕 | logmi Biz
148あとで/955users ITエンジニアが投票した「ITエンジニア本大賞2022」ベスト10発表。「シェル・ワンライナー160本ノック」「モノリスからマイクロサービスへ」「恐れのない組織」など | Publickey
142あとで/690users JavaScriptを遊び尽くす究極のWebサービス・ツールを厳選して大公開! - paiza開発日誌
138あとで/891users そこまで努力しないで生活をちょっと改善する100の方法 | 英紙が元旦に紹介 | COURRIER
137あとで/1237users 問題職員の正しい辞めさせ方 1/10 | anond.hatelabo.jp
136あとで/635users フロントエンドを集中的に学習できる究極の無料リソースを厳選してみた! - paiza開発日誌
133あとで/768users ミーティング・ファシリテーション入門 / Introduction To Meeting And Facilitation | ストックマーク株式会社 iwashi | SpeakerDeck
126あとで/1056users Future社員が使っているWindows便利ツール(新人さん向け) | フューチャー技術ブログ
126あとで/802users 『データ分析のためのSQL勉強会』資料公開|高橋 光|note
126あとで/859users エンジニアを始めてから便利だったツールまとめ | nakaatsu | Zenn
125あとで/757users 2022年におけるフロントエンド開発のベースライン - LINE ENGINEERING
123あとで/1202users 50歳になってようやく気付いた、人生で重要なことと、後悔したこと。 | fujipon | Books & Apps
123あとで/1055users 【必読】総務省直伝のExcelマニュアルが目から鱗が落ちるものだった | Togetter
ジャズのコード進行を解説したブログが2位になった。はてブでこんなページを目にできようとはとブクマカが驚愕。
COURRIERの「そこまで努力しないで生活をちょっと改善する100の方法」はペイウォールの向こうに行ったが原文は読める。 https://www.theguardian.com/lifeandstyle/2022/jan/01/marginal-gains-100-ways-to-improve-your-life-without-really-trying
]]>難しいことはいいから、今俺が悩んでいることを具体的に解決してくれる本が欲しい。答えが欲しい。難しいことは分からない。お前が非エンジニアなのになぜそんなに詳しいのかも分からない。
世界は俺が理解できる世界ではないのかもしれない。バグが埋め込まれている。俺か世界のどちらかに。
]]>非エンジニアの身からすると、クリーンアーキテクチャとかドメイン駆動設計とか古いやつだとMVCとかそういうデザインパターンの本も結構色々あると思うけどそういうので不足するようなもんなん?
というかアーキテクチャに関しても抽象化すれば
・どこに着目して分割するか
・疎結合と密結合でどの部分を分離してどの部分をどちら方向に依存させるか
みたいな話だと思うから、そういうのを意識すればブログとかでも情報十分拾える気がする。
あくまでも非エンジニア目線だけど。
]]>基本的に現在では、バックエンド・フロントエンド・運用保守全てができないエンジニアに価値は無い。
経験者でも、これらができない/わからないのは、相当恥ずかしいことだと思った方がいい。
典型的はてなーな意識の高さ。
上がってるような基本(元増田に上がってるやつの倍ぐらい)が全部立ち上げからできて
2〜3個プロジェクト経験したらテックリードの素養が既に身についてそう。
つまり、ただのエンジニアにはそこまで要求されない。
プロジェクト的にもどっちかが弱いと
Rails/DjangoにjQuery+Bootstrapみたいな構成や
Amplify/FirebaseにVue/Reactみたいな構成も全然あるので
フロントとバックエンドも一旦はどっちかでいい。
面接はなんとか抜けてもらうとして、
チーム開発での最低限の目標としては、
成果物から、指導、学習コスト、レビューコスト、技術的負債、マネジメントコストを引いた分が正になっていれば
ひとまず「チームに居ていい人」と見なされそう。
チーム的に良くても、経営層にそれで許されるかはわからんのでその辺の立ち回りも上手いことやるとして、
一旦は、正の生産性を目指してほしい。
以後、ブコメで誰一人一ヶ月でできるって言ってなくて笑うので、
一ヶ月というのは無視して、三〜六ヶ月程度をイメージしつつ書いていく。
これだけで一ヶ月経つ気がするが正気か。
似たような言語なのでどっちからやってもいいし、両方同時にやってもいい。
どっちかしかやらないならJavascriptがおすすめ。後ででてくる、Flaskは適当にExpressとかに置き換える
現場だとほぼTypescriptなので、Javascriptはある程度慣れたらTypescriptに移行したほうがいい。
どちらも、Python2とES2015以前の記法というレガシーがネット上に転がってるので参考にしないように注意。
パッケージ管理、単体テスト、タスクランナー
この辺は6のフロントフレームワークと同時にやる。
コードは断片的なサンプルではなく
・一貫性があって
・正しい書き方がされた
お手本プロジェクトをなにか(githubや書籍など)で手に入れて読むべき。
おそらくフレームワークに乗っかっているので並行して進めることになる。
話の流れで先にこっち
現在のコーディングのグッドプラクティス、デザインパターンはフレームワークの形をしている。
なので、ReactとVueをその思想から理解しきれれば、プログラミング言語の潮流の最先端に追いつけるはずだ。
とはいえ最低限としては使い方が分かるところまで。
TypescriptもVue.jsも書き方をどこまで取り入れるかが使用者の裁量に任されてるし、
開発でVueとReactのどっちを使うかはチーム次第なので、
一旦React+Typescriptでガチガチに書かれたコードプロジェクトを拾ってきて、必死で解読するのがいいと思うなー。
2割ぐらいわかった気になればチーム入ってから(React, Vueどちらだったとしても)動けそう。
パッケージとかテスト、タスク&デプロイ辺りもこのタイミングで拾ってきたプロジェクトを使って学ぶ。
バージョン管理とコンテナの思想が優れているのは自明なので、これらはツールと見ていい。
そして、後からプロジェクトに入った人がプロジェクトの流儀に沿って使う分には難しいことはなさそう。
採用に来た人がgitとかわかってるとチーム開発経験者だなーって思うし、知らないと未経験者なんだなーって思うし、
そういう意味ではチーム開発の経験があるかどうかの試金石にはされてそう。
構築できる、ではなく、触れる程度で良さそう。
gitはプロジェクトの流儀によると書いたが、git-flowのイメージ図を理解して運用できるのがよい。
https://qiita.com/KosukeSone/items/514dd24828b485c69a05
これは「パソコンの使い方わかってますか」ぐらいの温度感。
ファイルやパーミッション、ユーザーやプロセスのような基本概念を理解する
一冊読めば済むだろうし、概念系はさらっておいてほしい。
grepやfindやxargsなどのコマンドを組み合わせて簡単な処理を自動化する
こういうのができるんだなーって言うのを知っておいて、調べつつ書ければ十分。
sedとか正規表現も。
あとはシェルスクリプトとかって思ったけど同様のことはPythonでもできそう。
IPアドレスを調べたり、SSHでリモートマシンにログインする
地味にSSHでログインした先の環境だと、vimが主要なテキストエディタになるので
vimを最低限触ることだけ要りそう。もういらないかもって思ってたんだけどなー。
→ ファイル開いて入力モードに切り替えて書き込んで保存して終了
をチュートリアルする。拡張とかはいらない。
細かく書いたが、LPIC-1の範囲がほどよくまとまっているのでそっちを参照するとよい。
フレームワークを覚えること自体が重要なのではなく、Web開発の基本を習得することが重要。
これが意図なら
HTTP、ルーティング、データベース、SQL、認証、セッション管理などは当然すべて覚える。
この辺の機能を持った小規模Webアプリを作ってHerokuでデプロイすれば一旦完成とみなしてよさそう。
コード書き写しただけにならないようには注意しつつだけど、長く見て5人日ぐらい?
慣れると1日あればいけると思う。
フレームワークもなんでもいい。
軽量である必要もなくて、
Djangoとかでも各コンポーネントがどんな働き方してるか程度はわかるだろうしそれで十分。
余力があれば複数個触ってみたり、人から勧められたらそっちでも。
最近はサーバーレス&NoSQLが流行ってるのでFirebaseとかもやればいいと思う。
コメントツリーが荒れててウケる。
実務プログラミングで最低限必要なアルゴリズム力は
「書いてるコードの計算量オーダーを把握していること」
に尽きる。
計算量を気にしなかったせいで線形検索メソッドとfor文を組み合わせて
O(n^2)やO(n^3)のロジックを書いてしまって
データ量が万〜十万の本番データで遅延するとか
それらに対して分散や非同期処理で解消しようとするとか、
ちょっとでもアルゴリズムを触った人ならアホらしいなって思うような行為を
アルゴリズム不要勢は平気でやるぐらい、両者は溝が深い。
計算量を意識するだけなら、AtCoderのABCのC〜D問題辺りが解ければ十分。
有名な脆弱性や攻撃手法は、ほとんどフレームワーク等で解決手段が用意されている
(XSS対策の自動エスケープなど)
のでアドリブをせずに正しい書き方でやれば良い。
開発現場でもセキュリティリスクがある箇所を1から自前で実装することを経験が浅い者にはやらせないので、
ただただ、フレームワークが正しいとしているやり方をなぞるのが良い。
開発の勉強のやり方としては、
・正しいコード見本を手に入れること
・公式のリファレンスを読むこと
・エラーメッセージを読むこと(そしてググること)
この辺りの習慣があればやってけんのかな、
その他、チーム開発って面では
アジャイルサムライ(プロジェクト管理)とか
TeamGeek(人間性)とかインプットしておくと共通言語が増えて嬉しい。
この方向で進めてけば、その途中で正の生産性≒足引っ張らないぐらいになれるので、
そしたらやってけるんちゃうーって感じ。
]]>IoTとか言って、モノを重視するのは前時代への退行だよ。
デザインパターンとか言って、世の中や人間を型に当てはめたがるのも気に食わないね。
これからは心の時代だ。プログラミングも、心を重視すべきなんだ。
]]>俺は数学やアルゴリズムよりも言語そのものの知識とデザインパターンを正確に組み合わせることが出来るエンジニアの方がいいなと思う。
そこで話通じない方が辛い。
数学・アルゴリズムは専門性が高い分野の話かなと思うかな。
ゲームや AI ・ロボット系とかなら必要だけど。
]]>情報科学専攻で半年か一年かけてやる程度の内容だが、他のほとんどの科目でもそうであるように、要領の良い奴なら数週間でマスターできる。
実際、世の中にはこのレベルの奴なんか珍しくもなくいる一方、Pythonチュートリアルレベルの文献を数ヶ月かけても前半数章すら読めないような奴もいて、そういう奴が「プログラマになりたい」とか言ってる。本当に社会の迷惑。やめてくれ
]]>https://anond.hatelabo.jp/20200521094135
もっと前からかな
]]>たとえば、C言語のポインタが難しいとよく言われる。まあ、中学生や高校生がはじめて学ぶならともかく、あんなもの別に難しくはない(実際のソフトウェアでポインタを適切に使うことは難しい)。
実際、ポインタに躓かなかった人なんかたくさんいて、そういう人の一部はより高度なことをどんどんやっている。一方、ポインタに躓いて努力してやっと最低限のレベルに達したような人が、声を大にして「プログラマになるなら、ポインタくらい理解しないとな」とか言ってる。
GoFのデザインパターンもそうだ。
プログラミングのセンスのある奴はすぐ見抜けることだが、アレには何の重要性も無い。だが、頭の悪い奴は、あの程度でも苦労しないと覚えられないから、重要だと思ってしまうらしい。これはギャンブルや宗教にハマる心理と同じである。つまり、時間や労力をかけたのだから、その対象にそれに見合う価値があって欲しいと思うわけだ。
頭が悪いと、こういう意味で物事を客観的に見られなくなる。学歴コンプレックスになると、一生そのことを引き摺って、何に関しても学歴と絡めて論じたくなるようなものだ。
]]>