yannickt

This is a very, very good read. Thanks for sharing.

I think buildings are better understood in large part because they are not nearly as malleable. Because software is highly malleable by nature, the complexity and scope of decisions can grow much faster than in any other engineering discipline.

What Is Software Design? http://www.developerdotstar.com/mag/articles/reeves_design.h...

FTA:

There is one consequence of considering code as software design that completely overwhelms all others. It is so important and so obvious that it is a total blind spot for most software organizations. This is the fact that software is cheap to build. It does not qualify as inexpensive; it is so cheap it is almost free. If source code is a software design, then actually building software is done by compilers and linkers.

Edit: brain failure on my part.

It's an interesting read. Previous HN discussion: https://news.ycombinator.com/item?id=5383650

"Amazon's vesting schedule is 5%, 15%, 40%, and 40% over the 4 years"

This is a significant deviation from the industry standard, which is to have a one year cliff, and have stock vest month-to-month afterwards. What happens if you leave in the middle of year 3?

If I had to recommend _one_, it would be Four Pillars. The first part is a bit more intellectually "challenging" than Random Walk, but ultimately does a better job (IMO) at backing up the author's ideas on personal investing with data.

Random Walk covers all the major bubbles in history, and does an excellent job at breaking down asset allocation per age range in the later sections of the book.

All About Asset Allocation was very useful to me in developing a long term investment plan, and deciding what asset classes to include in my portfolio.

I refer to each book at least once a year.

https://blogs.msdn.microsoft.com/larryosterman/2004/08/27/it...

I've read both Four Pillars and Random Walk; I refer back to the former much more often than the latter. But both are great books.

http://yosefk.com/blog/do-call-yourself-a-programmer-and-oth...

I think it is also wrong to generalize like that. There are renters who are disciplined enough to invest most of their "surplus of money" in appreciating assets. One can even invest in real estate without buying a home. Depending on location, a disciplined renter may well come out way ahead of the owner. IMO, that's a message that we should hear more often.

In my experience, this is not uncommon, especially with C++ codebases. I've seen quite a few style guides that go in at least as much detail as Carmack's guide. Two publicly available guides that come to mind are the Google[1] and Webkit[2] style guides.

Maybe it's just me, but I don't find the Doom 3 code style that exemplary or exceptional.

[1] http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...

[2] http://www.webkit.org/coding/coding-style.html

The first is that they ignore or gloss over the fact that there is no shortage of world class software written without TDD. I also have yet to see any great programmer preach the virtues of TDD.

The second is that they blur the line between TDD and unit testing, maybe intentionally. I don't use TDD, but that doesn't mean I don't write unit tests. I just don't write unit tests all the time, and I don't write them first most of the time. In fact I think the advocates would have better success if they advocated plain unit testing instead of TDD.

What irritates me though is that several valid criticisms of TDD have been published (1), and in some cases the advocates (Uncle Bob included) were given an opportunity to respond, but did so poorly, or just didn't bother at all. This sends a message that they are trying to sell something.

TDD has its place, but it is not always the right tool, and it is certainly not a silver bullet.

(1) - Andrew Dalke's "Problems with TDD" may be the best criticism of TDD that I've read so far. The exchange between Dalke and Uncle Bob in the comments is also revealing. http://dalkescientific.blogspot.ca/2009/12/problems-with-tdd...

- Jacob Proffitt also wrote a classic (IMO) on the subject. http://theruntime.com/blogs/jacob/archive/2008/01/22/tdd-pro...

http://www.gamecareerguide.com/features/1108/game_developer_...

One game per year is actually pretty good for studio of Valve's stature, especially if you consider that many of those 400 work mostly, and maybe exclusively, on Steam. It is not uncommon for highly profitable studios to release just a few games each decade, especially if they are independent. So it is important to keep things in perspective. Half-Life 2 was released in 2004. Per Wikipedia, this is the list of games developed by id Software (200+ employees) since 2004:

- Wolfenstein 3D Classic (2009)

- Doom Classic (2009)

- Quake Live (2010)

- Rage HD (2010)

- Rage (2011)

- Doom 3 BFG Edition (2012)

Of those, probably only Rage sold a significant number of copies across all platforms. id Software also published the following games in the same time frame:

- Doom 3: Resurrection of Evil — Nerve Software (2005)

- Quake 4 — Raven Software (2005)

- Doom RPG — Fountainhead Entertainment (2005)

- Orcs & Elves — Fountainhead Entertainment (2006)

- Enemy Territory: Quake Wars — Splash Damage (2007)

- Wolfenstein RPG — Electronic Arts (2008)

- Doom Resurrection — Escalation Studios (2009)

- Wolfenstein — Raven Software (2009)

Of those, my guess is that only Quake 4, and maybe Wolfenstein, sold in significant amounts.

Since 2004, Valve has shipped HL2:EP1, HL2:EP2, Portal, Team Fortress 2, L4D 1, L4D 2, Portal 2, Alien Swarm and CS:GO. While none was the hit that HL2 was, few studios have achieved that level of success in the same time frame.

Or take a look at Blizzard. They have at least five, maybe ten times as many employees as Valve, but have released "only" five or six games since 2004, most of which were WoW extensions.

My point is that if Valve is not shipping games at a faster pace, it's because they can afford it. Steam is probably printing enough money that they can afford to spend as much time as they want iterating on their engines and games. I would be very surprised if you were right about the motivations for the layoff.

"Valve is going to build a new cross-platform engine [...] HL3 will be the showcase for this engine."

This isn't much of a prediction. HL2 was released on multiple platforms, and it is reasonable to assume that HL3 will follow suit.

Edit: Gabe Newell has addressed the speculations. http://mobile.theverge.com/2013/2/13/3986540/valves-gabe-new...

For the Ouya to "smoke" other consoles in sales, it will have to offer something unique, and that looks like a really tall order at this point.

Here's the link: http://blogs.msdn.com/b/visualstudio/archive/2012/06/20/the-...

Also, Apple pays dividends, and they have enough cash to operate for 1-5 years on zero sales. They are better positioned (IMO) to reinvent themselves without being rushed, and at the same time minimize the potential negative impact of that reinvention to their shareholders.

http://www.stroustrup.com/C++11FAQ.html#template-alias

   class Foo {
   public:
      Foo() : myBar(0), myBaz(0)
      {
         myBar = new Bar;
         myBaz = new Baz;
      }
      ~Foo
      {
         if (myBar) delete myBar;
         if (myBaz) delete myBaz;
      }
   private:
      Bar *myBar;
      Baz *myBaz;
   };

   class Foo {
   public:
      Foo() : myBar(new Bar), myBaz(new Baz)
      {
      }
   private:
      std::unique_ptr<Bar> myBar;
      std::unique_ptr<Baz> myBaz;
   };

You would only need to use shared_ptr when ownership is shared among multiple objects. A shared_ptr holds a reference counter that is incremented every time it is copied, and decremented every time it is destroyed or re-assigned. When the reference counter reaches zero, the pointer is automatically deleted.