馬鹿プログラマーを排除する方法を考えるスレ

**仕様書無しさん** · 2013/04/17(水) 21:58:22.07

馬鹿プログラマーがいると

1)ゴミコードを書き散らしてみんなに迷惑をかける
2)生産性の低い馬鹿プログラマーの給与のせいで業界の平均賃金が下がる

存在するだけで悪である馬鹿プログラマーを業界から排除する方法を考えましょう！

**仕様書無しさん** · 2013/04/17(水) 23:47:54.12

馬鹿プログラマを排除するより、
自分が馬鹿プログラマのいない上級の会社に転職するほうが楽かもしれないね。

**仕様書無しさん** · 2013/04/18(木) 22:57:10.26

あのなあ。。

プログラマーがいないと、全部箱なんだぞ

**仕様書無しさん** · 2013/04/19(金) 07:11:32.28

3がいうように、糞が混じり安い多重派遣や請負がいる仕事に関わないようにすべきだと思う。

**仕様書無しさん** · 2013/04/20(土) 01:09:42.72

人日制を無くさない限り絶対無理
生産効率悪い方が高いシステムできるんだもんww

**仕様書無しさん** · 2013/04/20(土) 19:00:32.85

>>3
上級の会社ってたとえばどこ？
少なくともNTTデータじゃないとは思うが

**仕様書無しさん** · 2013/04/21(日) 08:41:10.35

>>2
君みたいに学歴だけで判断するような短絡さでこの惨状です

**仕様書無しさん** · 2013/04/22(月) 08:06:09.88

>>7
webサービスをしている会社は内製している所が多い

**仕様書無しさん** · 2013/04/23(火) 06:26:31.83

>>7
ベンチャー企業じゃね？
大手企業だと技術の移行が遅いし

**仕様書無しさん** · 2013/04/24(水) 22:19:10.56

>>6
縦読み多いな

**仕様書無しさん** · 2013/04/25(木) 09:49:15.91

馬鹿マネージャーを排除する方が先

**仕様書無しさん** · 2013/04/27(土) 02:17:49.96

工程通りに進めてたら八時間労働しなくても帰らせてくれ

**仕様書無しさん** · 2013/04/27(土) 02:24:51.86

数十分の残業を付けたら渋い顔するくせに数十分遅刻したり数十分早く帰ると人非人扱いするこの国はいかれてる

**仕様書無しさん** · 2013/04/27(土) 16:35:42.07

馬鹿を排斥することを考えるより、自分が馬鹿の居ない職場に転職することを考えたほうが捗る。

**仕様書無しさん** · 2013/04/27(土) 20:25:39.12

>>13
工程表の方を密度を濃く変更します。
次の案件はその密度で受注します。そして納期厳守。

**仕様書無しさん** · 2013/05/09(木) 08:56:14.68

>>12
プログラマーとして役に立ちすぎる奴はプログラマーから先に進ませてもらえない
逆に役に立たない半人前は糞マネージャーになる
実作業者が優れてるとマネージャーはバカでも務まるからね

本当は知識、技術、経験のすべてが揃ってる奴に管理させるべきなんだけど
多少かじった程度の奴でも務まると思ってるから実作業者の負担が激増して
デスマになったりプログラマが辞めたり壊れたりする

**仕様書無しさん** · 2013/05/09(木) 09:33:57.43

そうなると派遣の人売り営業と変わらんな
実作業のことなんか知らんて感じで客の要望スルーしてりゃいいから

**仕様書無しさん** · 2013/05/09(木) 13:26:54.11

>>17
＞プログラマーとして役に立ちすぎる奴はプログラマーから先に進ませてもらえない
んなこたぁねぇだよ。
ﾌﾟﾛｸﾞﾗﾏｰしかできない奴はいるけど。

＞実作業者が優れてるとマネージャーはバカでも務まるからね
んなこたぁねぇだよ。
ただの足枷だ。

**仕様書無しさん** · 2013/05/09(木) 13:43:14.43

糞マネージャー乙

**仕様書無しさん** · 2013/05/09(木) 13:59:27.47

>>19
技能職なんだからプログラマで居続けたいと願う奴はいくらでもいるけど
プログラマしかできないって奴はたぶんいないぞ

