プログラマーになったばかりの頃に知っていたらよかったと思うことは？ 113
ストーリー by headless
遠路 部門より
遠路 部門より
本家/.「Ask Slashdot: What Do You Wish You'd Known Starting Out As a Programmer? 」より
プログラミングを始めたときに、「職業」としてはあまり意識していなかった人も多いと思う。しかし、困難を乗り越えて経験を積み、コンソールを前に数十年がたってみると、このような長い道が続いていることを最初に知っていればよかったと思う。そこで、昔の自分や現在プログラミングを始めようとしている若者たちに対し、どのようなアドバイスができるだろう。Andrew C. Oliver氏はプログラマーになったばかりの頃にあまり意識していなかったことについて、いくつかの考えをまとめている。皆さんの場合はいかがだろうか。
Andrew C. Oliver氏が早いうちに知っていればよかったと考えているのは以下のようなものだ。
- 人の名前を覚える
- 見方を変えて問題を解決する
- マーケットと自分の仕事に合わせて言語や技術を選ぶ
- ソフトウェアの面で大きな革新が起こることは比較的少ない
- 仕事の連続ではなく、職業だと考える
- 週に40時間以上働く
- 自分で難しくしない限り、プログラミングは難しくない
- コミュニケーションの仕方を学ぶ
プログラマーと言ってもいろいろ種類があるということ (スコア:5, 興味深い)
大学院とかで研究としてプログラミングをする人
企業の中でも新しいアルゴリズムを研究するような人
ゲームを開発する人
組み込み機器の開発をする人
Webアプリを開発する人
業務システムを開発する人
言われたコードを書くだけの人
「プログラマー」になったときは、何も知らずこれらの区別もついていなかったが、SIerで数年仕事をするうちに、どうも俺がやりたかったのは↑の方の分野で、後になって違うルートに変更するのは非常に難しそうだ、ということに気づいてしまった。
その事実をプログラマーになる前に知っていたら、違った人生もあったのではないかと思うと、いまでも残念に思うことがある。
これからプログラマーを目指すという人には、自分が目指すルートが何なのか、認識したうえで、同じ過ちをしないようにしてもらいたいと思う。
注）1990年代の話です。今の人はネットで事前にそういう実情に触れられるから、よい時代になったもんだ。
＃ 脱SIerだけは果たした。
Re:プログラマーと言ってもいろいろ種類があるということ (スコア:1)
> 違った人生もあったのではないかと思うと、いまでも残念に思うことがある。
馬鹿馬鹿しい。環境がそれをやらせてくれるなんてのは勘違いもいいところだろう。やりたいことが分かっているならやるだけだ。今やらないのは怠惰でしかない。学部レベルの知識から出発して丁寧に解説してくれている専門書は山ほどあるでしょう。
Re:プログラマーと言ってもいろいろ種類があるということ (スコア:1)
行動力足りなすぎ。なぜ個人？必要ならできる環境と仲間を探せ。
うまくその環境に行けないのなら、実力不足だ。あきらめろ。
ちなみに個人でも勉強はできるし、さらに
ロボットは余裕で現物に落とせる。デアゴスティーニから週刊誌が出るほど。もちろんそのまま組み立てるなんて低レベルなことはしないでね。
宇宙開発も三流大の研究室が人工衛星上げてる例はいくらでも。個人で火星探査ロボットを作ることも余裕。
個人で打ち上げられないのは当たり前。打ち上げられないじゃんとか思ったら、技術者としての問題分析力不足。技術畑から早めに足を洗った方がよい。
Re:プログラマーと言ってもいろいろ種類があるということ (スコア:1)
そら『二本足で歩く』だけなら昔のオモチャでもあったからね。
（二本足じゃないが）有名なAIBOだってたかがオモチャだおなあ。
でもそんなのは研究とは言い難い。
ところで宇宙開発の方へのツッコミは？
＃やる気があれば個人でもできる？ご冗談を。
Re:プログラマーと言ってもいろいろ種類があるということ (スコア:1)
大丈夫。
「宇宙開発やりたかったな」と言っている人でやり方がわからない人は、
もしもその業界に身を置いても、何の役にも立てないから。
無理にでも宇宙機業界にかかわるとしたら、
一番の近道は、衛星を作っているメーカーの工場の工員かな。
「人工衛星作ってるぜ」とは言える。
俺の工場実習時の２つ年下の兄貴は見た目はヤンキーだけど、組み立ての腕は良かったよ。
知らなくてよかった（？） (スコア:5, 興味深い)
ウォーターフォール型開発か、アジャイル開発か。
この違いは、プログラミングと言っても雲泥の差があります。
私がこの職に就いたとき、後者の手法しか知りませんでした。
もちろん「アジャイル」という言葉は後から出てきたものですが。
子どもの頃から、パソコンにパッケージ（主にゲームやワープロ）を
インストールして（あるいはフロッピーから直接起動して）利用する
というコンピュータの使い方しか経験が無く、特定のシステムのために、
専用に設計されたプログラムを、注文して開発するということを、
根本的な概念から知りませんでした。
10代～20代の頃は、ソフトウェアといえばパッケージという固定観念を持っていました。
受託開発というものを知ったのは30代になってからで、ウォーターフォール型開発
という言葉を知ったのは、30代後半です。
そんなわけで、私が就職するときは、自社ブランドパッケージ会社しか考慮していませんでした。
私とは正反対に、在学中から学内のシステムにログインして計算機を使っていたとか、
就職したところが、はじめからSI屋や受託開発屋だった、のような方もいるかもしれません。
受託系の話題を見るたびに、厳しい話しか出てこない印象があります。
その点、自社ブランド製品なら、開発者にかなり自由な裁量が与えられ、
設計に口出し（アイデアを助言）することができます。
もはやアジャイルという言葉すら死語になりつつある感がありますが、
それが度々話題に上がっていた数年前、そのさらに10年ぐらい前から、
アジャイルという言葉を知らずに、それに相当する開発スタイルで、
今までやってきました。
初期段階ではほとんど設計を行わず、作りながら踏み固めていく感じです。
もし、初めて経験した職業プログラミングが、ウォーターフォール型開発だったら、
と想像すると、ぞっとします。たぶん今頃、この業界から足を洗っていたかもしれません。
そもそも、趣味で始めたプログラミング。その趣味を嫌いになっていたかもしれません。
39歳のとき転職しました。もちろん自社パッケージ屋です。面接の時に初めに聞いたのは、
どちらの開発スタイルかということです。もし、設計工程と実装工程とテスト工程が完全に
分離されたスタイルだったら、今の会社には入らなかったでしょう。
若い頃は無知で、受託開発なんて知りませんでした。
その無知のおかげで、今でもこの業界で食っていけてると思っています。
Re:知らなくてよかった（？） (スコア:1)
今の仕事にはあまりストレスを感じていないので、
私のグリーフシードはほとんど濁っていません。
Re:知らなくてよかった（？） (スコア:1)
間違えました。
ソウルジェムは濁っていません。
謹んで訂正いたします。（笑）
Re:知らなくてよかった（？） (スコア:1)
私の担当は、ネイティブアプリ開発ですが、社内にはウェブアプリをやっている部署もあります。
ウェブアプリといっても、インターネットで公開しているようなサービスではなく、組織内で使用するイントラ的なウェブアプリです。
パッケージというと微妙に語弊があるかもしれませんが、PCショップで箱売りしているようなものではなくて、
営業が注文を取ってきて納入します。でも、受託開発ではなく、自社製品として売っているものです。
たとえるならば、グループウェアみたいなものでしょうか、サイボウズではありませんが、サイボウズ的な何かを想像して頂けると良いかと。
Webサービス系は考えないわけではありませんが、私の主力言語はC++なので、必然的にWeb系は担当していません。
# FastCGIを使ってウェブアプリを作れといわれれば作りますが、今のところ社内からはそういう要求は出ていません。
Re:知らなくてよかった（？） (スコア:1)
自社開発の企業に新卒で入り、今はSES営業が中心の企業に転職して客先常駐で開発やってます。
顧客の要望を想定・予測して仕様を作るのと、顧客から要望を聞いて仕様を作るのとでは、入り口から全然違いますからね。
>きちんとした仕様書を書くようにしようと言ってきたり（仕様書を書くのもプログラマーの仕事の一部なんだが）
この部分れだけ主張がわからないのですが、自社開発だときちんとした仕様書は不要とか、書けないとか言ってますか？
横道 (スコア:3, 興味深い)
プログラム:8進数に気をつけろ
ハードを利用する場合:故障での遅延を折り込んどけ
マネジメント:SEに進化しろと言われるが、実際はジョブチェンジで、後衛から前衛になるので、それが自分にとって最良なのか考えておけ
くらい?
# 良い職場かどうかは、お客様先常駐が多いので、あんまり関係ないかも、とかもあるかも?
M-FalconSky (暑いか寒い)
「プログラマーになる」なんて思わないことだ (スコア:3, 興味深い)
プログラマーはソフトウェア技術者と呼ぶべきだと思う。コードを書く人はコーダーと呼ぼう。
コーディングは自体は難しいものではない。コーディングはスキルであって、職業だとは思わないことだ。
プログラムを作るのは、問題解決の手段にすぎない。コーディングの問題だけを解決する職業につかないことだ。
顧客のシステム・要件などを深く理解し、正しい「問題」を作れば、正しい「回答」(コード)を生み出すことができる。
問題を正しく認識すれば、システムで変化する領域と、変化の少ない領域が把握でき、
顧客のビジネスの変化に追従しやすいコンポーネント分割ができる。
開発期間の大半を占めるテストのフェーズで効果的なテストケースを抽出できる。
気持ちよく使われて初めてプログラムの存在意義がある。
そのために、顧客とシステムとの関わりを知る、技術(道具)を知る、サイエンスとして研究し自ら新しい技術を生み出すなど、
「コード」より「問題解決」側に視点を持って行った方が良いと思う。
(……科学技術とは言うけれど、ITの分野だと「技術」だけに偏重しがち。
既存の言語を覚えるとか「技術」の範疇だ。「科学」の事も忘れないでやってください。
全員技術者になってしまったら、日本発の新しい技術は生まれなくなってしまう。)
Re:「プログラマーになる」なんて思わないことだ (スコア:2)
ライブラリの仕様書と現物コード比べたら違っているなんてのが今まさに・・・・・。
顧客のルール・習慣・癖を知る (スコア:3)
たとえば文字セット――シフトJISが通じるのは日本だけ。
たとえば時刻――国内で時差がないのは日本を含めたアジア諸国だけ。
リアルタイム・オンライン処理では、トランザクションが3桁、4桁の伸びを示す瞬間がある。それをどうクリアするか。
そして顧客は「想定外」の入力をしてくる――バリデーションは脆弱性対策の第一歩。
Re:顧客のルール・習慣・癖を知る (スコア:1)
日本のアプリでもクラウドとかの開発でサーバーがどこにあるか不明なのにDateTime.Now使っちゃうとかの話じゃないの？
Re:顧客のルール・習慣・癖を知る (スコア:1)
〉 そして今は Unicode 系統の UTF-8 や UTF-16 等が全てであると考えている開発者が多いんじゃないかと思う。
ISO-2022-JP も Shift-JIS も EUC も滅ぼてしまえ、ついでにUTF-16 も UTF-32 も消え去ってしまえ、
と願ってる開発者なら私です。
Re:顧客のルール・習慣・癖を知る (スコア:2, すばらしい洞察)
国内で時差がない国について言及してて、英仏独は時差がないって言われたら、
イギリス、フランス、ドイツはそれぞれの国内には時差がない、って話だと取るのが普通だと思うんだが
なんでイギリスとフランス、ドイツそれぞれの他国との時差について語ってるんだ？
むしろプログラマーになったばかりの頃に知っといたらよかったと思うことに追加するとしたら、こういう
日本語の読解力が足りなすぎて話を混乱させる奴が居るということを常々意識すべき、ってことかな
設計書なんかを斜め上の解釈をされた挙げ句、話が拗れた案件を何回か経験しているとね
Re:顧客のルール・習慣・癖を知る (スコア:1)
夏時間と国内の時差では扱いが全然違うんだけどな。そもそも話題に上がってないのと忘れてるのは違うし。
そして「夏時間がどうたら」と言い出して話の本質をどっかに行かせる典型的なコメントをありがとう。
手段と目的を弁える (スコア:2)
プログラムはIT実現の手段
ITは戦略実現の手段
とりあえず１つの言語に習熟してみること (スコア:2)
人によって習熟には差があると思うが、アレコレと手を出さずにとりあえず１つの言語でだいたいのことが出来るようになっておけばと思った。
# １つの言語ができれば他の言語も似たようなものであると気づいたからだけど
Re:とりあえず１つの言語に習熟してみること (スコア:1)
一つの言語だけ覚えて原理主義者になってしまう人も居るし、
いろんな言語を知っているけどちゃんと使えない人も居る。
出来る人だと思える人は、いろんな経験から新しい言語もさくっと使うし、面倒なプログラムへの問題解決能力があるので最後にきっちり仕上げてくるよ。
最近困るのは、ぐぐってコピーしたのがうまく動かないっていう相談だな。一つの言語もまともに使えないってコトでしょ。
見た目大事。
IEはクズだけど避けて通ることはできない (スコア:2)
Javascript が動かなかったり、CSS がバグだらけだったり…
でも OS バンドルはなくならないんだよね。
いつもだけど (スコア:1)
>6. 週に40時間以上働く
なんでやねん
>8. コミュニケーションの仕方を学ぶ
馴れ合いになるから程々に
Re:いつもだけど (スコア:1)
Re:いつもだけど (スコア:1)
＞>6. 週に40時間以上働く
＞なんでやねん
米： 週に40時間以上働く
日： 週に40時間以上残業する
だよね。
Re: (スコア:0)
仕事の時間だけしかやらない場合、自分の可能性を上司に任せることになるといいたいようですよ
Re:いつもだけど (スコア:1)
・自分の考えていることを相手に伝える能力
・相手の考えていることを理解する能力
がコミュニケーション能力だと思います。特に仕事の場合では。
飲み会の席で豊富な話題を提供するのは、また違った能力。
Re:いつもだけど (スコア:1)
なによりまず、自分とコンピュータが意志疎通できるほどには、人間（顧客や同僚や上司、そして未来の自分）とはコミュニケーションが取れないし、とてもコスト（時間と手間）がかかるし、そしてなによりそれは避けることができない、ということを理解すべき。
Re:いつもだけど (スコア:1)
単純に進捗と周りへの影響をロジカルに伝えて欲しいだけなのだが。。
見た目大事。
Re:いつもだけど (スコア:1)
＞人の理解に留まらず、人に何かを求めさせ、人を動かす力まで含んでいる。
＞人との理解に支障がないだけで、今の時代に「コミュニケーション能力」と呼ばれる尺度で充分な評価を得ることはできない。
知性のある相手なら、正確な内容を伝えられれば、それに応じて適切な対応をしてくれる。
（感情的な理由などで）それが出来ない相手はそもそも知性が欠けているので、コミュニケーションを取る必要はない。
プログラミング言語 (スコア:1)
COBOLを覚える
費用対効果についての助言 (スコア:1)
客が怒り出す一歩手前のモノを、可能な限り短時間でつくれ。
# 不具合あっても、とにかく早く納品してエンドユーザに弄らせた方が面倒が少ないから
notice : I ignore an anonymous contribution.
ふたつの専門分野を持つ。 (スコア:1)
ひとつは自分の興味分野。もうひとつは、実際に金を払ってくれるひとの興味分野。
プログラムを書くことで飯を食おうとするな (スコア:1)
「客の問題を解くために」使う技術として「プログラミング」というものを捉えておけ。
そのほうが儲かる。
# Google ってその典型例だと思うんだ。
fjの教祖様
1.人の名前を覚える (スコア:1)
人の名前を覚えることが病的にできません。
いっつも相手は自分の名前を覚えてるのに、こっちは四苦八苦。
それなりに良い年なので営業トークとかできないと拙いのですが、
名前すら覚えられないんじゃあ話になりません。
社風その他が合わないと思ったら (スコア:1)
即転職するのが最良の方法だと言うこと
そのために転職サイトはまめにチェック
合う合わないが強烈にある職種なので無理に続ける必要は無い
まして心身を病むほどのものではない
それと日本に限った話かもしれないけど、一労働者としても労働三法に労安衛法と労契法辺りは一度目を通しておくと良いかと
#この辺がしっかりしてればブラック企業に肉体的・社会的に殺される可哀想な人は少なくなるはず
ないなー。 (スコア:1)
「知ってるだけ」でどうにかなるような事はね。
『なれる！SE』はフィクションだということ (スコア:0)
ただし、良く描かれている部分は。
自分の書いたプログラムが一番だめね。 (スコア:0)
> 7. 自分で難しくしない限り、プログラミングは難しくない
すみません。
おっしゃるとおりですぅ。
Re:自分の書いたプログラムが一番だめね。 (スコア:1)
自分が作り込んだ数々のバグを最初から知っていれば...別のを
Re:自分の書いたプログラムが一番だめね。 (スコア:1)
粛々と完璧なプログラミングをお願いします。
仕事のパートナーとしては、そういう人が一番助かります。
一番大事なのは (スコア:0)
「プログラム書いて飯食うなんて考えるのはやめて，他の仕事にしとけ！」 の一言かも．
Re:一番大事なのは (スコア:1)
「プログラマって職業はITカーストの下から二番目だ！(最下位はコールセンタ・ユーザーサポート)」っと言っておこう〜
Re:一番大事なのは (スコア:1)
カーストの上の方までもれなくヌケサク揃いでエンドユーザが使いづらいものを作ってくれるので、俺らの仕事が無くならずに済む。
ありがたいことです。
Re: (スコア:0)
プログラミングが好きだから多少給料が安くてもって言う奴には近づかない
それを食い物にするやつもいるから、それにも近づかない
oh!no! (スコア:0)
脳の容量に限界があるものだということにしてあまり手を広げすぎない、、、かな
Re:oh!no! (スコア:1)
若い人にそういっちゃいかんだろ。
若い時は理論とか概念とか実体がないものでもいくらでも頭に入っていくよ。多少知恵熱が出る程度で。
歳くうと頭痛がするようになる。そりゃそうだ、頭の血管も老朽化している。
そうなるまでにどれだけ詰め込むかが勝負だ。
ただし、（やり方を）覚える必要はない。どうしてそうするのか理解する、これが重要。
電車でLinux入りのCDROMを拾ったら (スコア:0)
駅員さんに渡してさっさと忘れること（オリバー違い
なったばかりの頃だと (スコア:0)
「もう手遅れだ」とか。
こんなところにこなきゃ もう少し
ましな人生歩めたはずだが
もう遅い
プロセスの起こし方殺し方
なまじコードが書けたから
紙切れ一枚で地獄行き…
Re:コードをとにかく読め (スコア:2, すばらしい洞察)
そういう意味ではマイコンBASICマガジンとか良い環境だったよな
ある程度厳選されたコードしか載ってないし、特にインターネット普及前は自分で打ち込むしかないから、嫌でもコードをしっかり読むことになる
ついでに入力ミスからのバグが出た時に自力で入力ミスの箇所を見つけることができるからデバッグの基礎力もついたりする
「最近の若い者は」的な言い方はしたくないけど、でもやっぱりああいうアプローチで育ったタイプのプログラマが最近の若い世代には本当に少ないからなぁ……