いっしょに仕事をしたいプログラマ 5つの特徴 - たごもりすメモ
ちょっとこんなことを考えるきっかけがあったので、ざっと書き出してみた。Webに公開されている情報からあるプログラマについて見てみたとき、どういう人ならいっしょに働いてもいいかについて。 ここに書く内容はソースコードの品質以前の問題についてのみにしてある。だからこの特徴を満たしていればどうということに直接なるわけではない。ただ、欠けているところがあれば、少なくとも自分はその人といっしょに仕事をしたいとは思わないだろう。 なお自分は現勤務先の採用活動にはかかわっておらず、このエントリの内容は勤務先の採用基準とは全く無関係です。 学生さんなどの場合にはまた話が違うと思います。 あと割と自分のことは棚に上げてます。「お前これできてねえじゃん」という部分については都度ご指摘をいただけますと大変ありがたく思います……。 1. その人が書いたソースコードが公開されている 日本語で何を言われてもぶっちゃけ
プログラマの嫁が知るべき97のこと - Cube Lilac
まとめ第2弾。個人的には プログラマが知ろうが知るまいがどうでもいい97のこと - Togetter に期待していたのですが、これは 97 個揃えるのはちょっと無理ゲーのようです。尚、ここ最近の一連のまとめの元ネタは プログラマが知るべき97のこと です。類似ネタの プログラマが知るべきではない97のこと、プログラマが体験するべきではない50のこと も併せてどうぞ。 切りのいい数字とは 2進数です 片手で 31 まで数えられる 万能じゃない "パソコン"に強くない プログラマだからといって Office シリーズに精通してるわけじゃない あ、その作業は事務のお姉さんの方が得意だと思います カナ入力に変えたら必ずローマ字入力に戻しとけ プログラムの GC は得意でも部屋の GC は得意でない マルチスレッド処理は書けてもマルチスレッド処理はできない Amazon で買っているのは技術書だから
自分はプログラマなんだなと実感すること：アルファルファモザイク
どんな時に自分はプログラマなんだなと実感しますか？ 皆さんの実感体験・経験を教えてください 私は「全角英数字を見るとあーあって思ってしまう」ことです 仕様書無しさん :2008/04/28(月) 12:07:45 Oxfordが16進数に見えた時 3 仕様書無しさん :2008/04/28(月) 12:22:05 4 仕様書無しさん :2008/04/28(月) 13:29:33 256や512をキリ番だと思ってしまうとき 5 仕様書無しさん :2008/04/28(月) 14:24:02 彼女いない暦＝自分の年齢を当たり前と思うとき 6 仕様書無しさん :2008/04/28(月) 18:39:15 自販機とか家電を見るとアルゴリズムを考えている 8 仕様書無しさん :2008/04/28(月) 21:38:52 もうひとつ を ぷらすいち っていってしま
Fine Software Writings
最近のもの 目標でなく恐怖を明確にすべき理由 (Tim Ferriss) 我々が築き、掘っている未来 (Elon Musk) 表計算ソフト誕生の話 (Dan Bricklin) Linuxの背後にある精神 (Linus Torvalds) 先延ばし魔の頭の中はどうなっているか (Tim Urban) 好きになる仕事はどうしたら見つかるのか (Scott Dinsmore) 人間に新たな感覚を作り出すことは可能か？ (David Eagleman) 人工知能が人間より高い知性を持つようになったとき何が起きるか？ (Nick Bostrom) 厄介な問題を解決したい？ ではトーストの作り方を説明してください (Tom Wujec) 子供の夢を奪う学校というシステム (Seth Godin) 彼らがいなくなってしまう前に (Jimmy Nelson) 頭良さそうにTED風プレゼンをする方法 (W
頭の中にプログラムを入れる
Paul Graham / 青木靖 訳 2007年8月 いいプログラマは、自分のコードに集中しているとき、それを頭の中に保持しておくことができる。数学者が取り組んでいる問題を頭の中に入れているのといっしょだ。数学者は学校で子供たちが習っているように、紙の上で問題の解いているわけではない。彼らは多くの部分を頭の中でやっているのだ。問題の領域をよく把握しようと努めることで、普通の人が記憶にある育った家の中を歩き回れるように、数学者は頭の中で問題空間を歩き回ることができる。最高の状態で行われるプログラミングもそうだ。プログラムの全体を頭の中に入れたなら、それを思い通りに操れるようになる。 これはプロジェクトのはじめにおいては特に価値がある。それはプログラムを作り始めるときに最も重要なことが、やっていることを変えられるということだからだ。単に問題の解き方を変えるという ことではなく、解いている問題
抽象度は関係ないと思う | おごちゃんの雑文
Matzの日記より。 初心者向けの言語 言語が初心者向きだとかそうでないとか、「高度」であるかどうかと「抽象度」はまるっきり関係ないはずだ。 まぁどうせこの手のネタにつっこむ人はいっぱいいるだろうから、私がつっこむ必要もないとは思うけど。 Matzの言うように、「抽象度が高い」ということと「初心者から遠い」ということに関係があるのであれば、一番初心者向けの言語は アセンブラ ということになってしまう。それも、下手なOSなんかの上じゃなくて、生ハードウェア上のアセンブラ。や、最近のアセンブラはいろいろ下層のレジスタとか操作出来ないから、マイクロプログラムの方がいいか。これが一番初心者向けの言語だ。 逆に、初心者向けでない方向で言うなら、たとえば「テレビを見る」という行為。これはとんでもなく抽象度が高い。スイッチを入れてチャンネルを指定するだけで、いろんな人達のいろんな行動が見える。「いろんな
「ググるな危険」が呼んだ波紋
11月のトップを飾ったのはひでみ氏の「ググるな危険」。エンジニアライフ歴代トップクラスのアクセス数とはてなブックマーク数を叩き出し、話題となった。 ひでみ氏の主張は、いたってシンプル。「自分で説明できないコードを1行たりとも書くな！」である。特に新人の場合、検索してコピペして、はい動いた……というのは危険である。検索エンジンに頼り過ぎず、自分の頭で考えて、自分の頭で理解することが、エンジニアとしての成長には不可欠である。 とはいえ、話はそう簡単には終わらない。「うちの会社でもよくある。まったくその通り」という意見があれば、「新人が質問しづらい雰囲気を作る上司に問題があるのではないか」という反論も散見される。新人にどこまで丁寧に教えるべきか。聞きに来るまで待つべきか。あなたの意見を教えてほしい。 なお、第2位ではおなじみ生島勘富氏が、このコラムを受けて持論を展開している。「待っていれば会社は
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