プログラマとしてはクソの役にも立てなかった無能なチンカスが考えそうな決めつけ

**仕様書無しさん** · 2013/05/09(木) 21:10:21.03

PM<<<(超えられない壁)<<<伝書鳩

**仕様書無しさん** · 2013/05/09(木) 21:14:49.91

伝書鳩ｗ

**仕様書無しさん** · 2013/05/09(木) 22:21:12.60

ただの伝書鳩ならいいけど
中途半端な知識で生返事してきて現場を炎上させる馬鹿もいるからね・・・

**仕様書無しさん** · 2013/05/09(木) 22:37:21.88

知ったかぶって見当外れな文章にわざわざ書き換えてから
現場に送ってきたりとかね。そのまま手を加えず送ってこいやとｗ

**仕様書無しさん** · 2013/05/10(金) 01:57:56.89

伝言ゲームかよww

**仕様書無しさん** · 2013/05/22(水) 21:26:12.12

馬鹿プログラマなどど抜かしてる馬鹿は
必ず現場からは馬鹿にされてるな

**仕様書無しさん** · 2013/05/24(金) 02:12:50.81

統計学の問題出せば一発で潰せる
高卒と文系はデータ分析の仕事渡して潰してるよ

**仕様書無しさん** · 2013/05/24(金) 21:29:31.41

数3Cと物理は必修だよね～

**仕様書無しさん** · 2013/05/29(水) 00:21:48.43

排除？
雇ったほうが馬鹿なんじゃねーの？

**仕様書無しさん** · 2013/06/23(日) 20:09:33.13

馬鹿プログラマーは向上心とかないし、自分で調べようっていう意思がないからな
自宅でコード書いたりしない奴は大抵ろくなレベルじゃない

**仕様書無しさん** · 2013/06/23(日) 20:35:41.99

もうほんと、ツールの使い方くらいググって探せよと
お前上司だろ

**仕様書無しさん** · 2013/06/24(月) 23:09:41.78

はいｗブーメラン>>31

**仕様書無しさん** · 2013/06/29(土) 03:45:43.86

自宅でコードを書いてるほうが馬鹿だと思う。
出来る奴は、絶対に残業しないだろうな。
無駄なことが少ない証拠でもある。

**仕様書無しさん** · 2013/06/29(土) 07:58:04.06

自宅ってのはフリーソフト作ったりって話だと思ったが

**仕様書無しさん** · 2013/06/29(土) 20:51:38.96

>>34は明らかにモグリ
この業界やプログラマという職業の実態を知らなさすぎる

**仕様書無しさん** · 2013/06/29(土) 21:12:49.80

謎コーディングスタイルとゴチャゴチャした構造化設計貫いてる職場の連中見てると、
仕事以外で何もやってこなかったんだろうなとは思う
新しい技術に触れる職場ならいいけど、小さいメーカーで組み込みだと本当ひどい

**仕様書無しさん** · 2013/06/30(日) 12:07:38.04

>>37
あるあるｗｗ
その職場伝統のスタイルって奴。
コーディングスタイルだけならともかく俺様フレームワークもどき
とか強制されたりする。

**仕様書無しさん** · 2013/06/30(日) 12:57:11.31

フレームワークは仕方なくね？
不本意でも社内で統一されてるならそれに従って覚えるのがスジ。
嫌なら別のフレームワークを社内で奨めるか、辞めて別の職場を探す。

**仕様書無しさん** · 2013/06/30(日) 12:58:32.32

フレームワークごときに人生を翻弄されるPG

**仕様書無しさん** · 2013/06/30(日) 13:05:31.82

すでに動いているオレオレフレームワークなら使わざるを得ないからなぁ。
問題は、そんなダメフレームワークに対して愚痴しか言わないやつだな。

ダメなのは分かっているから、今すぐコストかけずに入れ替えれるものが
あるなら持って来いよ。ダメなところだけあげつらって、リファクタリングも
しなければドキュメントも残そうとしない愚痴しか言わない奴は氏ねとか
思うよ。

**仕様書無しさん** · 2013/06/30(日) 14:26:51.84

