タグ

programmingとmanagementに関するhidex7777のブックマーク (9)

  • Early Work

    初期の作品 --- Early Work Paul Graham, October 2020 これは、Paul Graham: Early Work を、原著者の許可を得て翻訳・公開するものです。 <版権表示> 和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。 (「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。 Copyright 2020 by Paul Graham 原文: http://www.paulgraham.com/early.html語訳:Shiro Kawai (shiro @ acm.org) <版権表示終り> Paul Graham氏のエッセイをまとめた『ハッカーと画家』の 邦訳版が出版されました。 出版社の案内ページ Amazon.co.jp サポートページ 2020/10/20 翻訳公開

    Early Work
  • 会社でjQuery使ったら無能上司に怒鳴られたんだがwwwww : IT速報

    1: 仕様書無しさん 2014/09/22(月) 12:19:06.02 .net jqueryで書いてたら怒鳴られた うちでは使うなって・・・こっちのが簡単じゃん・・・なんで書けないの 3: 仕様書無しさん 2014/09/22(月) 13:47:22.65 .net 世の中には馬鹿で無能な会社もあるってことよ。 15: 仕様書無しさん 2014/09/22(月) 20:16:36.27 .net ゴミのような上司だな。 もしシステム屋なら直ちに転職しろ。 6: 仕様書無しさん 2014/09/22(月) 15:25:28.97 .net >>1 新人かい? なんで使ったらいけないのか理由を聞きな。 納得できたなら使わなければいいし、納得出来ないなら説得してみればいい。 説得して無理なら、諦めるか配置換え希望出すか転職するか。 12: 仕様書無しさん 2014/09/22(月) 18:3

    会社でjQuery使ったら無能上司に怒鳴られたんだがwwwww : IT速報
    hidex7777
    hidex7777 2015/02/11
    これはひどい
  • デザインは理屈で学べる! エンジニア向けデザインメンター業が求められる理由について聞いた | HRナビ by リクルート

    アイデアは面白いのに、どうもダサかったり、UIがわかりにくかったりするWebサービスに出会ったことはないだろうか。 それはもしかすると、デザインを知らないエンジニアが、ふわっとした感覚と印象で作っているからなのかもしれない。そんなエンジニアでも、デザインのセンスを身につけることはできるのだろうか? プログラマー向けにデザインを教える“デザインメンター”赤塚妙子さんに話を聞いた。 プログラミングを学んだデザイナーが始めた“デザインメンター業“ 今年の1月から“デザインメンター業”を始めたフリーランス デザイナーの赤塚妙子さん。美大を卒業後、デザイン事務所に就職。その後、Webの世界へ足を踏み入れ、今ではRuby on Railsの開発に参加するまでになった。 「自分がプログラミングを覚える中で、デザイナーとプログラマーが歩み寄る感じが面白くって。デザイナーがプログラミングを覚えることはあるけ

    デザインは理屈で学べる! エンジニア向けデザインメンター業が求められる理由について聞いた | HRナビ by リクルート
  • 努力とセンスの関係と優秀なプログラマー - ワザノバ | wazanova

    http://www.quora.com/What-are-the-best-kept-secrets-of-great-programmers/answer/Jeff-Darcy? 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約5時間前 スポーツにしろ、勉強にしろ、仕事にしろ、何をやるにもその特定の分野でトップ1%人は尊敬するほどすごいのですが、人が長く続けつつ努力をしてきたことが垣間見えるので、なぜ優秀なのかというのが理解できる範囲。ただし、そのさらにトップ10%、いわゆる世の中でその分野のトップ0.1%の人というのは、すごすぎて、どうしてそうなれるのかが分からないと実感することがあります。議論している時に、数歩先の真理を理路整然と突然読み取って指摘されるような、驚くようなセンスを見せつけられる経験を数

  • 全日本デスマーチ選手権

    今週もやってまいりました。 全日デスマーチ選手権。 日中の兵どもが、プロジェクトを破壊するために死闘を尽くします。 日は解説にギコさんをお呼びしております。 さぁ、ギコさん、ウンコーダ選手のまなざしはどうですか? 「いやー面接じゃなにもわかりませんからねぇ。どんな荒業が飛び出すか想像もできません」 では、注目してみてまいりましょう。 おっと!ウンコーダ選手、テストコードの記述を拒否!!!!! やったことがないから、できませません!!!!! でたーーーー!!開幕早々の大技だ! 「これはすごいですね。難しそうな作業は全部拒否するATフィールドを展開して、リーダを牽制しています」 おっと、リーダ、い下がる。 しかし、理屈にならない理屈を並べて攻撃をかわします。 「面接でみせた、一見、口が上手くてコミュニケーションが得意そうにみえるという罠にはまりましたね。現場を離れた人が面接官だとよくひ

    全日本デスマーチ選手権
  • リリースの高速化はWebサービス企業にとって最重要である - Kentaro Kuribayashi's blog

    インターネットを眺めていたら、リリースの高速化自体を目的化するのではなく、ビジネス成果によって成否を判断するべきだという主張があったので、思うところを書いておく。起点は他社さんにおける議論だが、そこは問題ではなくて、もし自分の関わるところでそういう議論が起こったら、自社の技術に対してそれなりのポジションにおいて関係する人間としてどのように考えるべきだろうかという視点で述べる。 リリースあるいはリリースの高速化自体を目的化するのではなく、その結果としてのビジネス的成果が大事だということは、マネジメントにとっては当たり前なわけで、いちいちいうまでもないことだろう。そもそも、サービスが圧倒的に成長し続けていれば、リリース頻度 = 成果になるはずだ。現状そうでないのであれば、成長速度が遅いということになる。エンジニア技術を尽くしてリリース速度を向上させたにも関わらずそれが成果に結びつかないとした

    リリースの高速化はWebサービス企業にとって最重要である - Kentaro Kuribayashi's blog
  • 先に相手の予算聞けよ

    見積もり初心者の増田君にマジレスな。 先に相手に予算聞いて「う~ん、200万ぐらいかな~」って言ってきたら、それに合わせて見積もり作れ。 簡単な要求でも200万円分の機能をつけてやればいいし、難しい要求なら200万円以内でできる仕様にすればいい。 これができれば見当違いだったり桁違いの見積もり出して大失敗することはないし、確度はかなり高い。 ある程度精度のある見積もりを作った方がいい。 要求仕様だけ見せてきて予算を言ってこない場合は「降り」 これは発注先が決まっていて、社内でちゃんと相みつ取った証拠に使われるだけで完全に無駄な労力になる。 出すならバカ高い金額で適当に作った見積書出しておけ。 マジなコンペも「降り」 零細企業は5分の1とかのコンペに付き合ってる暇はない。 金額は限界まで下げないと取れないし、仮に取れても要求仕様も期間も厳しくなってデスマーチ確定。 無理しすぎたせいで納期内に

    先に相手の予算聞けよ
  • ドメイン駆動設計読んだ - hitode909の日記

    ドメイン駆動設計というのはソフトウェア工学のおしゃれなで,Kindleで買えたので読んだ.ドメインを軸に戦略的に設計しましょうという.2週間くらいで読めて良い体験できてよかった. ソフトウェアを,ユーザーインタフェース,アプリケーション,ドメイン,インフラストラクチャという4つの層に分けて,一番重要なのがドメイン層で,ドメイン層にアプリケーションが存在し得る理由がある.銀行システムだったら,口座とか利子みたなやつがドメイン層で,口座がよくできてると銀行としてうまくいく.ATMのタッチパネルというのはユーザーインタフェースで,どんなにATM押しやすくても,ドメイン層に,口座という概念がなくて,ただのハッシュだったりすると,銀行を運営して金を儲けるとか,新たな金融商品とか作るのが困難になる.インフラ層は永続化とかするのだけど,インフラ層がいかによくても,意味ないデータを保存していては銀行倒

    ドメイン駆動設計読んだ - hitode909の日記
  • 技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog

    元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニア

    技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
  • 1