  |
はてなキーワード: javaとは
在籍期間は約2年。これは組織に所属する期間として短いものかもしれない。
たった2年である。されど2年。鬱憤が溜まるには十分すぎる時間であった。
新卒採用ページの初年度年収は嘘である。個人的に一番不満のあった点なので最初に触れておきたい。
ヤフーの新卒採用ページを見ると以下のように書かれている（修士の場合）。
（2019/08/01 時点で修正されていました）
私の「初年度」という言葉に対する解釈「4月〜翌年3月の12ヶ月間」が正しいのであれば、この内容は誤っていることになる。
実態から言うと、初年度年収は468万ではなく410万あたりなのだ。
重箱の隅をつつくような指摘と捉えられるかもしれないが、私としては見逃し難い点であったので深掘りしていく。
これが誤りだと主張するに足る最も大きな理由として、初年度の社員は年2回ある賞与のうち1度しかもらえない事が挙げられる。
ヤフーでは4月と10月が賞与月であり、それぞれ基本給の約2.5ヶ月分の賞与（評価によって多少変動するが初年度の変動はなし）となる。
ただ、新卒社員は4月にもらうことはない（仮に6・12月タイプだとしても、通常6月にもらえるのはいわゆる寸志だろう）。
つまり、
(242,000 + 47,266 ) × 12 + 242,000 × 2.5 × 1 = 4,076,192
いかがなものだろうか。主観ではあるが、60万前後の差額は無視しがたい。少なくとも当時の私にとっては大きな額だ。
ではここで、上文に書かれている「賞与等」の解釈を変え、残業時間を考慮している路線を考えてみる。
条件として、最初の4〜6月は全体研修で残業が許されていないため、7月から3月の9ヶ月でできる残業時間が対象となる。
また、残業時間が45時間を越えていいのは年6回まで、かつ上限は80時間である。
加えて、初年度の1年間での昇給は基本的になかったので、1時間あたりの残業代は固定とする。
これを踏まえた上で計算してみる。
「25時間相当分の固定時間外手当47,266円/月」とあるので、残業は1900円/時となる。
80時間残業を半年間続け、残りの3ヶ月は45時間の残業をしたとする。
1900 × ((80 - 25) × 6 + (45 - 25) × 3) = 741,000 円/9ヶ月
これを先程の4,076,192円に加えると、4,817,192円である。
なんと、468万を超えた。失敬。
「新卒採用ページの初年度年収は嘘である。」と冒頭で言ってしまったが、嘘つきは私のほうだった。
さて、これを読んでどう感じただろう。
こんなことはよくある、で済ませていいとは思わない。
（「残業80時間を年6回なら別に苦ではない、むしろこの業界なら当たり前では」といった類のコメントは一旦跳ね除けさせてほしい）
それに45時間を1度でも超えれば上長から指摘を受けるし、6回も超える事例が実際にあるのかと言われれば極めて少数派である。
このような書き方がされていれば新卒1年目にもらえる下限年収のように感じても不思議ではない。少なくとも私はそう感じていた。
これはいつだったか転職ドラフトで炎上していたときと同じ流れだ。
[転職ドラフト経由でY社の内定貰ったけど](https://anond.hatelabo.jp/20160925170021)
正しい情報をミスリードなく伝えるのが企業としての在り方ではないだろうか。
最初の2週間はビジネス・エンジニア・デザイナーの3職種合同で様々な研修を受ける。研修の内容は多岐にわたり、当然ビジネスマナー研修もあった。
研修中初期はPCを開くことを許可されておらず、みんな紙にメモをとっていた。自分はメモをとらなかった。
6人で1つの机にまとめられ、座学の合間にやたらと個人ワーク・グループワークを要求される。特にグループワークが苦で苦で仕方がなかった。
グループワークは、都度いくつかのグループが話し合った内容を発表するよう当てられる。
話し終えると「はい、拍手！」と司会役を務める人事の方が声をかける。そして拍手。
約300人が回答者に向かって一斉に拍手するのだ。時代錯誤も甚だしい。
この研修を通して、付箋とペンに対してアレルギー反応を示すようになった人も多いと思われる。
今年度でもその形式が続いているのであれば退職希望者を増やすだけなので早急にやめたほうがいい。
そして、全職種合同の研修を終えた後はエンジニアのみに用意された研修が続く。
内容は外部講師によるLinux研修・Java研修・チーム開発と
先に言っておくと外部講師による研修は残念すぎた。不要。不毛。不服。
まずはじめにWindows PCを貸与され、それで戦うことを強要される。
一方で、ヤフーでの業務に使う貸与PCはエンジニアならMacのみである。なんということだろう。
そして外部講師企画のチーム開発は「雑に集めたメンバーでハッカソン」というタイトルが正しい（ここでもまだWindowsのまま）。
Linux・Java研修で学んだ内容を活かせる場面は決して多くなく、チーム内の優秀な人がひたすらにリードする形式だった。
チームによってはリードされる側は「なんかすごいのが出来上がっていく（が仕組みはよくわからない）」、リードする側は「この時間に意味があるのだろうか」と誰得な雰囲気が出来上がる。
その後、チーム開発研修についてもフィードバックする機会があったのだが、
とある同僚は
チームメンバーにgitの使い方を教えないといけない場面があった。gitコマンドに初めて触れるような人をエンジニアとして採用するのはどうなんだ
というコメントを残していた。
なかなかに攻めているなと思ったものの、振り返ってみれば全くそのとおりである。
gitコマンド触ったことない=初心者、が必ずしも成り立つわけではないがWeb系業界のエンジニアにはある程度当てはまるのではないだろうか。
同僚のコメントも受け、採用サイドに苦言を呈するのであればクックパッドの方の言葉をそのままお借りしたい。
クックパッドでは、新卒であってもプログラミング未経験者は基本的にエンジニアとしては採用しません。
なぜか？というと、学生のうちにプログラミングやソフトウェア、あるいはサービスを作る事に興味を持ち、それを仕事にしたいと思っているのに、手を動かさない理由はないんですよね。
[クックパッド 星氏「新卒でも技術力を重視、尖ったエンジニアはエキスパート枠として採用」《新卒エンジニア育成カイギ その5》 |](https://blog.codecamp.jp/engineer-training-cookpad-part1)
また、ヤフーが「世界に通用する tech company を目指す」と謳っていることも踏まえる。
今でも不思議でしかたないのは、私の知る極めて優秀な後輩2名がエンジニアとの面接に行く前に落とされてしまったことだ（当時の面接フローは人事→エンジニア）。
もちろん、最初の面接で受け答えがうまくいかなかったのかもしれないが、それならそれで持っている技術の良し悪しをはかる以前に「面接うまい人材」が重視されていることにほかならない。
技術さえあれば、コミュニケーションができなくていいと言っているわけではない。
一方で、面接で落ちたからと言ってコミュニケーションがとれていない、とも思わないが。
ことエンジニアの採用に関して言えば、GitHubやホワイトボードコーディングで見られる技術に関する蓄積や瞬発力、
リサーチャー寄り（機械学習エンジニアなど）であれば関連領域の論文実績等に比重を置いてもよいと思う。
もちろん、採用する側が手を抜いているわけでないことは重々承知している。
ヤフー含め、多くの企業が採用に苦戦していることを鑑みると、採用そのものがとても困難なプロセスであることは明らかである。
加えて、GitHub等を見たとしても応募者の技術力を正確に測ることは難しい。
ただ「世界に通用する tech company を目指す」 のであれば、まず人材の技術力ありきではないだろうか。
ヤフーにはヤフーの採用戦略があり、一個人が偉そうに言えるものではないので（十分語り尽くしているけれど）このあたりで大人しくする。
研修の虚無さについて書いているつもりが、いつの間にか採用云々についてヒートアップしてしまった。
無理やりまとめるならば、研修・採用において間違った方向に舵が切られていると感じた次第である。
ただ多くの人が納得のいかない評価制度は直ちに改善されるべきであり、決して惰性で運用されてはならない。
ここではこの4月に廃止されることになったバリュー評価に触れる
（採用ページからもバリュー評価に対する言及が消えていることは確認済み）。
廃止されたからこそ、この場を借りて言いたい放題言わせてほしい。
ざっくり言えば、ヤフーのもつ5つのバリューに沿って360度評価、である。
Japanese Traditional Big Company の実施する年功序列よりは億倍まともだし、360度評価といえば聞こえはいいが、
このバリュー評価がきちんと機能していたかと言われれば疑問符が浮かぶ。
[Yahoo! JAPANのミッション・ビジョン・バリュー - ヤフー株式会社](https://about.yahoo.co.jp/info/mission/)
謎だ。
やはりわからない。
重複しているようにも感じるし、「やりぬく」あたりはもう一つのパフォーマンス評価（説明は割愛）が担っているようにも感じる。
各々によって解釈も異なるはずである（もし社員で認識が合っていたのであれば今すぐに全力で謝罪する）。
加えて、昇給額の上限がある程度決まっており、いくら成果を出そうと結局のところ全社的にはそこまで大きな差がつかないようになっていた。
本当にとびきり優秀でなければ従来の枠組みを越えることはない。
先輩社員も口をそろえて言っていた。
給料を大きく上げるなら転職したほうが早い、そして数年経ったら戻ってこればいい、と（実際、自分の場合は550万 → 700万の転職となった）。
これはおそらくヤフーに限った話ではなく、転職による給与ハックがWeb界隈全体に蔓延っていることに起因するので仕方ないともいえる。
閑話休題。
いろいろな経緯のもと、この4月より廃止となったバリュー評価。
今ではパフォーマンス評価のみになったが、やはり評価に対する不満の声はいくらでも聞こえてくる。いくらかマシになったのかもしれないがやはり難しい。
世はAI時代。院卒の新入社員は、多くがデータサイエンス部署なるものを志望していた。
学部卒でも志望している人は少数ながらいた。
しかし蓋を開けてみると、ほとんどはデータサイエンスに全く関係ない部署に配属となった。
データサイエンスの部署に限って言えば、一番必要なのは東大もしくは京大を出ているか、そうでなければ運である。
学歴である程度決められていたように感じるデータサイエンスに焦点を当てたが、ミスマッチという点でいえば他の領域でも多少は起こっていた。
1ファイル数万行のphpファイルを運用しているようなレガシー極まったハズレ部署に配属される可能性もある。
こればかりは巨大な企業なら日常茶飯事かもしれないが、現実を受け止めるにはどうしても時間がかかる。
最後に、社外の人から見れば些細なこと、しかし多くの社員が日々思っていることであろう不満で締めてみたい。
毎朝絶えること無く形成される長蛇の列、まさに地獄絵図。阿鼻叫喚とも言える。
ヤフーでの出勤の定義は「執務エリアに入り社内Wi-Fi下で打刻アプリを起動しボタンを押下」である。
これを10:00までに行わないといけないのだが、入り口のエレベータまわりでは9:40あたりから徐々に変化が現れる。
気づけば、建物に入ってから執務エリアに着くまで10分以上要することになる。
つまり、この行列の待ち時間も計算に入れて通勤しないといけないのだ。
これを毎日経験するのは気が滅入る。ただでさえ電車通勤で疲弊しているというのに。
もっと余裕をもって出勤すればいいのでは、という声もあるだろう。ごもっともである。
しかし、時間をずらせばずらすほど電車の密度は増加してしまう。
これもできるのであれば避けたいし、個人的にはエレベータ行列の方が鉄の箱にすし詰めされるよりマシであった。
では、徒歩圏内に住むというのはどうだろう。
これも金銭面で相当にきつかった。
仮に自転車圏内だとしても、私の求めた最低限の生活（風呂とトイレに行きたいときにいける）を送るには80,000円を軽く超える。
家賃は手取り月給の1/3程度が目安とよく言われているが、就職を期に上京してきた自分の金銭感覚からすると家賃に80,000円を払う決断は最後までできなかった。
そして近くに住んでいたとしても、電車通勤から解放されるされるだけで、早く出ないのであれば結局エレベータ行列に悩まされることになる。
ということで、この惨憺たる状況に対する企業側の動きにも触れておきたい。
結論から言うと、行列に対する直接的なアプローチは何一つ無かった。
社内チャットツール（≠slack）のどこかで議論されていたりもしたが「待ち時間に何か楽しめるものがあればいい」というのもあり、根本を解決できそうにない。
うまくたとえられているかわからないが、「料理が不味い」ときに「美味しく感じられるよう空腹にする」というものが近い。
唯一の救いは、月5回まで利用できるリモートワーク制度である。
が、ヤフーはリモートフレンドリーであってリモートファーストではないし、みんながみんなリモートワークに慣れ親しんでいるわけでもない。
加えて、エンジニア・デザイナー職だろうとマネジメント業務を担い始めた途端にリモートワークは難しくなる。銀の弾丸ではないのだ。
話が発散しているが、エレベータ行列は悲惨であった、言いたいことはただそれだけである。
当然である。がポジティブな面は調べてもらえればいくらでも出てくるので割愛する。
様々な制度はメディアで幾度となく取り上げられているし、給与についてもvorkersや有価証券報告書をみればだいたいわかる。
優秀な社員もたくさんいるし、サービスの規模的にもやりがいを感じられる場面は多いはずだ。
そして、悪いところをずっと放置し続けるような企業でもない（と信じている）。
まとめるにも思い思いに書きなぐっただけなので特にメッセージもない。
外部ライブラリが果てしなくあり、
← それはPythonに限ったことじゃないでしょ。JavaでもRubyでもPerlでもCでも同様。主要言語はほぼそうでしょ。
それはむしろ逆。Python のスローガンは There's Only One Way To Do It で、これは Perl のスローガン There's more than one way to do it. を意識したもの。
https://wiki.python.org/moin/TOOWTDI
なお、個人的には C# は良さそうだなとは思うけど、Windows以外のプラットホームではどうなんでしょう。（よく知らない。） これは Visual Basic についても同様。
新しいことなんてないところに行けばいい。
今でもVB6やらピュアなPHPやらJavaやらで作られたシステムを保守したり
← いやいやw それは40年くらい前にBASIC言語でプログラミングしてた頃の話w
その後、月刊ASCIIとかの雑誌で構造化プログラミングの事を知って、Pascalだのヴィルトだのダイクストラだのの名前を聞きかじって、大学でPascalを学んで、「やっとGOTO文無しでプログラミングできるぜ！」と喜んでたよ。
| 時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
|---|---|---|---|---|
| 00 | 79 | 12205 | 154.5 | 56 |
| 01 | 50 | 10376 | 207.5 | 45.5 |
| 02 | 36 | 13542 | 376.2 | 54.5 |
| 03 | 13 | 6333 | 487.2 | 49 |
| 04 | 7 | 5028 | 718.3 | 956 |
| 05 | 12 | 5202 | 433.5 | 49.5 |
| 06 | 13 | 3823 | 294.1 | 118 |
| 07 | 26 | 5014 | 192.8 | 39.5 |
| 08 | 57 | 2242 | 39.3 | 24 |
| 09 | 81 | 5855 | 72.3 | 52 |
| 10 | 143 | 13361 | 93.4 | 43 |
| 11 | 142 | 13873 | 97.7 | 52.5 |
| 12 | 121 | 13181 | 108.9 | 45 |
| 13 | 137 | 11426 | 83.4 | 49 |
| 14 | 81 | 4661 | 57.5 | 40 |
| 15 | 96 | 8615 | 89.7 | 37 |
| 16 | 125 | 8243 | 65.9 | 25 |
| 17 | 115 | 16140 | 140.3 | 40 |
| 18 | 95 | 8384 | 88.3 | 34 |
| 19 | 104 | 12440 | 119.6 | 38 |
| 20 | 93 | 11053 | 118.8 | 48 |
| 21 | 149 | 22400 | 150.3 | 31 |
| 22 | 100 | 12331 | 123.3 | 42 |
| 23 | 86 | 13074 | 152.0 | 35 |
| 1日 | 1961 | 238802 | 121.8 | 41 |
マルティナ(8), 男系(7), DQ5(8), Pascal(5), デボラ(8), 高橋洋一(4), 天空(8), ぱふぱふ(4), フローラ(12), 上皇(5), 母子手帳(4), 令和(29), リメイク(11), ゴーン(21), 勇者(13), Java(14), たつき(7), 令(9), ドラクエ(10), 何かと(8), けもフレ(11), Python(9), 孫(9), 出版社(10), 初代(7), 初心者(12), 声優(16), 元号(14), プログラミング(16), 言語(19), 借金(9), 肩(9), 息子(12), 監督(9), PM(12), AM(11)
■こうすればプログラミング覚えられるよ【随時追記】 /20190404034812(16), ■ノリで豚バラブロックを買った /20190403210718(15), ■富士通を退職した理由 /20190326233147(15), ■絶望している /20190403235507(10), ■俺は社会的JAXA、NASAけないぜ。 /20190404095147(8), ■俳優を使わず声優を使えとかいうの /20190404145540(7), ■IT業界の不思議なプログラマ /20190404003732(7), ■言ってくれないと分からない、なんで言わないと分からないの？問題 /20190404213809(7), ■過去の元号に対するイチャモンまとめ /20190403184726(6), ■道端で人が倒れてたり苦しんでても無視するみたいな風潮 /20190404152553(6), ■ /20190404161254(6), ■いきなり味変する人が理解できない /20190403164100(6), (タイトル不明) /20190404100235(5), ■けもフレ2の監督イジメ /20190404044016(5), ■ /20190404133738(5), ■「令和」は「beautiful harmony」 /20190404083337(5), ■三つ子死亡家庭の夫が、夜勤だったと聞いて /20190404152110(5), ■日本政府は提灯記事の作成が壊滅的に下手 /20190404173109(5), ■anond：20190404103434 /20190404103837(4), ■みんな政治の話って何処で誰と話してるの？ /20190404154915(4), ■ゴーン容疑者の再逮捕 /20190404170231(4), ■納税の義務を課せられた奴隷 /20190404183344(4), ■anond：20190404131849 /20190404133151(4), ■anond：20190404164119 /20190404164704(4), ■anond：20190404034812 /20190404131646(4), ■水割りをください 涙の数だけ /20190404183312(4), ■ /20190404110821(4), ■「限界女」とは私のことだ！ /20190404135026(4), ■母親がポンコツという愚痴 /20190404030136(4), ■令和の令は命令の意味じゃない /20190404191424(4), ■ゲームメーカーさんに切実なお願い /20190404133652(4), ■ジュニアに熱中してる女 /20190403214729(4), ■首都高の地下から東京駅の地下街に出れる階段 /20190403232026(4), ■今後増えるだろう漫画家のフリーライダー問題 /20190404091759(4), ■スーパーのカゴ・袋詰め問題 /20190402213330(4)
6145545(3276)
プログラミングのプロになるつもりなら、Pascal → C → Python → Java あたりでどう？
俺は今でも Pascal のシンプルさと一貫性と融通のきかなさ（良い意味で）は初心者にうってつけだと思う。すぐ学べるし。
C と Python は知らないでは済ませられないだろうから必須。
で、結局は Java もやることになるだろうし。
何が言いたいかと言うと、まずは構造化プログラミングを学び、それだけでは収拾がつかなくなる場合があることを実感してからオブジェクト指向へ進むのが自然で納得できるだろうということ。
そして、最初はオブジェクト指向の要素が無い言語を学べば、オブジェクト指向の要素を使いたくても使えないので、その方が却ってスッキリしてわかりやすいだろうという事。
そこまで行かなくても、とにかく何かできてしまうというのは却って混乱しやすくはないか？
シンプルで縛りの多い言語の方が間違えたくても間違えられないみたいな面があるので、初心者が混乱する可能性が低くて良いように思う。
まあ、バリバリのプログラマーになるつもりなら最初からJavaもいいと思うけど、何も手をつけた経験がないうちから自分の適性や将来の進路の方向まで見通すのは難しいだろうし。
よくよく考えてみると自分が最初にやった言語が思い出せない・・・
Javaは複雑だから初学者がいきなりやっても意味不明で挫折するかもしれないけど
あれぐらいお堅い方がお行儀の良いプログラマーになるのかも。
PHPは舐めた評価になっちゃうけど他の言語が出来てれば何となくで出来ちゃうんじゃね？（みんながそんな感じでやってるからそこら中に地雷の埋まった危険なシステムが出来上がっちゃうんだけど・・・）
Javaはやめとけ、ってのは同意。だけど、Javaも手続き型言語だぞ、と訂正は付け加えておくとく。
プログラマじゃないけどプログラミング完全に理解した（）おばさんが理解してる基礎知識書くよ。
（追記 この文章はプログラミングの勉強をしたいけどその周辺にある基礎知識になかなか触れる機会がない人向けに書きました。これらの基礎知識があると、困ったときに調べ方すら分からないという状況は回避しやすくなるはず）
ターミナル、いわゆる黒い窓からCUI（コマンドユーザーインターフェース）でコンピュータを使う方法を覚えよう。これは大学のコンピュータリテラシーで習った。MacOSXで復習すると捗った。（追記 すごく間が抜けてたけどMacOSXはUnix系OSです）
まずはファイル操作。Macでターミナルを使って、cd Desktopって打ってからecho ohayou ＞ aisatsu.txtって打ってみて、cat aisatsu.txtってやる。そうすると何が表示されるのか？とりあえずやってみよう。ここで＞は増田の都合上大文字全角にしてるけど、ちゃんと半角にしてね。なんで増田の都合上半角がダメなのか、そのうち想像できるようになろう。（追記 ブコメ指摘感謝）
そして、実際にデスクトップを見に行ってみると、aisatsu.txtってファイルがあるはずなんで、開いてみよう。これで何が起こったのか７割くらいはわかるはず。
こういうファイル操作の基本をまず覚えよう。これこそ空気みたいなものだから。
（追記 ここも間が抜けてたけど確かにhogeって何かわからないね。直しました）
最近は何も考えなければ文字コードはとりあえずUTF-8でなんとでもなるようになってるけど、バックスラッシュとかは環境設定で出てくるように設定しないと出てこないし、その意味合い、つまりエスケープとしての使い方を頭に入れておくと後々困らないと思う。あとEOF（エンドオブファイル）とか改行コードとかもそういうものがあるよ程度には覚えておこう。これ頭の片隅にはいってないと分からん殺し的な罠にはまることがある。
これは使いたいプログラミング言語の公式サイトに行くと大抵書いてある。
でもMacだとだいぶ楽。とりあえずターミナルからgccって打ってみるとなんかCUIツールとか書いてあるものをインストールしろって言われるのでインストールする。これだけでCとかC++とかRubyとかPythonとか一通り使えるようになる。もしかしたら最近はこのインストールすらいらないかもしれないけど。
あと、シェルのコマンドとかプログラミング言語を実際に使うときはいろんなライブラリをインストールする必要があるけど、そのライブラリは管理がすごく面倒なので管理をまとめてくれるコマンドがあったりする。aptとかhomebrewとかがそういうのだから、そんなものの使い方も覚えておこう。
（追記 言語の文法を追うだけなら環境構築なんてしなくてCloud9とか使ってもいいかもだけど、プロダクトを作ろうとした時にはまだまだ手元で環境作って必要なライブラリを入れてとやった方が後々応用がきくと思うのですよ。それにそうしていくとDockerの有り難みなんかも理解できるようになっていくのではと思います）
最初に勉強するプログラミング言語は、Javaだけはやめておけ。
なんでかっていうと、Javaはオブジェクト指向言語ってやつなんだけどオブジェクト指向的にしか書けないから。古い人間だと言われそうだけど、最初は手続き型言語から始めるべきだと思ってる。少なくとも、手続き型的に書ける言語から始めるべき。
なぜそう思うのかも含めて、とりあえずおばさんが理解しているプログラミング言語の発展の経緯を軽く解説する。
最初の頃のプログラミング言語は、手続き型と呼ばれるものが多かった。
この〇〇型ってのはプログラミングをするときの考え方によって名前がついているんだけど、手続き型はまず0を作って、0に1を100回足して、最後にその結果を表示してください、みたいな、上から書いた順番通りに動くのが基本のルールである考え方。プログラムは基本的にはこうやってデータをアルゴリズムを使って変化させていって望む結果を得ている。でもこのやり方は問題も多かった。プログラム全体がひとかたまりになってしまっているので、数千行とかになるともう普通の人では手がつけられないし、人間のミスでデータを間違って扱ってしまうことがバグの温床になった。
なので、この手続き型の考えに構造化という考えが加わって、関数というものが生まれた。関数っていうのは料理のレシピに例えるとわかりやすいかも。
5:豚こまを入れて色が変わるまで炒めます。
9:火を消して8をお皿に盛り、野菜炒めの出来上がりです。
B:肉に味付けをします。
2:Bを入れて色が変わるまで炒めます。
3:Aを入れてしんなりするまで炒めます。
4:火を消して3をお皿に盛り、野菜炒めの出来上がりです。
って書ける。ここではAとBが関数。
この程度だとあまり意味を感じないかもしれないけど、これがもっと複雑なものを想像してみると、なんとなくありがたみが分かって来ないだろうか？こうすると、多人数でプログラミングをするときに、Aを書く人、Bを書く人、1〜4にまとめる人って感じで作業分担ができる。それに、バグが起きた時もAの領域でバグったのか、Bの領域でバグったのかとか、全体にまとめると上手くいかないのかとか、原因の切り分けがしやすい。
でも、プログラムがとっても複雑化すると、これでも手に負えなくなる。料理の例えを拡大すると、料理店を運営することを考えるといいかも。
料理店でたくさんの料理をさばくときに、レシピを完全に1から作ることってないと思う。Aさんが野菜の仕込み担当、Bさんがスープの仕込み担当、というように各人に仕事が割り振られているはず。AさんもBさんもそれぞれの仕込みのレシピを持っていて、最終的に出てくる仕込みがちゃんとしてればAさんBさんの仕事の詳細までいちいちシェフが細かくチェックしない体制になっていると思う。大雑把にいうとそういう考え方をプログラムで再現したのがオブジェクト指向型言語。
なので、本気で料理の初心者がいきなり厨房の仕切りを任されて上手くいくのは難しいように、構造化プログラミングのありがたみすらわからない段階でオブジェクト指向型プログラミングに手をつけても意味がわからんだろうと思うのがおばさんの立場です。
（追記 おばさんはRubyを勧めておきます。オブジェクト指向型言語ですが、手続き型的に書き下すことも出来るからです。一つの言語で手続き型構造化オブジェクト指向、全部勉強できます。メソッドも便利なのが一通りあるし、日本語を扱うのにも問題が少ないです）
次に問題を分解できるようになろう。
例えば、クイズゲームを作りたいと考えたときにクイズゲームを作りたいです、って問題は大きすぎる。
クイズゲームに必要な要素は、問題文を表示する、回答を入力してもらう、正誤判定をする、正誤判定の結果を表示する、ということだなぐらいにまず分解する。
これを実際にプログラミングしようとすると、もっと分解できてさらに問題が見えてくると思う。
コンピュータってのは創造的なことはできない代わりに、とても簡単なことをとても階層的に重ね合わせて大きな問題を解けるように作られてる。それを心するといいと思う。
これ超大事。プログラミングって本当に自分で1からものを考えなきゃいけないことってあまりない。大きな問題はあなただけの問題かもしれないけれど、それを構成する小さな問題は大抵他の誰かが解いている問題なので、調べてみれば答えが見つかると思う。
エラーメッセージが出てきたらまずググってみる。翻訳しても初心者には意味がわからないし、ググったら誰かが解説付きで紹介してくれているのでその解説を読んだりしながらエラーメッセージとの付き合い方を覚えていけばいい。
メソッドの使い方がわからなかったら言語の公式サイトに行ってみる。メソッドの使い方で大事なのは呼び出し方、返ってくる値の型とかそういうのだから、こういうところはググるよりも公式サイトに書いてあることをしっかり読んで理解する。
あと、アルゴリズムの勉強もしてみるといいと思う。アルゴリズムとデータ構造と計算量の勉強。大学の学部レベルの教科書をちゃんと読んでみると、例えばデータベースを操作するSQLというものを書くことになった時とかに効いてくる。あとは作ったプログラムが遅すぎてどうしようとかいうのを解決する時とか。
なんか深夜までいろいろ書いてしまったけど、あくまでもプログラマじゃないおばさんが書いたものなので、みんなでツッコミとか入れてくれると大変助かります。
ネット見ていて（今日だとコインハイブ裁判とか、転職サイトとか）、いろいろな JavaScript の表記で自分なりの許せる／許せない。
○ JavaScript : みんなこう書く。俺もこう書く。
○ ＪａｖａＳｃｒｉｐｔ : おそらく新聞社とかの表記ルールに従って、仕方なくこうしていそうなので許せる。
○ Javascript : 読みにくいけど、頭文字だけ大文字っていうルールだと思えば、気持ちはわかる。
× ジャバスクリプト : おっさんなのでカタカナは苦手なんですよ。
× Java ： Javaのことかと思って読み進めていたら JavaScript だったりするので、読んでいて疲れる。
我ながら かなり寛大だと思う。