既に>>41の考え方がダメダメ
開発をわかっていない

**仕様書無しさん** · 2013/06/30(日) 17:26:55.04

>>42
実現可能な提案等を書くわけでもなく、ダメダメと言うだけだからな。
言うは易し行うは難し。お前は評論家かよっていう。

**仕様書無しさん** · 2013/07/01(月) NY:AN:NY.AN

>>41 >>43
論点ずらしの詐術・詭弁ですね
橋下市長がよくやる手法と一緒

**仕様書無しさん** · 2013/07/01(月) NY:AN:NY.AN

>>43
実現可能な提案を「今ちゃんと動いているから変える必要はない」って
あっさり蹴られるってことも多いと思うが……。

**仕様書無しさん** · 2013/07/01(月) NY:AN:NY.AN

経験ある有能なエンジニアだけで書いた理想の美しいフレームワークを作れる、
というのは幻想だよ。

実際には様々なスキルや経験を持つエンジニアを混ぜて作らざるを得ず、
フレームワークを作り直したけどゴミ具合いはあんまり変わらなかったね、
ということはよくある。

それより既存のフレームワークの一部をリファクタリングしたほうがいい。
45の言っていることも現実だけど、いざフレームワークを刷新してもよいという話になったときに、
基本はそのままで最悪の部分だけを選んでリファクタリングする
というのも選択肢に残しておいた方がいいぞ。

**仕様書無しさん** · 2013/07/01(月) NY:AN:NY.AN

>>45
結果が既存のモノと同じなら、コストをかける理由がない。
その提案に何かメリットがないとな。

**仕様書無しさん** · 2013/07/01(月) NY:AN:NY.AN

>様々なスキルや経験を持つエンジニアを混ぜて作らざるを得ず
そもそもコレが諸悪の根源だろ。「様々な」どころか何のスキルも経験も無い
文理不問・未経験歓迎の求人で掻き集めただけの派遣SE・PGに丸投げ案件大杉。

**仕様書無しさん** · 2013/07/28(日) NY:AN:NY.AN

むっちゃけ人売り業界なうちはダメなままだと思う
いつまで居るかもわからない、先人が残したクソ環境、クソコードを自分が頑張って良くしていっても
自分にかえってくる評価とかのリターンが殆どないから、やる気とか出ないだろう
好きだからやってるけれど、それなら評価に繋がる場所でやったほうがマシだしなぁ

いまも出向先で業務改善、既存の問題点の指摘と改修提案、
既存コードの大幅改修（ぶっちゃけ作り直し）してるけど、
どうせあと数ヶ月でここ抜けるつもりだし、そういうこと考えたらすごいモチベ下がる
いくら頑張って仕組みつくっても、残ったうんこがうんこーどを次々追加していくだろうからなぁｗ

**仕様書無しさん** · 2013/07/28(日) NY:AN:NY.AN

>>48
まじコレだわ
口入れして中抜きするだけの企業と人を売るだけの企業が大杉て、技術者が育つ環境が殆ど無い

**仕様書無しさん** · 2013/07/28(日) NY:AN:NY.AN

>既存コードの大幅改修（ぶっちゃけ作り直し）
作り直しさせてくれた方がマシな既存コードとか多々存在するんだぜ。
そもそもポインタを理解できずに関数のIn/Out引数を宣言してしまってたり。
それを「作り直し禁止」で、元のコードは全部残したままで、最小限の修正で
バグを直して、性能も向上させろ、とかムチャ振りする大手客先とか平気で有る。

**仕様書無しさん** · 2013/07/29(月) NY:AN:NY.AN

>>51
それはそうだが、もし動いてたところが動かなくなっちゃったりしたときのリスクまではふりかかって
欲しくはないよね

**仕様書無しさん** · 2013/07/29(月) NY:AN:NY.AN

理想論だってのはわかってるけど、こうあるべきって思うところに近づけていきたと思ってる

その「もし」動かなくなったら、って考えるのはもちろんダメなことではないと思うけど
コードは書いたようにしか動かないんだから、「もし」なんてものは言ってしまえばありえない
ミス(バグ)はテストで潰すしかない
再帰テストを行わないようなゴミプロジェクトはもうどうしようもないけど、
しっかりリグレッションこなすなら、だめな部分はしっかりなおしていったほうが後々役に立つで

