Well, the numbers are in for 2005. We watched 116 Netflix movies last year. That's an average of 9.6 movies per month at $1.88 each. Netflix doesn't exactly make it easy to figure this out - except that they send emails that can be collected. Maybe there's some sort of Long Tail or Web 2.0-ish opportunity here...
I wonder how many Netflix disks were lost because of Hurricane Katrina?
Friday, March 17, 2006
Saturday, March 04, 2006
The Economics of Expertise
Kathy Sierra, contributing author to O'Reilly's Head First series, Sun's Java certification exams, and Creating Passionate Users makes some interesting points in "How to be an expert". It's another great post embodying the unifying theme of how to kick ass.
In my opinion, there are some very real economic decisions made when evaluating how far down the expert road you want to get. I tend to agree that we practice the things we're already good at. I also agree to an extent that we avoid things we suck at, but I'm not sure it's because we make a decision to be mediocre. I think it has as much to do with the value of our time, or an organization's time, as much as anything.
The point was made, "Yet the research says that if we were willing to put in more hours, and to use those hours to practice the things that aren't so fun, we could become good." I totally understand the point of this sentence. From a pragmatic standpoint, this could describe more time in test-driven development, or an extra evening at a user's group meeting, or really digging into SOAP with that next web service. But I only have 24 hours in a day and I need to sleep for some of that time! So those other 17-ish hours of my day have some real economic value to me, my family, and possibly other people.
It seems the value of becoming an expert sometime in the future is constantly weighed against the near-term value of that time. And the distance into the future seems to be significant as well. For example, O'Reilly's home page currently displays a heading: "Technology Doesn't Wait-- Neither Should You". In other words, we have a relatively short amount of time to maximize our expertise in a technology. Entity beans? Stateless session beans is the way to go. EJB? Why? Don't you know that Hibernate with Spring probably solves the same problem? Struts? You should consider Ajax with JSF. JavaScript and JSP? Why not a C# .NET smart client..? And on and on for eternity. Sure, I can still put in more hours and become an expert in C or SmallTalk. And yes, being an expert in anything at any time is worthy of some merit. But what it comes down to is this: is the payoff at the end of the expert road worth the time that I missed on other things, particularly, playing with my kids? In technology, that value is diminished with every passing day.
So this is probably the reason why I still have not actually changed the oil in my car myself. There are experts out there that can do it for me. And in the end, I guess I'll live with mediocrity in investing, remodeling my house, or playing that saxophone that's in my basement. But that's because I am trying as a software engineer. And frankly, I'm able to convince my employer to pick up a portion of the economic cost of traveling down that road. But most importantly, I'm well on my way to becoming an expert at being a dad. And I think the economic benefits of that to our world will probably outweigh my contributions as an engineer.
In my opinion, there are some very real economic decisions made when evaluating how far down the expert road you want to get. I tend to agree that we practice the things we're already good at. I also agree to an extent that we avoid things we suck at, but I'm not sure it's because we make a decision to be mediocre. I think it has as much to do with the value of our time, or an organization's time, as much as anything.
The point was made, "Yet the research says that if we were willing to put in more hours, and to use those hours to practice the things that aren't so fun, we could become good." I totally understand the point of this sentence. From a pragmatic standpoint, this could describe more time in test-driven development, or an extra evening at a user's group meeting, or really digging into SOAP with that next web service. But I only have 24 hours in a day and I need to sleep for some of that time! So those other 17-ish hours of my day have some real economic value to me, my family, and possibly other people.
It seems the value of becoming an expert sometime in the future is constantly weighed against the near-term value of that time. And the distance into the future seems to be significant as well. For example, O'Reilly's home page currently displays a heading: "Technology Doesn't Wait-- Neither Should You". In other words, we have a relatively short amount of time to maximize our expertise in a technology. Entity beans? Stateless session beans is the way to go. EJB? Why? Don't you know that Hibernate with Spring probably solves the same problem? Struts? You should consider Ajax with JSF. JavaScript and JSP? Why not a C# .NET smart client..? And on and on for eternity. Sure, I can still put in more hours and become an expert in C or SmallTalk. And yes, being an expert in anything at any time is worthy of some merit. But what it comes down to is this: is the payoff at the end of the expert road worth the time that I missed on other things, particularly, playing with my kids? In technology, that value is diminished with every passing day.
So this is probably the reason why I still have not actually changed the oil in my car myself. There are experts out there that can do it for me. And in the end, I guess I'll live with mediocrity in investing, remodeling my house, or playing that saxophone that's in my basement. But that's because I am trying as a software engineer. And frankly, I'm able to convince my employer to pick up a portion of the economic cost of traveling down that road. But most importantly, I'm well on my way to becoming an expert at being a dad. And I think the economic benefits of that to our world will probably outweigh my contributions as an engineer.
Wednesday, March 01, 2006
Open AJAX Consortium Looks to Ease Development
One of the interesting points that Laszlo Systems CTO David Temkin makes in this interview is the relative lack of good UI developers out there, specifically in the J2EE realm. I think he's correct in stating that a good J2EE developer tends to be proficient more on the server side than on the client. And maybe that's because there's relatively much less Java code actually involved in the display when you're talking about a web application - witness the rise of Ajax. Also, a good UI developer has to be so much more than just a software engineer. A good UI developer needs to be part psychologist, part designer in the pure sense, part artist, part engineer, a users' advocate (gasp), and extremely detail-oriented. On top of that, a good J2EE UI developer probably needs to work well in other technologies such as HTML, JavaScript, CSS, XML/XSL, and even Flash. True, these are not so much of a technical stretch compared with J2EE technologies, but it is a bit of a stretch to expect the same person to be truly exceptional in all of the technologies (jack of all trades, master of none).
The one thing that catches my attention most about Ajax splashed across java.sun.com, developerWorks, and TheServerSide is that these same people were touting XP not very long ago. And granted, I understand that these folks must live on the edge. But I find it so interesting that we've shifted from test driven development and best-practices to getting something out the door quickly. And a "something" which isn't based on a standard framework (as this article points to), can't easily be unit tested, has very little tool support, and actually isn't even grounded in Java!
I'm excited about these developments but I'm also interested in watching how they play out with Windows Vista and XAML lurking around the corner.
The one thing that catches my attention most about Ajax splashed across java.sun.com, developerWorks, and TheServerSide is that these same people were touting XP not very long ago. And granted, I understand that these folks must live on the edge. But I find it so interesting that we've shifted from test driven development and best-practices to getting something out the door quickly. And a "something" which isn't based on a standard framework (as this article points to), can't easily be unit tested, has very little tool support, and actually isn't even grounded in Java!
I'm excited about these developments but I'm also interested in watching how they play out with Windows Vista and XAML lurking around the corner.
Subscribe to:
Posts (Atom)
