Link
From the Cool Tools blog:
If you've ever wondered how to model something, or were looking for new ideas for segmenting and presenting complex concepts, this is an incredible online resource.
Friday, December 19, 2008
Programmer's Bill of Rights
I would say this goes for anyone analyzing data, as well.
Blog post by Jeff Atwood of Coding Horror
Blog post by Jeff Atwood of Coding Horror
- Every programmer shall have two monitors
- Every programmer shall have a fast PC
- Every programmer shall have their choice of mouse and keyboard
- Every programmer shall have a comfortable chair
- Every programmer shall have a fast internet connection - Good programmers never write what they can steal.
- Every programmer shall have quiet working conditions - Programmers cannot work effectively in an interrupt-driven environment.
Hardware is Cheap, Programmers are Expensive
Blog post by Jeff Atwood of Coding Horror
Given the rapid advance of Moore's Law, when does it make sense to throw hardware at a programming problem? As a general rule, I'd say almost always.
Incidentally, this is also why failing to outfit your (relatively) highly paid programmers with decent equipment as per the Programmer's Bill of Rights is such a colossal mistake. If a one-time investment of $4,000 on each programmer makes them merely 5% more productive, you'll break even after the first year. Every year after that you've made a profit. Also, having programmers who believe that their employers actually give a damn about them is probably a good business strategy for companies that actually want to be around five or ten years from now.
...
Programmers have a tendency to get lost in the details of optimizing for the sake of optimization... If you're not extremely careful, you could end up spending a lot of very expensive development time with very little to show for it. Or, worse, you'll find yourself facing a slew of new, even more subtle bugs in your codebase.
Rules of Optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.
- M.A. Jackson
Given the rapid advance of Moore's Law, when does it make sense to throw hardware at a programming problem? As a general rule, I'd say almost always.
Incidentally, this is also why failing to outfit your (relatively) highly paid programmers with decent equipment as per the Programmer's Bill of Rights is such a colossal mistake. If a one-time investment of $4,000 on each programmer makes them merely 5% more productive, you'll break even after the first year. Every year after that you've made a profit. Also, having programmers who believe that their employers actually give a damn about them is probably a good business strategy for companies that actually want to be around five or ten years from now.
...
Programmers have a tendency to get lost in the details of optimizing for the sake of optimization... If you're not extremely careful, you could end up spending a lot of very expensive development time with very little to show for it. Or, worse, you'll find yourself facing a slew of new, even more subtle bugs in your codebase.
Rules of Optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.
- M.A. Jackson
Thought-provoking (and contrarian) advice from Mike Rowe
Article on Forbes.com
As a huge fan of Dirty Jobs, I think Mike Rowe's career advice is definitely something to ponder:
So why are people with dirty jobs having more fun than the rest of us?
The answer (aside from the fact that they're still employed) is because they are blissfully sheltered from the worst advice in the world. In particular, I'm thinking of a specific piece of nonsense that implores in earnest italics, to always, always ... Follow Your Passion!
If I've learned anything from this show, it's the folly of looking for a job that completely satisfies a "true purpose." In fact, the happiest people I've met over the last few years have not followed their passion at all--they have instead brought it with them.
These guys are passionate about what they do, but none of them aspired to the careers they now enjoy. None of them were guided by a burning desire to do a particular thing. What they did was step back from the crowd and watch carefully to see where everyone else was going. Then, they simply went the other way. They followed the available opportunities--not their passion--and built a balanced life around the willingness to do a job that nobody else wanted to.
As a huge fan of Dirty Jobs, I think Mike Rowe's career advice is definitely something to ponder:
So why are people with dirty jobs having more fun than the rest of us?
The answer (aside from the fact that they're still employed) is because they are blissfully sheltered from the worst advice in the world. In particular, I'm thinking of a specific piece of nonsense that implores in earnest italics, to always, always ... Follow Your Passion!
If I've learned anything from this show, it's the folly of looking for a job that completely satisfies a "true purpose." In fact, the happiest people I've met over the last few years have not followed their passion at all--they have instead brought it with them.
These guys are passionate about what they do, but none of them aspired to the careers they now enjoy. None of them were guided by a burning desire to do a particular thing. What they did was step back from the crowd and watch carefully to see where everyone else was going. Then, they simply went the other way. They followed the available opportunities--not their passion--and built a balanced life around the willingness to do a job that nobody else wanted to.
Tuesday, December 16, 2008
Defining Freelancers and Entrepreneurs
Post by Seth Godin on OpenForum
A freelancer is someone who gets paid for her work. She charges by the hour or perhaps by the project. Freelancers write, design, consult, advise, do taxes and hang wallpaper. Freelancing is the single easiest way to start a new business.
Entrepreneurs use money (preferably someone else's money) to build a business bigger than themselves. Entrepreneurs make money when they sleep. Entrepreneurs focus on growth and on scaling the systems that they build. The more, the better.
The goal of a freelancer is to have a steady job with no boss, to do great work, to gradually increase demand so that the hourly wage goes up and the quality of gigs goes up too.
The goal of the entrepreneur is to sell out for a lot of money, or to build a long-term profit machine that is steady, stable and not particularly risky to run.
The trap is simple: Sometime freelancers get entrepreneur envy and start hiring other freelancers to work for them. This doesn't scale. If you're an entrepreneur, it is impossible to succeed by using your own labor to fill the gaps. That's because your labor is finite. It doesn't scale. That's because if it's a job only you can do, you're not building a system, you're just hiring yourself (and probably not paying enough either).
The solution is easy. If you're a freelancer, freelance. Figure out how to do the best work in your field, the best work for the right clients. Don't fret about turning away work, and don't fret about
occasional down time. You're a freelance for hire, and you need to focus on your reputation and the flow of business. Find partners if you like but keep the cash flows separate.
If you're an entrepreneur, don't hire yourself. Build a business that works, that thrives with or without you. It might not be good for your ego, but it will be good for your bank account.
Whatever you do, don't mix em up.
Monday, December 15, 2008
Complexity is patentable, otherwise - rely on execution
Seth Godin's post on Selling Ideas to a Big Company
... the more complicated your idea is, the better off you are patenting it. Dean Kamen made his fortune patenting wheelchairs and other devices that you and I could never hope to build. On the other hand, if your idea is simple enough to dream up in a week, the only way you're going to protect it is to build it, fast and well.
... the more complicated your idea is, the better off you are patenting it. Dean Kamen made his fortune patenting wheelchairs and other devices that you and I could never hope to build. On the other hand, if your idea is simple enough to dream up in a week, the only way you're going to protect it is to build it, fast and well.
Friday, December 12, 2008
The economics of free
i.e. "How do you make money by giving away stuff?"
Mike Masnick of Techdirt
So, the simple bulletpoint version:
Infinite component: music (latest album given away for free)
Scarce component: seats at his concert tour
Another one: The String Cheese Incident (another music band)
Infinite component: music
Scarce component: concert tickets, time, flights, lodging, access to band
The music (the non-scarce good) helps them sell a lot more tickets to concerts (a scarce good). However, that band took it a step further. They set up their own travel agency to help fans attend their concerts -- and have been making money there, by saving people time (scarce good!) and helping them secure flights (scarce good) and lodging (scarce good), all in the pursuit of access to the band (scarce good) who they value so much because of the music (non-scarce good).
Mike Masnick of Techdirt
So, the simple bulletpoint version:
- Redefine the market based on the benefits
- Break the benefits down into scarce and infinite components.
- Set the infinite components free, syndicate them, make them easy to get -- all to increase the value of the scarce components
- Charge for the scarce components that are tied to infinite components
Infinite component: music (latest album given away for free)
Scarce component: seats at his concert tour
Another one: The String Cheese Incident (another music band)
Infinite component: music
Scarce component: concert tickets, time, flights, lodging, access to band
The music (the non-scarce good) helps them sell a lot more tickets to concerts (a scarce good). However, that band took it a step further. They set up their own travel agency to help fans attend their concerts -- and have been making money there, by saving people time (scarce good!) and helping them secure flights (scarce good) and lodging (scarce good), all in the pursuit of access to the band (scarce good) who they value so much because of the music (non-scarce good).
Wednesday, December 10, 2008
A simple goal to shoot for
Smart, and gets things done.
courtesy of Joel Spolsky* and now Marissa Mayer**
*The Guerilla Guide to Interviewing v3, 10/25/2006
**For personal reference, Marissa Mayer is Vice President of Search Product and User Experience at Google as of December 10, 2008.
My career goal is to leave each company being described in that way.
Another description of the ideal employee from Seth Godin's blog:
My favorite combination is the quiet confidence of knowledge, combined with the humility that comes from realizing that you're pretty lucky and that you have no idea at all what's guaranteed to work tomorrow.
courtesy of Joel Spolsky* and now Marissa Mayer**
*The Guerilla Guide to Interviewing v3, 10/25/2006
**For personal reference, Marissa Mayer is Vice President of Search Product and User Experience at Google as of December 10, 2008.
My career goal is to leave each company being described in that way.
Another description of the ideal employee from Seth Godin's blog:
My favorite combination is the quiet confidence of knowledge, combined with the humility that comes from realizing that you're pretty lucky and that you have no idea at all what's guaranteed to work tomorrow.
Monday, December 8, 2008
Genetic Algorithms and the Mona Lisa
Link to blog post by Roger Alsing
50 semi-transparent polygons, with vertex locations and color being determined by a genetic algorithm - evaluation function is a comparison to the actual Mona Lisa.
What's instructive here is the simplicity of the model: 4 parameters per polygon - 3 vertices and the color, for a total of 200 parameters. I'm guessing the evaluation consists of summing all the polygons and then doing some kind of image comparison - wonder how fast it runs?
The final result appears after close to a million iterations...but recognizable image occurs around 100,000 generations. Also, comments point out that the algorithm does not appear to be a standard "genetic" algorithm, but instead a stochastic hill-climbing algorithm.
Update:
FAQ by Roger Alsing
Source code
A Clojure version of the same approach
Another update:
A very detailed look at optimizing this image compression approach
50 semi-transparent polygons, with vertex locations and color being determined by a genetic algorithm - evaluation function is a comparison to the actual Mona Lisa.
What's instructive here is the simplicity of the model: 4 parameters per polygon - 3 vertices and the color, for a total of 200 parameters. I'm guessing the evaluation consists of summing all the polygons and then doing some kind of image comparison - wonder how fast it runs?
The final result appears after close to a million iterations...but recognizable image occurs around 100,000 generations. Also, comments point out that the algorithm does not appear to be a standard "genetic" algorithm, but instead a stochastic hill-climbing algorithm.
Update:
FAQ by Roger Alsing
Source code
A Clojure version of the same approach
Another update:
A very detailed look at optimizing this image compression approach
Saturday, December 6, 2008
Why corporations do things the way they do...
You build a nice big room-sized cage, and in one end of it you put five monkeys. In the other end you put the banana. Then you stand by with the fire hose. Sooner or later one of the monkeys is going to go after the banana, and when it does you turn on the fire hose and spray the other monkeys with it. Replace the banana if needed, then repeat the process. Monkeys are pretty smart, so they’ll figure this out pretty quickly: “If anybody goes for the banana, the rest of us get the hose.” Soon they’ll attack any member of their group who tries to go to the banana.
Once this happens, you take one monkey out of the cage and bring in a new one. The new monkey will come in, try to make friends, then probably go for the banana. And the other monkeys, knowing what this means, will attack him to stop you from using the hose on them. Eventually the new monkey will get the message, and will even start joining in on the attack if somebody else goes for the banana. Once this happens, take another of the original monkeys out of the cage and bring in another new monkey.
After repeating this a few times, there will come a moment when none of the monkeys in the cage have ever been sprayed by the fire hose; in fact, they’ll never even have seen the hose. But they’ll attack any monkey who goes to get the banana. If the monkeys could speak English, and if you could ask them why they attack anyone who goes for the banana, their answer would almost certainly be: “Well, I don’t really know, but that’s how we’ve always done things around here.”
"Corporations" could be replaced by any group with turnover and institutional history.
Unsourced story was used in this interesting post about Python 3.0
Once this happens, you take one monkey out of the cage and bring in a new one. The new monkey will come in, try to make friends, then probably go for the banana. And the other monkeys, knowing what this means, will attack him to stop you from using the hose on them. Eventually the new monkey will get the message, and will even start joining in on the attack if somebody else goes for the banana. Once this happens, take another of the original monkeys out of the cage and bring in another new monkey.
After repeating this a few times, there will come a moment when none of the monkeys in the cage have ever been sprayed by the fire hose; in fact, they’ll never even have seen the hose. But they’ll attack any monkey who goes to get the banana. If the monkeys could speak English, and if you could ask them why they attack anyone who goes for the banana, their answer would almost certainly be: “Well, I don’t really know, but that’s how we’ve always done things around here.”
"Corporations" could be replaced by any group with turnover and institutional history.
Unsourced story was used in this interesting post about Python 3.0
Monday, December 1, 2008
Subscribe to:
Posts (Atom)
