September 30 2014
Quote September 30 | 17:26


マーク・アンドリーセン、スタートアップのバーンレートが過大と18回連続ツイートで警告 - TechCrunch

Quote September 30 | 17:21



  • 通常のオフィススペースのかわりに家具付きのエグゼクティブ・オフィスを使う。コスト:約3倍。節約できる時間:数ヵ月から一年(マーケットの状況による)。
  • 法外な給料を払うか、スタート時ボーナスとしてBMWを提供する。コスト:技術スタッフに対し約25%余分の支出。節約できる時間:通常採用枠を埋めるのに6ヵ月かかるところが、3週間で済む。
  • 従業員の代わりにコンサルタントを雇う。コスト:約3倍。節約できる時間:コンサルタントは即座に仕事を始められる。
  • あなたが必要とするだけの時間と労力をコンサルタントに払わせられない?彼らがあなたのためだけに働きたいと思うようになるまで金を積めばいい。
  • 問題の即決のためにいくらでも金を使う。あなたの新しいスタープログラマが彼らの家の新築や引越しで忙しく、あまり仕事していないようなら、彼らのかわりにそれをやるハイクラスの引越しサービスを雇う。新しいオフィスに電話を引くのにいつまでも時間がかかるようなら、携帯電話を2ダースほど購入する。インターネットアクセスの問題が仕事の支障となっている?余分に2つほどのプロバイダと契約する。ドライクリーニングのピックアップや予約や空港へのリムジンの手配などを行うコンシェルジュを用意し、全従業員が使えるようにする。

Joel on Software - ストラテジー・レターⅠ: ベン&ジェリー 対 アマゾン

September 23 2014
Quote September 23 | 17:26


OK, seriously this time.  I think there are really a few things that distinguish great programmers.

  1. Know the concepts.  Solving a problem via memory or pattern recognition is much faster than solving it by reason alone.  If you’ve solved a similar problem before, you’ll be able to recall that solution intuitively.  Failing that, if you at least keep up with current research and projects related to your own you’ll have a much better idea where to turn for inspiration.  Solving a problem “automatically” might seem like magic to others, but it’s really an application of “practice practice practice” as Miguel Paraz suggests.
  2. Know the tools.  This is not an end in itself, but a way to maintain “flow” while programming.  Every time you have to think about how to make your editor or version-control system or debugger do what you want, it bumps you out of your higher-level thought process.  These “micro-interruptions” are small, but they add up quickly.  People who learn their tools, practice using their tools, and automate things that the tools can’t do by themselves can easily be several times as productive as those who do none of those things.
  3. Manage time.  Again it comes back to flow.  If you want to write code, write code.  If you want to review a bunch of patches, review a bunch of patches.  If you want to brainstorm on new algorithms … you get the idea.  Don’t try to do all three together, and certainly don’t interrupt yourself with email or IRC or Twitter or Quora.  ;)  Get your mind set to do one thing, then do that thing for a good block of time before you switch to doing something else.
  4. Prioritize.  This is the area where I constantly see people fail.  Every problem worth tackling has many facets.  Often, solving one part of the problem will make solving the others easier.  Therefore, getting the order right really matters.  I’m afraid there’s no simple answer for how to recognize that order, but as you gain more experience within a problem domain - practice again - you’ll develop a set of heuristics that will guide you.
  5. Reuse everything.  Reuse ideas.  Reuse code.  Every time you turn a new problem into a problem you already know how to solve - and computing is full of such opportunities - you can save time.  Don’t worry if the transformed solution isn’t absolutely perfect for the current problem.  You can refine later if you really need to, and most often you’ll find that you’re better off moving on to the next problem.

Jeff Darcy’s answer to What are the best-kept secrets of great programmers? - Quora

September 16 2014
Quote September 16 | 14:53

"Competition Is for Losers"

Peter Thiel: Competition Is for Losers - WSJ

September 14 2014
Picture September 14 | 16:37
Nihon Typeface on Behance

Nihon Typeface on Behance