giant robots smashing into other giant robots
Written by thoughtbot
Episode 43: A good person by default
thoughtbot’s Ben Orenstein is joined by Scott Orn, venture capitalist at Lighthouse Capital Partners by day, and co-founder of Ben’s Friends by night. Ben and Scott discuss building a community, the future of Ben’s Friends, and how running the site helps him be a better VC, teaching people, and getting value out of giving back. They also talk about his work as a venture capitalist at Lighthouse, how the money flows, the freemium software model, why it’s good and how it works, picking the winners, and how the market can affect success, and the companies Scott thinks are great investments, and where he thinks the market is going.
Episode 42: Why were you suing a website?
This week, Ben Orenstein is joined by Peter Moldave, attorney at Gesmer Updegrove to discuss attorney client privilege, what not to do with email, the similarities between lawyers and programmers, how he got into law, his history with technology, and his time as a corporate lawyer at Apple. They also dig into how EULAs work, whether they are binding, whether you should be reading them, and how they can be enforced, software licensing, copyrights and the First-sale doctrine, patent law, software patents, and navigating the patent landscape. They also discuss how to view stock options in your startup job offer, working at startups, how to have a valuable career path, what your employer owns from your side projects or your work for them, how to manage liability in your startup, web site, app on the App Store, and side projects, the best corporate structure and much, much more.
Episode #32: There is an excited you in there
Ben Orenstein is joined this week by Daniel Jalkut, the developer of MarsEdit and other fine software. Ben and Daniel discuss the origin of Daniel’s twitter username, his history at Apple and his work there, and how it influences what he builds today. They also discuss the challenges of running your own company, and how Daniel’s priorities and rule systems help him get things done, how the success of MarsEdit takes up his attention at the exclusion of other ideas, and how he thinks about failure. Then then go on to talk about App Store versus direct sales, why Daniel still sells his software outside the app store as well as in it, and what the breakdown of sales are like there, as well as Daniel’s thoughts on App Store pricing and the benefits of being in the app store. Finally, Daniel tells us why he thinks git is like a PC and Mercurial is like a Mac, why he dislikes git, what he thinks makes a good podcast, how his podcast has changed, and much more.
Business problems and technology people
When you have a hammer, everything looks like a nail. I’m sure this pattern emerges in other industries, but here are some strawman personalities of web/tech types of people, and how they respond to business problems…
- The Value Personality — This person can stop themself and ask about what sort of problem they have. They’re not rushing to a solution. They want to understand the problem and determine if it’s worth solving, and how to most efficiently solve it if it does. They’d rather buy something than build something, if buying is cheap and building requires continuing to own and operate a service after the fact.
- The Mixed Bag — These people have the ability to answer the question “is this a technology problem?”… but they don’t always use it. They’re giddy to solve the problem and use the skills they have, so they jump head-first into creating a solution. They can be steered into agreement in discussion by being forced to confront “value” as a worthwhile component of the decision making process.
- The Builder — This person has trouble contemplating a world where the answer to any question doesn’t involve them building software. They’re not clear why they would even be involved in a conversation which comes to another conclusion. The logic is something like “I am programmer; hence any discussion about a problem should lead to me writing code”.
Practical examples of problems, think about how each role might react to each:
- We want to launch a company blog
- We want to host events and need a registration system
- We want to serve ads on our website
- We want to monitor google for mentions of certain keywords
There are “build” and “buy” solutions for all of these, and I think the psychology and personality types of our strawmen will strongly dictate which direction they want to go.
So who’s “better”?…it depends. This may not be true in large organizations or very top-heavy organizations, but in the context of a small self-directed team, I think you want to make sure you’ve got the first personality type as your owners/operators and managers, and try to get as many of the first and second type as you can for your employees. Unless you have a large team with a lot of management and oversight, be careful about the third type.
That being said, there certainly is a time and place to write software! The key here is to realize that just because you happen to be capable of using technology and software to solve problems, or because you happen to be in the technology service business, does not mean that you must build new technology to solve every problem you encounter.
Ruby’s pessimistic operator
Do you know Ruby’s pessimistic operator? It looks like this:
~>
You’ve seen it in some Gemfiles. Here’s an example
gem 'rails', '~> 3.0.3'
gem 'thin', '~> 1.1'
~> 3.0.3 means that when you bundle install, you’ll get the highest-released gem version of rails between the range >= 3.0.3 and < 3.1.
~> 1.1 means that when you bundle install, you’ll get the highest-released gem version of thin between the range >= 1.1 and < 2.0.
Using the pessimistic operator in combination with consistent Semantic versioning by gem authors, we can theoretically achieve better stability in our dependencies.
Read more on the tradeoffs or read our current guidelines on Bundler.
Written by Dan Croak.
