アカウント名:
パスワード:
なぜこれが良いプログラマかどうかの判定にできるのかの根拠を知りたい。
自分の狭い経験だけで、単純に判定しようとする人とは仕事したくないなあ
自分はこれは悪くないひとつの判定基準だと思う入力された配列のすべての要素が条件を満たす場合に~ってときに空配列が入ってきた場合を聞くのはその人が問題をどう扱うかを見れる
回答は「このライブラリではtrueになります」とか「前職のプロジェクトではfalseになってました」でもいいんですよ一番ききたいのはそのtrue/falseにした理由そこでもし筋の通った理屈で問題を解決していればOK、もしも「このライブラリではそうなっています」とか「過去のプロジェクトでそうなっていたからです」という理由しか出てこなかったらNGね
自分は良いプログラマというのは良い問題解決者でもあると考えているので、そういう意味でこれは良い質問かな、と
確かにどっちを選ぶじゃなくて、選んだ理由を共有することが出来るがどうかでも今使おうとしてるプログラマとの意思疎通は出来るけど将来使うだろう人をどれだけ想定出来るかどくか
説明書に書いたとしても読まない人には対処出来ないし
ちゃんと空気が読めてるかどうかってことであって、プログラマ以前に、社会人としてどうかって話だと思う。もちろん、resultがどうあれ、自分の仕事ができるのが正解。この関数と同じ。
数学、ブール代数の知識があればこの問いの答えはTrueというのはすぐにわかる。あるいは、世の中の多くのライブラリではTrueが返ってくるという知識も持っていてしかるべき。
絶対にFalseがダメだとは言わないけど、もしFalseと答えて、その理由付けが適切なものではない場合は良いプログラマとは言えないだろうね。
答えが数学では、ってのは慣習にすぎないそれを正しいと言い切るとか、書き順とかにまうるさいタイプだろうな
コメントの1行目しか読めない人、そして書いて無い情報を勝手に自分で付け加える人は、良いプログラマとは言えないでしょうね。
そりゃ良いプログラマってのは上長や客先の顔色を正しく読み取れる人のことだからな#本物のプログラマはコメントも、仕様書も読まない、読む工数がもったいない
未定義に対して独自判断で実装する阿呆を炙り出せます仕様確定を依頼してこないなら使いっぱしりにも使えません
そんなのは立場によって色々だろ。あなたの立場だったらそれが正解というだけ。
立場関係なしに、未定義もしくは曖昧なことに関する意見を求められているとして、どう答える?
全て客に聞くと言うのが正統な多重請負の姿。作業員としての根性が染みついてるので、自分で判断や提案は=悪となる。
そう、あくまで判断するのは客でも聞き方って割と重要で、「どうしましょう?」というよりかは「こうしましょうか?」という問いかけを作ったほうが相手としても判断しやすいし何より自分の力になる場合が多い#もちろんこっちから試案を出したら「余計なことすんな!」って場合もあるから相手をよく見るのと経験も必要だけどね#でもちゃんと対案つくって実力つけていったら割とすぐにそんな場所からはオサラバできたりするよ!
貴重な意見、ありがとう。そこまで想像が及ばなかった。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
というか (スコア:1)
なぜこれが良いプログラマかどうかの判定にできるのかの根拠を知りたい。
自分の狭い経験だけで、単純に判定しようとする人とは仕事したくないなあ
Re:というか (スコア:1)
自分はこれは悪くないひとつの判定基準だと思う
入力された配列のすべての要素が条件を満たす場合に~ってときに空配列が入ってきた場合を聞くのはその人が問題をどう扱うかを見れる
回答は「このライブラリではtrueになります」とか「前職のプロジェクトではfalseになってました」でもいいんですよ
一番ききたいのはそのtrue/falseにした理由
そこでもし筋の通った理屈で問題を解決していればOK、もしも「このライブラリではそうなっています」とか
「過去のプロジェクトでそうなっていたからです」という理由しか出てこなかったらNGね
自分は良いプログラマというのは良い問題解決者でもあると考えているので、そういう意味でこれは良い質問かな、と
Re: (スコア:0)
確かに
どっちを選ぶじゃなくて、選んだ理由を共有することが出来るがどうか
でも今使おうとしてるプログラマとの意思疎通は出来るけど
将来使うだろう人をどれだけ想定出来るかどくか
説明書に書いたとしても読まない人には対処出来ないし
Re: (スコア:0)
ちゃんと空気が読めてるかどうかってことであって、プログラマ以前に、社会人としてどうかって話だと思う。
もちろん、resultがどうあれ、自分の仕事ができるのが正解。この関数と同じ。
Re: (スコア:0)
数学、ブール代数の知識があればこの問いの答えはTrueというのはすぐにわかる。
あるいは、世の中の多くのライブラリではTrueが返ってくるという知識も持っていてしかるべき。
絶対にFalseがダメだとは言わないけど、もしFalseと答えて、その理由付けが適切なものではない場合は良いプログラマとは言えないだろうね。
Re: (スコア:0)
答えが数学では、ってのは慣習にすぎない
それを正しいと言い切るとか、書き順とかにまうるさいタイプだろうな
Re: (スコア:0)
コメントの1行目しか読めない人、そして書いて無い情報を勝手に自分で付け加える人は、良いプログラマとは言えないでしょうね。
Re: (スコア:0)
そりゃ良いプログラマってのは上長や客先の顔色を正しく読み取れる人のことだからな
#本物のプログラマはコメントも、仕様書も読まない、読む工数がもったいない
Re: (スコア:0)
なぜこれが良いプログラマかどうかの判定にできるのかの根拠を知りたい。
未定義に対して独自判断で実装する阿呆を炙り出せます
仕様確定を依頼してこないなら使いっぱしりにも使えません
Re: (スコア:0)
そんなのは立場によって色々だろ。あなたの立場だったらそれが正解というだけ。
立場関係なしに、未定義もしくは曖昧なことに関する意見を求められているとして、どう答える?
Re: (スコア:0)
全て客に聞くと言うのが正統な多重請負の姿。
作業員としての根性が染みついてるので、自分で判断や提案は=悪となる。
Re: (スコア:0)
そう、あくまで判断するのは客
でも聞き方って割と重要で、「どうしましょう?」というよりかは「こうしましょうか?」という問いかけを作ったほうが
相手としても判断しやすいし何より自分の力になる場合が多い
#もちろんこっちから試案を出したら「余計なことすんな!」って場合もあるから相手をよく見るのと経験も必要だけどね
#でもちゃんと対案つくって実力つけていったら割とすぐにそんな場所からはオサラバできたりするよ!
Re: (スコア:0)
貴重な意見、ありがとう。そこまで想像が及ばなかった。