わけわからない物事を自分なりに解釈して試行錯誤する能力
1日で終わりそうな実装を5日かかる見積もりをして4日間サボる能力
頭の中でイメージする能力じゃない？
コーディングできるやつほど実際にタイピングする前に頭の中でコード完結させてるよ
異論ある？
あーはいはいこういうことね
↑
全然わかってない
この気持
程度を弁える能力が欲しいな
どんな便利な手法、方法論もやり過ぎると破綻したり分かりにくくなったりする
使うべきところでだけ使う、という弁えが自他ともにあると良いと思う
「論理構成力」
論理を組み立てて他人にわかりやすく言語化して伝える能力
>>16
ついでに言うと
抽象化思考力は論理構成力を支える三本柱の一つ プロジェクトをやめる能力
下っ端としては、怪しいと思ったらやめられる能力
マネージャーとしては、プロジェクトをたたむ能力
一時的な記憶力
それがないからRAIIとか非冗長に記述できる言語が好まれるわけで
>>1
一番大切かどうかはわからないけど 忍耐力は確実に必要
理不尽極まるものに囲まれて忍耐できないものがどんどん落ちていく ググって、出てきたサンプルを自分のソースに落とし込めるセンス
global 変数の甘いささやき
(you使っchina)
に打ち克つ
アスペであること、ナルシストであること、サイコならなお良い
負けないこと、禿げ上がらないこと、ニートにならないこと、信じぬくこと
それが～一番大事～
発注者の気持ちを理解すること。
お前らに最も欠けていることだぞ。
発注者でもお前でもありません
お・きゃ・く・さ・ま
当時の上司に「あれは客じゃないカモだ」という話をされたときは眼から鱗だったわ
便利なものを作りたいという意志と作る実行力と作ってからも改善し続ける継続力
─RubyやPythonの成功例より─
プログラムは思った通りには動かない、書いた通りに動く
というのは誰の言葉なんだろう？
もしかすると、この精神がプログラマーとして一番大事な能力なのかもね
なんつーかプログラマーに必要というより、仕事する上で必要な能力だよなw
>>58
プログラムは書いたとおりにさえ動かない。環境と合わせなければ適切に動作しない。
というのも、誰か外人の名言にあった気がする。 >>58
1980年代にはすでに言われていたからそれよりは古いんだろうな。 >>58
何度もデバッグして原因究明してたら自然に身につくと思う
>>62
それって仕様違反してたりするだけじゃね？ >>64
その昔、ハードウェアもコンパイラも、それどころかCPUさえも完全に信頼できるものではなかったりしたしね。
マイクロソフトのCコンパイラなんかでも、式が少し複雑になるとダメとかいうのがあったりして。いろいろ泣かされましたわ。 >>64
その昔、ハードウェアもコンパイラも、それどころかCPUさえも完全に信頼できるものではなかったりしたしね。
マイクロソフトのCコンパイラなんかでも、式が少し複雑になるとダメとかいうのがあったりして。いろいろ泣かされましたわ。 >>65
俺はハード開発もやってて昔はマイコンボードとかも作ったことあるから不安定なハードがあることもわかるけど、さすがにCPUのバグにぶち当たったことはないな
コンパイラのバクも生涯で２回しか経験ないわ 中型機、2000年代にCPUの不具合に1年間気が付かずに
苦労したことがあったわ。CPUの不具合とかメーカーもユーザーも
想定しないからなあ
>>68
何のスレだと思ってんだコイツ
隙があれば自分語り
空気を読まなすぎる能力、マナーやルールを守らない能力があるね！ CPUの型名もバグの内容も書いてないレスはスルーでいいかと
>>68
だいたいソフトのせいになるからね。
そこを反論できる、真の原因を追求できるだけの調査能力が必要だよね。 Intelの浮動小数点計算の最後の桁がおかしくなるとかいうアレ？
>>73
あーあったなあ。アイトリプルイーナナゴーヨンガーとか、昔は悩んだものだった。
皆さんご存知、Javaのstrictfpという修飾子ですが、
あれはインテルはいってるがJavaの言語仕様に影響を与えているわけですね。 変数が32bitなのは、インテルのCPUが32bitだったからとかいい出しそうだなｗ
>>11
コメント全部書いてからコード埋めてる
完成が早くてキモいと言われるが論文書くときってトピックセンテンスから作っていくから普通だと思うんだが
どんな言語でもパターンさえ覚えればその組み合わせだしな >>78
コメントって第一段階のコード作成で生産性を上げる意味ある？
コメントが一切ないコードも珍しくなく
ライセンスを明記するコメントは邪魔かもしれない >>78
最初の一発目が早くてもその後のメンテナンス性がめちゃくちゃ低いってこと多いからな
どれくらいの規模のコードを書いたことある？（ファイル数とかクラス数とか）
ちゃんとテストコード書いている？他の人が書いたコードを修正したことある？
リファクタリングとかしたことある？そこらへん疎かにしたスピードだと意味がない。
>>79
コードの可読性が高ければ、コメントは不要だからね
俺も最初に日本語で書いたりするけどそれはメモ書き。後で消す。
コメントが必要にならないようなコードに書き直す バグが絶対にないコードなら可読性が充分高ければコメントいらないになるけど
バグは存在しうるので、自然言語でコードの意図を補足するコメントは必要だと思うな
コメントをメンテしないとコードと乖離するから良くないとかいうのはズボラのいいわけだと思う
>>83
後で読むかどうか、だろ
絶対に読まないならば(そういうケースがあるかどうかは別として)コメントは要らない >>87
「抽象概念をテストする具体的コードをかける」かどうかをテストする具体的なコードを書ける？ 囲碁や将棋の達人は何十手も先を読むという
そいう能力が必要だと思う
今取り掛かっているロジックを考えつつも、
その先のことも合わせて考えられるかというのは
後々効いてくるぞ
prin（・・・次はreturnして終わりっと）
↓
pirntr・・・orz
>>88
怠惰を求めて勤勉に行き着く
FORTRANの開発者、バッカスだな >>67
> コンパイラのバクも生涯で２回しか経験ないわ
VAXだったかなあ。20年以上前に正規表現の勉強がてら
Cの構文解析するユーティリティをCで作ったらどうしても
動かなくてさ。（要はegrepの自作なんだけど）
悩みまくったあげく思いつきでオプティマイザ
抜いてコンパイルしたらちゃんと動作した経験があるな。
/*
** このソフトいじったらコンパイルする時に "/noopt" 付けてください。
*/
と書いた思い出がある。希少な体験だったんだなあれ。 こいつみたいに空気読まずスレ違いの文章を書き込める老人力
タイピングできないとそっちに脳のリソース持ってかれるから仕事できないよ
若者の読解力、数学力が、今の老人の若い頃より落ちているっていう
結果は出ているようだけどね。
>>118
抽象化能力が上がるぞ
若い人が全部同じに見えるだろ >>117
そうそう
だから義務教育でタイピングとコマンドとディレクトリ構造ぐらいは教えろって話 >>117
フリック入力ができる入力装置が主流になっていくと思われる
多分今後20年くらいで急速に >>125
優しい人。
ここまでスレ読んで疑問に思わないか？性的魅力とか3の倍数でアホになる能力とかが必要なプログラマと言う人は一体何をする人なのだろうかと。
しかしこのマジレスで生真面目な人達だと言う事はわかってよかったよ。 >>121
20歳過ぎてから、キーボード使えるようになった（ブラインドできるようになった）んだけど
いま５０代。
結婚が遅くて小３の息子がいる。
職場では早いほうなんだけど、ローマ字習って間もない息子に
タイピング速度ボロ負けする。
こいうの、識閾下で処理できるようになる低年齢でやったほうが
絶対いいと思う
その分リソースを指向に割ける。 タイピングゲームの北斗の拳は
入力が一定数超えると裏技であべし出来るからな
糞真面目に全部打たなくても勝てる
タッチタイピングは必須だけどタイピング速度はそれほど必要ない
エディタを使いこなして効率よく編集できる力のほうが大事
できるだけ脳の負担を小さくして
できるだけ少ないタイプ数で目的を達成しようとするのが
プログラマー的思考
>>131
記号を正確に入力出来る能力が高いといいな。エディタの補完なんかは記号入力起点が多いから。
ホームポジションから離れることが多いので大体タッチタイプできても、記号来るとなんか崩れるんだわ。 アイデアをダーって出力したいときに、タイピングが遅いとアレだなとは思うけど、普通は考えている時間の方が断然長いしな…
でも、タイピングは速い方がいいね
3DSに鬼トレというゲームがあるが、これの鬼計算がある程度できないと厳しいと思う
複数の変数・関数を脳のワーキングメモリに入れることが出来ないと
しょっちゅうアノ変数どんなんだっけ？関数どんな動きしたっけ？って確認する作業が発生して時間の無駄だし間違いも発生する。
趣味ならいいけど仕事でプログラマーを選ぶのはやめておいたほうがいい
いや関数とか変数にわかりやすい名前つけてればそんな能力いらないだろ
function_001()
var_001
とかそういう世界で生きてるなら必要かもしれんがw
関数を使うなというアホな理論がありましてね
ユニケージとかPOSIX原理主義っていうんですけど
>>134
一番大事な能力ではないが
あきらかに試行回数が品質に差を付けている場面はある >>137
仕様書と一致させることが大事な職場だとそっちのが楽
response
responce
とかくだらないことで時間取られない >>140
アプリケーションの生産性よりも
仕様書と一致させることが大事だってことですか？ 訂正
ソフトウェア開発の生産性
仕様書と一致させることが大事だってことですか？
>>137
わかりやすい名前を付けても、脳のワーキングメモリに複数の変数名・関数名を
とどめておくことが出来る人と出来ない人に別れて、出来ない人は職業プログラマーには向かないでしょ？ そこは職業プログラマーじゃなくて
単にプログラマーでいいでしょ？
わかり易い名前の価値が理解できない人が作ったものなんて
怖くて使えないよ
>>142
うん
正直デカすぎて通しで動いたときの動作なんて誰も把握できないし >>145
でかくて把握できないから小さい関数作るんでしょ
論理が破綻してるぞ >>146
それ俺の元の主張と何か食い違うことある？ 136
複数の変数・関数を脳のワーキングメモリに入れることが出来ないとプログラマーを選ぶのはやめておいたほうがいい
137
いや関数とか変数にわかりやすい名前つけてればそんな能力いらないだろ
138
仕様書と一致させることが大事な職場だとそっちのが楽
140
仕様書と一致させることが（ソフトウェア開発の生産性にとって）大事だってことですか？
145
うん
146
論理が破綻してるぞ
147
それ俺の元の主張と何か食い違うことある？
コミュニケーションが伝わらない原因は>>140の日本語が破綻してるから
＞仕様書と一致させることが大事な職場だとそっちのが楽
そっちってどっち？
意味不明
こんなのはスルーすべき 仕様がどんどん変わっていく環境というのもあるぞ。開発中のOSとか。
OSの新しいコードをチェックアウトしたら自分のコードがビルドできなくなったり
新しいOSビルドで「あんたのコードにバグがあるよ」ってバグレポされたり。俺じゃねー
そういうのは逆に変化についていく能力も重要。
>>151
これが意外と多いんだよな
対応するのが面倒になってくる だからといって対応しないと、ユーザーに価値を提供できないわけで
そういう変化に対応しやすい設計を作る能力というのも
プログラマーにとって大事な能力
ひどいやつだと、対応するのが難しいから、
そんなのは作らない主義ですとかいって
逃げるやつもいるからなｗ
素人が趣味でやるのはどうぞって感じだけども...
デヴィッド・カトラーとかまだコードを書いたりしてるのかな
まあ俺様一人が作るなら仕様書なんて要らないんだけどさ
昔は1日1万行ぐらいコードが書けたが、最近駄目になってきた
プログラマーとしての能力が失われてきている感じだ
最近だめになったんじゃなくて昔からずーっとダメなんだよ
プログラマーの能力がないから1万行も書いちゃうわけ
それに今も気づいてないんでしょ
>>159
わかる
ワイは統合失調症発症してから1行も書けなくなった スレチ
プログラマーとして一番大事な能力が1日1万行書く能力として終わるならいいが1万行も書けたと自慢したいだけ
名人プログラマーは遂にはプログラムを書くことを忘れ果てるのだよ
ルーチンをコピペで増やして1万行ではなかろうな…
10年くらい前までそういうコードばっか書いてた会社勤めてたけど
5年前にやらかして2年後に潰れたから正解だった
1万行オナニーコード書くより
コードを1行追加or修正して色んな人にレビュー指摘して貰う方が遥かに成長出来る
100行の関数を1日10個で週5日の2週間やると10000行増えてる
事前に細かいとこまで設計やってるとこのペースはよくある
週2日出社、週2日在宅の週4日勤務が最高の働き方だと提唱したい
週休3日制になったら給料を減らされる？？そんな考えだからいつまで経っても貧乏なんだよ...
サラリーマンが副業でプライベートカンパニーを設立するメリット
Webマーケターに転職して、セミリタイアを実現させる方法
【朗報】「在宅勤務OK」の求人、コロナ前と比べて7 7倍に上昇！
【悲報】「会社員に戻りたい！」というフリーランス、全体の3%しかいないw
【悲報】副業が解禁されても、副業を見つけられずに困窮する会社員が続出...
日頃から副業をやっておくことの重要性を再認識しよう
【驚愕】5人に1人は本業よりも副業収入の方が多いことが判明w 本業よりも稼げる副業とはなんなのか？？
>>169
超短期間で見積りを出す場合
解析工数は行数で出すとハズレがないぞ 超短期かどうかじゃなくて
同じことの繰り返しをする場合だろ
他所の業者が造ったプログラムを引き継ぎで仕方なくメンテしたことがあるが
ソース観たらまじでfor使わずに
a[0]=1;
a[1]=2;
a[2]=3;
printf("%d", a[0]);
printf("%d", a[1]);
printf("%d", a[2]);
みたいなのが延々と続いててびっくりしたことがある
前の業者は行数で見積もり出して行数で請求してたのかな
>>153
> ひどいやつだと、対応するのが難しいから、
対応難しいと感じてやらずに逃げるのはプログラマーの感覚としては正しいと思うよ
下手に対応して強引に動かせたとしても、その後のメンテ作業地獄を自分や同僚に残しかねない >>176
別のプログラムでforを使ってテキストとして吐き出していたのかも？ >>179
そっちの吐き出しプログラムがスゲーきれいな書き方だったら笑うなｗ メンテする人が暇になって人員削減されないように雑に作ってくれたんだよきっと
>>180
こう言うソースジェネレータ作ってると基本誰も見ないのに生成したソースのインデントとかの見た目にこだわってしまうわw >>176
案件ごとに対応するとき既存のコードに触れてはいけないみたいなことがある。
例えば最初に
a[0]=1;
printf("%d", a[0]);
てなったところ追加案件で
a[0]=1;
a[1]=2;
a[2]=3;
printf("%d", a[0]);
printf("%d", a[1]);
printf("%d", a[2]);
となって最初のコードに触れてはいけないからへんなことになる
そして可読性も失われる >>176
forが使えないプログラマを派遣で雇ったことがある。すぐに追い返したけど。 >>178
あーそっかーループを使うより速いよね。 っておい たとえば、九九の2の段を表示したいとする。手続き型プログラミング
言語的な発想でシェルスクリプトを書くと、次のようになる。
for i in 1 2 3 4 5 6 7 8 9; do
echo "2×${i}＝$((2 * ${i}))"
done
ユニケージ開発手法では次のように記述する。
echo "2×1＝$((2 * 1))"
echo "2×2＝$((2 * 2))"
echo "2×3＝$((2 * 3))"
echo "2×4＝$((2 * 4))"
echo "2×5＝$((2 * 5))"
echo "2×6＝$((2 * 6))"
echo "2×7＝$((2 * 7))"
echo "2×8＝$((2 * 8))"
echo "2×9＝$((2 * 9))"
ユニケージ開発手法では上から下に読めるというメンテナンス性を強く意識している。
プログラミングに慣れていない現場の作業員は、繰り返し構文がでてくると理解が及ばないことがある。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
162以降１レスも投稿してないが
プログラマーとして一番大事な能力が1日1万行書く能力だと言って
1万回の繰り返しを1万行にループ展開してメンテナンス性を上げようとマジで言ってる？
スレチすぎて話題について行けなかった
>>187
そこから3の段を作ろうとしてすべての2を3に書き換えてしまうんですね 一番大事ではないけれど
そういう泥臭い作業をやらされる案件でも、ミスなく素早くこなせる基本能力が要求されるな
タイピング速度、エディタの使いこなし、タイプミスの発見能力が必要だ
普通のプログラムじゃないけど手書きのMakefileの中にずらーっと似たようなルールが
書かれていたのを見たことはある。
あれはループやワイルドカードは使わない方がよかったのかな。
>>193
内容が同じかどうかではなく、独立した機能かどうかで決める >>194
例えば .cpp から .o を作るルールが、丁寧にすべてのファイルに対してずらーと書いてあった。
ワイルドカードも使える一方（コンパイルオプションが違ったりしない限り）、なんらかの事情で
あえて明示的に書く理由もあるのかなと。 >>197
なんだか私の makefile と同じですね
.c.o:
$(CC) $(CFLAGS) -c $<
.rc.coff:
$(RC) -i $< -o $@
$(EXE): $(OBJS) $(RES)
$(LK) $(LDFLAGS1) -o $(EXE) $(OBJS) $(RES) $(LDFLAGS2)
sss.o: sss.c sss.h debugout.h wmalloc.h maindialog.h buttonok.h editip2connect.h registry.h thread.h editproxyip.h backgroundcolor.h
debugout.o: debugout.c debugout.h wmalloc.h sss.h
maindialog.o: maindialog.c maindialog.h sss.h debugout.h rbutton.h cmbomyaddress.o cbproxyavailable.h buttonok.h editport.h editinterval.h editip2connect.h editproxyip.h backgroundcolor.h
registry.o: registry.c registry.h debugout.h sss.h
... もう嫌だ… if（flg == 0）｛
flg = 0;
｝else if （flg == 1）｛
flg = 1;
｝
flg == 0 ? 0 : flg == 1 ? 1 : flg
>>174
"for を使えばこんなに簡単にまとめられます" と、まったく逆ベクトルだな。
"for を消す" で、「再帰使うのかな～」とか思って読んだら顎が地下にのめり込むねこれ。 >>197
>例えば、.cpp から .o を作るルールが、
>丁寧にすべてのファイルに対して、ずらーと書いてあった
そんな事を書いている人が、他にいる？ エラーの時にブログじゃなくてドキュメント読もうとする意欲
>>209
ドキュメントの不備に絶望して、ライブラリソースを苦もなく読むようにw >>207, 205
男性限定であれば、宮台真司信者である私としては、これらは装備したいものですね… >>210
ソース非公開に絶望して、アセンブリ出力を苦もなく読むようにw 趣味のプログラミングは念入りにテストを実施
仕事では手抜きテストしてチームの協力を煽ぐ
細かいことは気にしない能力
言われたことだけ直す能力
余計なことはしない能力
テスターからバグが上がってきたとき、その人が実際にどういう条件で何をしたかを
詳細に聞き質さないといけない場合はあったな。特にあまり有能でないテスターの場合に。
とは言ってもその人しかバグが再現できない場合があったりしてないがしろにはできないというw
バグを上げるときは
その手順とセットで上げるんじゃないのか?
いくらいっても頑なに
エラーの出たテスト手順やエラーの出たデータを出さない人いるんだよな
そいつの上司にいっても変わらないし
メールの送信ミスの振りして
このラインのテスター変えてくれって本人に送ったら何故かそいつの上司だけ交代になって
本人が残り続ける地獄があった
低レベルな会社の愚痴をこぼされてもそんな会社にしか行けなかった自分を恨め
って言う感想しかないわ
世の中の9割は筋肉で解決できる。
筋肉を鍛えるべき。
羞恥心
他人にコードを見られたときに馬鹿にされたくない、一目置かれたい、
そうやって綺麗なコードが書ける
>>226
それは違うと思うなぁ・・
一目置かれたいとか、エゴはプログラマにとっては害悪だと思う、個人的には。
綺麗に書くのは後々の自分や他人のためだ 
ブックマークへ