2,493 karma · joined April 2, 2008
Co-founder of Mux. Previously, co-founder of Zencoder. YC W16 and W10. SF.
While I agree with his point on structured procrastination - sometimes the most inspired work is done while avoiding something else - it's also important to balance that with focus. I find my focused procrastination valuable and my scattered procrastination frustrating. Procrastination is rarely productive when it means bouncing between four things (reading HN, hacking on a library, writing a blog post, and buying a book at Amazon).
Procrastinate in serial, not parallel.
Amen. That could be hugely powerful.
Boilerplate code? Two great programmers are a waste.
Moderate difficulty? Maybe less efficient than working separately, but they'll still work a bit faster, produce fewer defects, transfer knowledge well, etc.
Really complex problem? Not a waste at all.
See http://www.loper-os.org/?p=42 for more.
The author is a smart guy. Major contributor to Sinatra, developer at Heroku, etc.
You might be right about the rubygems issue, but the random bile and personal attacks make it hard to take you seriously.
Me too. I generally lean right on economic issues, but as a small business employer, I wish we had a system like Canada or most of Europe.
What about getting through the back door via consulting? I know some people who have taken this route, and it seems to work at least some of the time. Basically, you sell a license to your software wrapped in consulting time (setup, customization, support). This has potential, at least, to be a leaner sales process.
In both cases, the author is right on. Focus on installation, documentation, support, and usability. Each of these things can make paid software less expensive than free software, assuming that [paid cost] < ([free setup hours] - [paid setup hours]) * [hourly rate].
And more importantly, maybe, businesses will pay a premium for decreased risk. If they think your paid software with good support/installation/usability/documentation is less risky than another tool, you've got a shot.
The latter places heavy restrictions on certain ways to commercialize software, e.g. selling it without making the source freely available.
Of course, cutting corners isn't the only kind of code debt, and the author makes some good points. If you're spiking something or prototyping it, and intend to rewrite or throw away, technical debt might be a good tradeoff.
I also take issue with this:
Early on at IMVU, we incorporated in tons of open source projects. This was a huge win... The downside was that we had to combine dozens of projects whose internal architectures, coding styles, and general quality varied widely. It took us a long time to pay off all the debt that incurred – but it was worth it.
The more you can offload to open source libraries or third party APIs, the less your application has to do, and the less you have to maintain. If the library or API sucks, then sure - you're incurring technical debt. But if the library/API is good, or you can contribute to make it good, then it's a win all around.
1. Does the app assume that users want to spend about the same amount every day? I'll sometimes spend $0 one day and $1000+ the next day (e.g. mortgage payment). I'm entirely interested in keeping my monthly spending within a limit, but not my daily or weekly spending.
2. I've never taken to Mint or Quickbooks. My finances are pretty complicated, thanks to several income streams and companies, and tools like Mint/Qb assume that you care about ALL of your income and expenses equally. But all I care about is my overall monthly spending (am I going into debt?), and my spending within categories (how much did I blow on eating out this month?).
Have you thought about adding optional categories/tags? So if you want to keep your "beer" spending to, say, $750/month, you can track how much you have left to spend on beer, alongside your tally of total spending? Email/text in "12.55 +beer" and it gets tagged with beer.
The more I think about this, the more I like it. And I love that it's open-sourced. Watch for a fork. ;)
If it is a mere opinion, it would not constitute libel. For something to be libelous, it must be an assertion of fact - it must also be false and tend to injure the reputation of the party within the community.
Isn't every opinion an assertion of fact? If I say "American cars suck" or "Apple mistreats its developer community", I'm expressing what I believe to be the truth, not just my opinion.
What's the distinction between opinions and assertions of fact?
And if so (uninformed legal commentary here), is it illegal to express negative opinions in writing? "My landlord doesn't care that my apartment is moldy" seems pretty tame and commonplace.
A place for everything. Ruby's weak threading is a shame, but doesn't keep Ruby/Rails from being an exceptionally productive way to build and deploy small/medium web applications, and to bootstrap large web applications.
Don't call Ruby "bad" because it's worse than Scala at Scala's strongest points.
you had better get serious about staking out your turf on the jvm
Also, isn't that the whole point of this article? A lot of Rubyists are doing this right now.
My solution after experiencing something like this was to turn to consulting. Which, as pg says, is a blessing and a curse - it removes the distraction of the shortening runway, but it adds the distraction of getting paid good money for something other than your startup.