アカウント名:
パスワード:
プログラマー言うても、プログラミング言語を知っているだけの「コーダー」では、仕事を確保するという意味では、せいぜいやれることなんて限られているので年齢関係なくしんどいですけど、設計がきちんとできてコードも書けるようであれば、仕事を作り出すことも可能なので将来の仕事に関しては(己の力で切り開ける分)心配することもないんじゃないかなーと。
私の定義では、良いプログラマーとは良い設計ができる人で、設計とは物事を必要最小の仕事単位に適切に分割して再構築することで、それをするには論理的に物事を組み立てられるかどうかというセンスにかかっている割合が多いと思っています。
なので、チャンスがあるかどうかは、そういうセンスがあるかどうかですので、少しやってみて「いける」「いけない」の判断をすればよいかと。今までそういうことをせずに来てセンスを眠らせているorセンスに気づいていない人もいるかと思います。
何を「常識」とするかの問題ですね。発注側の「常識」は本当に常識なのか?発注者だけがそう思っている可能性はないか?よく見かける「発注側の「常識」をすべて汲み取るべき」と考える思考パターンかと思いますが、別の言葉で言えば、自他の差異に思考が及ばない状態を隠して受注側に責任をなすりつける態度とも言えます。
発注側が受注側に対して行う「○○の知識を持っている」という仮定について、その検証を行なわないままプロジェクトを進めているのが問題です。
もし貴方がプロジェクトを管理する立場であれば、「受注側が○○の知識を持っていないかもしれない」という不確実性に対して、適切に対処していないということになります。「9割以上の〜」「それが、発注側の常識で、世間の常識じゃ無いと言いたいのでしょうか」といった発言から、省略可能な手順は可能な限り省略するというのが貴方の基本方針と理解しましたが、その省略がプロジェクト運営上の不確実性(リスク)を放置する結果につながるならばそれは仕事の手抜きです。そして「と、いうように、プログラムが書けても、常識が無い方が〜」からその原因を受注者の能力に求めているのが分かります。おそらくは、貴方がプロジェクト開始前に受注者の能力を確認*しないで*、それで問題が起こった場合でも受注者のせいにするのでしょう。
貴方とはあまり仕事したくないですね……煽りではなく、本気で……
> おそらくは、貴方がプロジェクト開始前に受注者の能力を確認*しないで*、それで問題が起こった場合でも受注者のせいにするのでしょう。
内容がカンタンなものなら、「できるかね?」という確認程度で済む場合もあります。たとえば、「○○へ行ってくる」「××から○○をもらってくる」というような内容ですね。ITの場合は、カンタンな能力テストなどを受けてもらったり、実績をみて判断するんじゃないでしょうかね。
「受注者の能力を確認」については、裁判などでは発注者側にそうした義務を認めることはほとんどないですよ。なぜなら、「できないもの」を「できる」と言って受注作業を行ったら、受発注以前の話(詐欺)になるからです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
言語を知ってるだけでは意味がない (スコア:5, すばらしい洞察)
プログラマー言うても、プログラミング言語を知っているだけの「コーダー」では、仕事を確保するという意味では、せいぜいやれることなんて限られているので年齢関係なくしんどいですけど、設計がきちんとできてコードも書けるようであれば、仕事を作り出すことも可能なので将来の仕事に関しては(己の力で切り開ける分)心配することもないんじゃないかなーと。
私の定義では、良いプログラマーとは良い設計ができる人で、設計とは物事を必要最小の仕事単位に適切に分割して再構築することで、それをするには論理的に物事を組み立てられるかどうかというセンスにかかっている割合が多いと思っています。
なので、チャンスがあるかどうかは、そういうセンスがあるかどうかですので、少しやってみて「いける」「いけない」の判断をすればよいかと。今までそういうことをせずに来てセンスを眠らせているorセンスに気づいていない人もいるかと思います。
ほえほえ
Re: (スコア:2)
正確には、依頼する方が常識だと思っている事はいちいち説明しないので、あとでトラブルになる事が多いです。
分割で支払われたら、領収書の金額は、その回に受け取った金額で、データベースにある、請求額と対応している入金額合計の項目から引かないで欲しいとか
領収金額の中には諸費税が含まれているとか
説明しなくても、領収書のサンプルが作れると、話していて安心できます。
昔、常識だろうと思っていて、できあがったものを見て愕然としたことが^^;
------------
惑星ケイロンまであと何マイル?
Re: (スコア:0)
何を「常識」とするかの問題ですね。
発注側の「常識」は本当に常識なのか?発注者だけがそう思っている可能性はないか?
よく見かける「発注側の「常識」をすべて汲み取るべき」と考える思考パターンかと思いますが、
別の言葉で言えば、自他の差異に思考が及ばない状態を隠して受注側に責任をなすりつける態度とも言えます。
Re: (スコア:1)
上記した事例については
日本国内で売上が上がる業種が特殊な業種と言うのでしょうか。
諸費税も非課税、不課税な費目をだけを扱う業界以外は対応していますが、そちらの方が特殊ですか。
感覚的に9割以上の業種が同じ対応をしているはずですが......
それが、発注側の常識で、世間の常識じゃ無いと言いたいのでしょうか。
と、いうように、プログラムが書けても、常識が無い方が多い業界なので、そのような知識を付けてゆくのは良いことだと思います。
------------
惑星ケイロンまであと何マイル?
Re: (スコア:0)
発注側が受注側に対して行う「○○の知識を持っている」という仮定について、その検証を行なわないままプロジェクトを進めているのが問題です。
もし貴方がプロジェクトを管理する立場であれば、「受注側が○○の知識を持っていないかもしれない」という不確実性に対して、適切に対処していないということになります。「9割以上の〜」「それが、発注側の常識で、世間の常識じゃ無いと言いたいのでしょうか」といった発言から、省略可能な手順は可能な限り省略するというのが貴方の基本方針と理解しましたが、その省略がプロジェクト運営上の不確実性(リスク)を放置する結果につながるならばそれは仕事の手抜きです。そして「と、いうように、プログラムが書けても、常識が無い方が〜」からその原因を受注者の能力に求めているのが分かります。おそらくは、貴方がプロジェクト開始前に受注者の能力を確認*しないで*、それで問題が起こった場合でも受注者のせいにするのでしょう。
貴方とはあまり仕事したくないですね……煽りではなく、本気で……
Re:言語を知ってるだけでは意味がない (スコア:0)
> おそらくは、貴方がプロジェクト開始前に受注者の能力を確認*しないで*、それで問題が起こった場合でも受注者のせいにするのでしょう。
内容がカンタンなものなら、「できるかね?」という確認程度で済む場合もあります。たとえば、「○○へ行ってくる」「××から○○をもらってくる」というような内容ですね。ITの場合は、カンタンな能力テストなどを受けてもらったり、実績をみて判断するんじゃないでしょうかね。
「受注者の能力を確認」については、裁判などでは発注者側にそうした義務を認めることはほとんどないですよ。なぜなら、「できないもの」を「できる」と言って受注作業を行ったら、受発注以前の話(詐欺)になるからです。