**仕様書無しさん** · 2013/07/29(月) NY:AN:NY.AN

>>51
最小限の修正ですませればリスクがゼロということにはならないんだよな
そういったコードは元々の品質が悪いから、
対策確認テストの時に「修正しなかった部分」で潜在バグが分かったりする
で、その潜在バグ対策を現担当者の自分がやらざるをえなくなる
更には「最小限の修正」だからバグを上手く回避する対策コードを追加し、
その対策確認テスト中にまた別の潜在バグが見つかって..................
あれよあれよと見事に底なしの泥沼へ一直線のコースにはまる(泣笑

モチベの点で、大改修を決めた案件にあたっている>>49のほうが、
まだマシな気がする

**仕様書無しさん** · 2013/07/29(月) NY:AN:NY.AN

言ってることはよく分かる

だが、それを全うできる工数もらえてるか？っていうとほぼ確実に違うでしょ？
その辺はどーすんの？

**仕様書無しさん** · 2013/07/29(月) NY:AN:NY.AN

潜在バグで直しちゃダメってなら、見てみぬふりしかないじゃん

**仕様書無しさん** · 2013/07/29(月) NY:AN:NY.AN

>>55
いや、「最小限の修正」であった場合でも、もらえる工数は修正規模で決まるから、
普通は潜在バグ対策(とその後の泥沼)の追加工数はもらえないだろ
事前に修正母体の潜在バグ発生率が計測できていて、
それに応じて工数が追加できるような契約であれば可能だろうけど、夢物語でしかない

>>49は計画の段階で「大改修(作り直し)」を決定しているから事前に工数を予測できる
たとえそれが厳しいものであっても、それを乗り越えるという目標を持てる
いつになれば朝日が昇るかまったく予測できない「最小限の修正」よりマシだと思うが

>>56
直しちゃダメじゃなくて、最小限の修正量で直せ、って意味だよ

**仕様書無しさん** · 2013/07/29(月) NY:AN:NY.AN

その最小限を大きく報告すればドンと改修出来るじゃんか
言われたとおり働けばいいってもんじゃない

**仕様書無しさん** · 2013/07/29(月) NY:AN:NY.AN

>>58
「最小限の修正」を過大に報告すれば「大改修(作り直し)」と同じ工数がもらえると思う？
常識で考えればもらえないだろ

こんなことも分からない「馬鹿プログラマーを排除する」いい方法はないものかね.......

**仕様書無しさん** · 2013/07/29(月) NY:AN:NY.AN

>>59
馬鹿はお前

**仕様書無しさん** · 2013/07/29(月) NY:AN:NY.AN

はいはい

**仕様書無しさん** · 2013/07/29(月) NY:AN:NY.AN

>>59
頭悪すぎるｗｗｗ

**仕様書無しさん** · 2013/07/29(月) NY:AN:NY.AN

>>59
常識に縛られて思考停止している無能プログラマ。
単にお客様から見て都合がいいだけで会社の利益貢献には全く役に立たないから、
いつまでたっても下級プログラマのまま。

**仕様書無しさん** · 2013/07/29(月) NY:AN:NY.AN

こうして

>いくら頑張って仕組みつくっても、残ったうんこがうんこーどを次々追加していくだろうからなぁｗ

が現実の姿となりますた
めでたし、めでたし

**仕様書無しさん** · 2013/07/29(月) NY:AN:NY.AN

>>54
あるある過ぎるwww

>>59
>「最小限の修正」を過大に報告すれば「大改修(作り直し)」と同じ工数がもらえると思う？
「派遣」禁止にしないとね。
派遣だと、「チェンジ」食らうだけだよね。

かくして、>>64 という結果に…

**仕様書無しさん** · 2013/07/29(月) NY:AN:NY.AN

>>59
赤くなるほどレスされてよかったなｗ
自分が楽しめないような仕事ばっかしてるようじゃ、バカだぜ

**仕様書無しさん** · 2013/07/29(月) NY:AN:NY.AN

馬鹿プログラマーを排除したい賢いプログラマーが、何で馬鹿SEだか馬鹿客をあしらえねえんだよ
だから馬鹿なんだよ

**仕様書無しさん** · 2013/07/29(月) NY:AN:NY.AN

自己紹介乙

**仕様書無しさん** · 2013/07/29(月) NY:AN:NY.AN

>>67
賢いプログラマーは馬鹿SEや馬鹿客をあしらっているだろ
くそなシステムにくそなコードを追加していくことで、
システムが寿命を終える迄の間、チェンジされることもなく
会社へ利益を貢献できるのだから

何か問題でもあるの？

**仕様書無しさん** · 2013/07/29(月) NY:AN:NY.AN

>>67
馬鹿は馬鹿同士で繋がる習性がある。
馬鹿が排除されない会社は経営者が馬鹿の同類だったりする。
宗教と同じ。健常者は排除され狂った奴だけが集まっていく。

忍法帖【Lv=2,xxxP】(1+0：5) · 2013/07/30(火) NY:AN:NY.AN

馬鹿グラマーが寄り付きにくい言語で開発すればいいんじゃね？
HaskellとかOCamlとかSchemeとか

**仕様書無しさん** · 2013/07/30(火) NY:AN:NY.AN

>>70
経団連のことかっ!?

>>71
求人案件は、JAVA(大文字), VBだらけ…

**仕様書無しさん** · 2013/08/07(水) NY:AN:NY.AN

> (大文字)
あるあるすぎるｗｗｗ

新しいことを学ぶ意思のない連中が一人でも混ざると、どんだけいい環境を揃えて
どんだけ優れたフレームワークを利用しても、うんこーどが発生するから、
結局は自社開発を自社メンバーだけで出来ない職場はうんこ化するよ
奴隷業界が全ての元凶

**仕様書無しさん** · 2013/08/08(木) NY:AN:NY.AN

おまいらの言う馬鹿プログラマーだけど
頭ん中がOO(というかGoF)でガチガチに凝り固まってしまって
ここ最近流行りの関数型言語がさっぱり解らなくて困ってる
staticおじさんに俺もこうしてなっていくのかな

**仕様書無しさん** · 2013/08/08(木) NY:AN:NY.AN

アマチュアプログラマが飛び付きやすい言語ってのは一見流行りに見えるが、業界ウケし難い。
これまで様々な言語が消えていったように、一部で使われるだけでそのまま衰退、自然消滅していく。

**仕様書無しさん** · 2013/08/08(木) NY:AN:NY.AN

つまり、この先生き残るのはコボラーとジャバラーだけなんですね。
たいへんわかりやすいです。

**仕様書無しさん** · 2013/08/08(木) NY:AN:NY.AN

>>76
C「もう俺だけでいいんじゃないかなー(^-^)/」

忍法帖【Lv=3,xxxP】(1+0：5) · 2013/08/08(木) NY:AN:NY.AN

>>74
おま
　ん
　こ
static

まで読んだ

**仕様書無しさん** · 2013/08/09(金) NY:AN:NY.AN

GoFが理解できる知性があるのに関数型が理解できないという意味がわからない。
実はGoFも理解してないってオチじゃね。

**仕様書無しさん** · 2013/08/09(金) NY:AN:NY.AN

ラムダ式とか普通に解る
部分適用とかもまあわかる
モナドとか入ってくるとわけわかめ

確かにGoF全部解ってるかというと、割とそうでもない気がする
VisitorとかCommandとかInterpreterあたりは正直理解が怪しい

**仕様書無しさん** · 2013/08/10(土) NY:AN:NY.AN

×覚えられない
○興味を持てない

潮時だよ

**仕様書無しさん** · 2013/08/10(土) NY:AN:NY.AN

>>80
Haskellは何を参考にして学習したのかな？
いわゆる「ふつケル本」は原語の表層を解説しただけの駄本だから、
これを読んでHaskellコードを書けるようになっても、深い理解は得られない

モナドはすごく(数学的に)抽象的な概念だから分かるようになるのは難しい
とりあえずHaskellコードが書けるレベルなら、以下の書籍で
関数型プログラミングの基礎を固めておいたほうがいい
　　関数型プログラミング -- R.バード/P.ワドラー共著, 武市正人訳
　　http://www.amazon.co.jp/dp/4764901811/
この本にはモナド登場以前の純粋関数型プログラミングについて、すべてを解説した良書だ

あるいは、>>80が「Haskellにあらずんば関数型言語にあらず」という純粋関数型絶対主義者、
いわゆるハスケラでなければ、他の関数型言語を試すのがいいんじゃまいかと
たとえば Scheme(Lisp族)やF#/OCaml/SML(ML族)など
これらの非純粋関数型言語でも「関数型プログラミングにおけるデザパタ」は考察できるよ

**仕様書無しさん** · 2013/08/10(土) NY:AN:NY.AN

13 名前: 仕様書無しさん Mail: sage 投稿日: 2013/07/11(木) NY:AN:NY.AN
今時にありがちな書籍のタイトル
・はじめてのXXX
・サルでもわかるXXX
・ふつうのXXX

これに当てはまるのは、どれも愚本のたぐい
アマチュアとしてプログラミングを楽しみたい人には適しているかもしれないが、
専門家/技術者の道に進もうと考えておるなら、避けるべき
これら優しい口調の文章で「分かったつもり」の感覚に慣れてしまうと、
次のステップへ進むために読む専門書の日本語文書に拒否反応を起こしてしまう

82 · 2013/08/10(土) NY:AN:NY.AN

>>80
では、具体的に「関数型プログラミングにおけるデザパタ」を考察してみよう

まず最も基本であるCompositeパターンについて、もしオブジェクトの属性が
集合論における直和であり、クラス継承が直和であるという認識を持てれば、
以下のようにコード化できる(これはGoF本からの引用になる)
　　[SML] datatype 'a Component = Leaf of 'a | Composite of 'a * 'a Component list
　　[Haskell] data Component a = Leaf a | Composite a [Component a]
これは再帰的な代数データ型の初歩的な定義例でしかない

そしてCompositeパターンと深い関連があるIteratorパターンやVistorパターンは、
上記のデータ型を再帰的に辿る探索問題でしかないと理解できるだろうし、
Commandパターンを含めるとコレクション(上記のデータ型)に対する高階関数の適用でしかない
またBuilderパターンやAbstract Factoryパターンは、関数を入力として関数を返す高階関数そのものであり、
Stateパターンは入力事象と遷移元状態の直積(組)から出力事象と遷移先状態の直積への写像(関数)になる

別の見方をすれば、OOPではデザパタとして神格化され高度な技法と見られていた概念が、
FP(関数型プログラミング)では基本とほんの少しの応用でしかない、と見なすことができる
この現実に対して拒絶反応を起こしてしまうかそれとも素直に受け入れられるかが、
OO脳から関数型脳へ脱却できるか否かを決める大きな壁になると考える

82 · 2013/08/11(日) NY:AN:NY.AN

>>84を訂正

X: .... もしオブジェクトの属性が集合論における直和であり、
O: .... もしオブジェクトの属性が集合論における直積であり、

ついでに参考として、直積 A×B と直和 A+B の定義を書いておく(特に難解な定義ではないと思う....)

A×B = { (x, y) | x ∈ A, y ∈ B }
A+B = { (0, x) | x ∈ A } ∪ { (1, y) | y ∈ B }

なお、直積は「集合の直積集合」、直和は「集合の直和分割」とも呼ばれている
そして、言語上では直積はタプル型やレコード型として、直和は代数型として表現される

**仕様書無しさん** · 2013/08/11(日) NY:AN:NY.AN

「神格化され高度な技法」とか「でしかない」みたいな強い言葉を使って他を貶して
自分たちが優れてるって主張するのって、昔Java厨がバカみたいに繰り返してて
もういい加減おなか一杯、胸やけがするくらいなんですけど

82 · 2013/08/11(日) NY:AN:NY.AN

>>86
まったくそのとおりだよね
GoF本の著者自身がデザパタの意義はカタログ化にあり、「デザパタは決して系統的であったり
厳密なものではない」と述べているのに、なぜかデザパタであれば正しいと主張を繰り返すのには、
もういい加減おなか一杯、胸やけがするくらいだ

**仕様書無しさん** · 2013/08/11(日) NY:AN:NY.AN

このスレで排除対象にあたるような馬鹿が腐るほど居る業界だ
自分はすごいって思ってしまうようになっても仕方がないって気はする
それくらい、馬鹿が多い業界

**仕様書無しさん** · 2013/08/11(日) NY:AN:NY.AN

ごめんなさい

**仕様書無しさん** · 2013/08/18(日) NY:AN:NY.AN

>>87

あんたに言ってんだけど？

**仕様書無しさん** · 2013/08/18(日) NY:AN:NY.AN

管理する側の層が技術者のスキルを理解や把握できていないから、排除すること自体難しいだろうなぁ
いってしまえば業界全体がレベル低い

**仕様書無しさん** · 2013/08/28(水) NY:AN:NY.AN

開発経験10数年らしいおっさん
1日中コンパイルエラーと格闘している様子

おれ「存在しない変数に値を設定しようとしているようですが」
おっ「そうか？、ガハハハ」
おれ「このクラスにこの名前で変数を定義してますか？」
おっ「あちこちからをコピったんでわからんわ」
おれ「この機能では必要な処理なんですよね？」
おっ「そんなん知らんわ動きゃええねん、ガハハハ」

管理する側は現場の状況なんか気にしない
スケジュールと進捗と報告書が大事
メンバーのサポート（尻拭い）をするのはメンバーの仕事
排除は難しい

**仕様書無しさん** · 2013/08/28(水) NY:AN:NY.AN

単価相応

**仕様書無しさん** · 2013/08/30(金) NY:AN:NY.AN

現場にいるババアがギャーギャーうるさい
喋り方がウザい上に頻繁に「わーーー」とか「うひゃーーーー」みたいな
擬音語を発するからイライラしてくる

若い奴ならまだしも４０超えてる人の話し方ではない
歳相応の落ち着きがないし変な違和感で気持ち悪い
いちいちリアクションがウザくてイライラしてくる

**仕様書無しさん** · 2013/09/01(日) 23:48:33.55

昔の現場で要件定義のヒアリングが全部擬音だった衝撃の案件を思い出した

**仕様書無しさん** · 2013/09/02(月) 00:19:07.00

>>95
全部って
盛りすぎで逆につまらん

**仕様書無しさん** · 2013/09/03(火) 01:54:04.85

ここはｽﾞｷﾞｭｰﾝって感じで、こっちはドドドドドドドってくるようなイメージでお願いね

**仕様書無しさん** · 2014/01/16(木) 13:08:48.94

>>97
少々盛ってはいるけど、委託の案件ってだいたいそんな感じではある

**仕様書無しさん** · 2014/03/04(火) 01:36:33.49

そのバカをもっとまともなコード書けるように教育してやれよ
そのバカが素質ないならどうしようもないがな

**仕様書無しさん** · 2014/03/05(水) 12:49:24.67

>>1
まず、
・大学偏差値６５未満はプログラミングをしてはならない。
・専門、Ｆランク卒はコーダーやテスターのみ。机を与えてはいけない。

からはじめよう！

**仕様書無しさん** · 2014/03/05(水) 12:58:30.90

矛盾してる２つの条件を恥ずかしげもなく書ける君の偏差値は？

**仕様書無しさん** · 2014/03/05(水) 14:39:15.37

☆コピペ推奨☆
【犯罪者追放のお願い】
大金、知財、健康を失ってからでは、取り返しがつきません。

犯罪者に従うのも犯罪です。犯罪行為を最寄りの警察署に通報して下さい。
※通報者のプライバシーは保護されます。

刑法第246条詐欺罪
虚偽による契約金を交付させた。

刑法第223条強要罪
作成等の完了日を強要された。

刑法第234条威力業務妨害罪
職権等の威力によって業務を妨害された。

刑法62条幇助罪
犯罪行為を助長した。

職業安定法第44条労働者供給事業の禁止
業務の時間、場所、方法等を指揮命令された。

警察官の対応に問題があった場合は、監察局、各都道府県の警察本部監察官室、公安委員会に苦情申出して下さい。