「書く」のは特別な道具 - naoyaのはてなダイアリー
This is why you shouldn't interrupt a programmer (なぜプログラマの作業に割り込むべきではないか) という4コマ漫画が話題になっていた。これは別にプログラマではなくても「わかるわかる」という感じの話。 コメントを見ると、だから作業を中断してもすぐ再開できるように自分の考えることをなるべく書き出すようにしているという人が結構多かった。なるほど。 今日は雨が降ったせいで予定が一つキャンセルになったことだし、ちょうどいい機会なので、文章で何かを書くということについて自分が思っていることを書いてみようとおもう。以前 Software Design のドキュメントの書き方特集みたいな号に似たような趣旨の話を寄稿したのだけど、「書く」というのは単に物事を忘れないようにするための行為に留まるものではなくて、自分の考えを整理するための道具なのだ、ということが
新人プログラマーに読ませて欲しいネーミングの大切さ - プログラマー幸福論
Photo from Kıvanç Niş ネーミングについてまじめに長文を書いてみました。もし、あなたの会社にネーミングに疎い新人プログラマーがいたら読ませてやってください。 ちなみに、この記事はシステム開発のネーミングについて書いています。また、このブログの特性上、英語でのネーミングを想定していますが、日本語のネーミングでも同様に考えることができると思います。 1. ネーミングの重要性 一般に、熟練のプログラマーほど、プログラミングにおける ネーミングに時間をかけます。それはなぜでしょうか。 あなたが付けたその変数名 data は、その時点では、自分のために付けた「目印的なもの」であったかもしれません。しかし、そのソースコードを引き継いだ担当者など多くの人が、その名前を見ることになります。 // データを取得する var data = getData(1); そしてその名前は、そのソー
Gitを使ったデザイナーとプログラマの協業について話してきた #P4D #phpcon2013 - 納豆には卵を入れる派です。
常連プログラマがほぼ Rubyist しかいないP4Dなのですが、なぜかPHPカンファレンスで枠をいただいたとのことで、デザイナーとGitについて話し合ってみようという企画に参加してきました。 「生煮えぷるり」をプログラマとデザイナーの間で行ったり来たりさせる話 Pull Request 4 Designers - GitHubを使ったプログラマとデザイナーのイテレーティブな開発フロー// Speaker Deck GitHubを使った、実際のプログラマとデザイナーの協業の様子を見てもらおうということで、私がお手伝いさせていただいている、[https://forkwell.com:title=Forkwell] と [https://jobs.forkwell.com:title=Forkwell Jobs] での開発の様子を例にお話させていただきました。 補足とか 「生煮えぷるり」という
プログラマは職人、力なければ淘汰されて然るべき―ソニックガーデン倉貫氏が問う、プログラマの覚悟。 | CAREER HACK
プログラマを一生の仕事に―と考えるソニックガーデンCEOの倉貫義人氏。人月ビジネスで時間を切り売りしているうちは、35歳定年説は覆せず、収入を上げるためにはマネジメントの道に進むしかない。人の管理ではなく、生涯プログラマであり続けるために必要な条件とは。 ▼ソニックガーデン代表倉貫氏へのインタビュー第1弾 “納品のない受託開発”とは何か？―ソニックガーデン代表 倉貫義人氏が全貌を語り尽くす。 プログラマを続けられる人、続けられない人。 「納品のない受託開発」というビジネスを確立したソニックガーデン。代表である倉貫氏は、「従来の受託開発は誰も幸せにできないモデル」と切り捨てる。倉貫氏の考える、新しいエンジニアの働き方とは何なのか。プログラマを一生の仕事にするために、必要な環境や能力とは。 人月商売は、エンジニアを馬鹿にしている。 ― 従来の受託開発モデルは、顧客・ベンダー・エンドユーザーから
2013.4.29 ゲーム製作のプロジェクト管理に関するお話
島国大和 @shimaguniyamato 俺自身、仕事でゲーム作り出した頃「現場に任せればもうちょっと上手く行くだろコレ」と思うような酷い指揮系統にいたが、「こんな現場良くに任せたな」みたいな現場も時々見る。結局人を見る目の有る無しだなという気がしている。で人を見る目がないと体育会系イエスマンに任せて失敗する。 島国大和 @shimaguniyamato 例えばプログラマがプログラムを組んでいる時というのは、例えるならば、いくつかの変数が脳内で常にマッピングされているみたいなもので、だからこそバリバリとプログラムが書ける。この状態はスポーツ選手のゾーンみたいなもので、入りにくいし終わりやすい。だからジャマしない。 島国大和 @shimaguniyamato 1つのゲームプロジェクトは長大なプログラムのソースで、どこかを弄ればどこかに影響が出る。ゲームのルールもそうで、何かを弄ればどこかに
エンジニアを頑張ったで評価する会社は衰退する | rake enjoy
この前飲み会でこんな話をしていたのでまとめてみます。 終身雇用が崩壊し、昨今では会社の評価制度では成果主義というのが普通になりつつあります。ただ成果主義とは言いつつ何を持って成果とするかは議論の余地があると思います。 例えば営業職であれば分かりやすく売上目標というものがあります。企画職の場合でも売上やその他のKPIを目標設定することで分かりやすく評価出来ると思います。ではエンジニアの場合はどうでしょうか。 開発したシステムが実際に軌道に乗って数字を出し始めるまでには相当時間がかかります。（最近のゲームなどは除く）またその数字が出るか出ないかは実際営業や企画側の問題が多分にある為、こういったケースでエンジニアを数字で評価するとシステムの良し悪しとは関係なく単純に運がいいか悪いかだけになってしまいます。もちろん企画に意見が反映出来る環境であったり営業に指示できる環境であればエンジニアでも数字を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch | Startup and Technology News