TechStars Completed

TechStars has been an amazing group to be a part of. We have frequently been asked about the program and “what is the best part of the TechStars program?” It is really hard to break it down to any single point, but all the benefits come back to being all about the people.

We have received a ton of help from everyone in the program. We want to thank all of the mentors and sponsors involved with the program. TechStars really brings an amazing group of people together. We of course want to thank the original founders of TechStars - you have helped to build a really unique and engaged tech community in Boulder.

We want to give mad props to all of the other TechStars 08 teams. Some of the best advice we got came from the other teams. So thanks goes out to Occipital, Gyminee, App-X, TravelFli, Ignighter, People’s Software Company, Foodzie, BuyPlayWin, and of course The Highway Girl.

We also got some great advice and feedback from some of last year’s teams. Thank you to Ari from Filtrbox, Rob and Josh from EventVue, and the entire team with Socialthing!.

Last, but not least, we wanted to give a final thanks to some of the mentors that we spent additional time with. We really appreciate the advice, feedback, and laughs… thanks to David Cohen, Tom Higley, and Seth Levine.

Congrats to everyone for making TechStars such an amazing ride. We know that even though the program is over we will still be getting advice from many of you and still be working with the kind of determination that TechStars helps foster.

Looking for your first CS job? Be sure to own your ideas

During my search for my first “real” computer science job during my senior year of college, I compared a lot of factors for various jobs including city, company, project, salary, and benefits. The salary stuff was fun to think about (especially after four years of being a poor college student) and I was looking to move to a bigger city somewhere outside of the Midwest (after growing up and going to college there). But mostly I thought about the company and project. Which companies would I want to work for? What project would interest me the most? Where would I learn the coolest stuff?

In hindsight, I realize I’d overlooked the single most important question - is this company going to own my ideas?

I never even thought to ask my prospective employers about their policies on IP and moonlighting. It wasn’t until I’d accepted an offer and received their legal documents that it dawned on me. And even then, I didn’t mind. I thought it was just standard practice and I really didn’t have much of choice*.

For those of you that don’t know, many large software companies technically own everything you think of while you’re working for them. No, not just the stuff that you do at work. They also own the stuff that you do at home, after hours. There is no clean separation of “work” and “personal” projects.

This manifests itself in a few ways. First of all, you may notice that the company explicitly bans working on open-source projects. Or they may require you get explicit permission for “moonlighting” i.e. working on non-work-related projects after hours.

At the very least, you should ask any potential employer about their IP policy before you accept a job. You may be able to get them to loosen their restrictions, especially if they really want you (I haven’t personally done this and I’m not sure if the bigger companies would go for it, but it’s worth a shot).

In fact, I’d argue that you should not accept any job that claims ownership over your outside-of-work ideas - even if that means compromising salary, benefits, project, company, or location. The benefits of owning your ideas are just too numerous and important.

Side projects make you a better programmer. I don’t care if you’re contributing to open-source projects, building a for-profit website, or just toying with a personal project in your own time, writing code that doesn’t relate to work will expand your skills and make you a better programmer at work.

Side projects help your career. Working on projects that anyone can examine are much more valuable than a good resume or recommendation.

As Paul Graham writes in Hackers and Painters:

It seems surprising to me that any employer would be reluctant to let hackers work on open-source projects. At Viaweb, we would have been reluctant to hire anyone who didn’t. When we interviewed programmers, the main thing we cared about was what kind of software they wrote in their spare time. You can’t do anything really well unless you love it, and if you love to hack you’ll inevitably be working on projects of your own.

Your side projects won’t just help you during your next active job search. They form a sort of passive job search in which you’re letting the outside world know how awesome you are. If a better offer comes along, great. Even if you’re happy where you are, you can use external offers as leverage with your current employer (and not just for salary, either. A higher profile outside the company may convince your boss to give you more responsibility at work, publish whitepapers, or attend more conferences).

You can start your own company. If you own your own ideas, then when that little site you built in a weekend starts getting a bajillion visitors a day - you’re free to pursue it. Hello, no boss/early retirement**.

Even if you quit and your startup fails, your career will probably be better off anyway. In Hiring is Obsolete, Paul Graham writes:

Even if your startup does tank, you won’t harm your prospects with employers. To make sure I asked some friends who work for big companies. I asked managers at Yahoo, Google, Amazon, Cisco and Microsoft how they’d feel about two candidates, both 24, with equal ability, one who’d tried to start a startup that tanked, and another who’d spent the two years since college working as a developer at a big company. Every one responded that they’d prefer the guy who’d tried to start his own company.

If you’re trying to rationalize taking that more restrictive job anyway (I mean, they’ve give you free soda at work!), you might be thinking:

“I don’t want to do a startup anyway.” Well, OK. But are you sure you’ll feel the same way in a year? In any case, working on side projects is good for your career, even if you never do a startup.

“No one will know.” Maybe you’re thinking that when you have that good idea for a startup, you’ll just keep it in your head until you quit. There’s a couple of problems with that.  First, you won’t really understand your idea until you start working on it. Secondly, some of the best startup ideas come from projects that didn’t initially have any commercial value (and therefore wouldn’t appear to be worth quitting to pursue)

“They won’t be able to enforce it.” You mileage may vary by state (I’m no lawyer, but I vaguely understand the California courts may be ruling against companies in these kinds of disputes), but it probably won’t matter anyway. Since you don’t want to spend time tied up in court, just the threat that your company could come after you will prevent you from working on most ideas. And even if you have a great idea and decide to go for it - do you really think future business partners and investors will want to hear that your old company might own the core IP of your company?

“My new employer lets me list the IP I own before I joined the company, so what’s the big deal?” The big deal is that you’re almost certainly going to think of new (and likely better) ideas during the time you’re employed at the company. Do you really think all your future ideas will fall into the narrow set of things you’ve thought of before you join? Doubtful.

If you feel you like have to take the job (or you’ve already done so), make sure to get permission in writing before starting to work on your new idea. But of course, just the hassle of getting permission is a strong disincentive to not work on your idea at all.

“All CS jobs are going to require me to sign away my IP” On the contrary, many jobs will let you keep your IP - especially if you are doing programming for a company that doesn’t consider delivering software to be it’s core business. Clearly some jobs let you do other stuff - or no one would be contributing to open source. For instance, Matt Mullenweg got to hack on WordPress while he was working on blogs and new media for CNET (in fact, working on WordPress was part of his job, which is extra cool but probably harder to accomplish).

In order to own your ideas, you may have to sacrifice other aspects of your job (not work at a “brand name” company, work on more mundane projects at work***, make less money), but I’d argue that it’s worth it, especially at the beginning of your career. It’s just too limiting to give away that much of your potential - because you never know where the next idea will take you.

*I ended up accepting the job at Microsoft. For the record, I really loved parts of the job (but also wish I could have worked on open source). I hear they have relaxed their policies since I left, which is definitely a good thing.

** For the record, I am not advocating taking ideas from work (the stuff you are being paid to work on) and starting a company based on that (or, for that matter, putting those ideas into open-source code). That’s illegal and immoral. I’m referring to the case where you’re working on X at work - but you want to keep your options open to do a startup that does Y.

*** Being less satisfied at work might actually be a good thing if you are interested in eventually doing a startup, since it will increase the chance that you’ll work on something really cool in your free time.

New Devver Blog Design

We finally have our new blog theme up! Thanks goes to Andrew Hyde for the amazing design and to Ryan Imel for the WordPress theme. We think the new theme helps complete our look, and provides a seamless transition from our Devver homepage. Let us know your thoughts.

Leaving NetBeans for Emacs as my Ruby Editor

When I first started working with Ruby I used RadRails (which still has the best integrated test runner I have used). Various problems and crashes with RadRails along with exciting features being added to Ruby NetBeans enticed me to switch. I enjoyed NetBeans and some of its features, but the weight of my IDE began slowing me down. I didn’t have the control to tell it not to do some things that annoyed me.

My cofounder Ben had been using Emacs since learning Ruby. The quick speed that he could work with code, made me wonder what features I was actually using in my bloated IDE. It turned out that I had been getting annoyed with most of the advanced features because they stalled my system, crashed occasionally, or really weren’t that useful. An example of a cool feature that I hardly found useful would be Netbean’s Ruby code completion. In the past I had used Emacs to develop all my C and C++ code and I always liked it, so I decided to switch away from NetBeans and see how Emacs would hold up as my editor.

I have enjoyed using Emacs and think that I can more quickly work with code with far less hassle and frustration. I don’t expect to move back to a large IDE anytime soon. That being said there are definitely pros and cons to working with a full IDE vs an editor, and I find myself missing features sometimes. So I thought I would list out some of the pros and cons so others can weigh these issues themselves.

Reasons I miss NetBeans:

  • Graphical test integration linking to the lines of code in the stack trace
  • Navigate -> ‘Go to Declaration’, ‘Go to Test’, ‘Go to Action or View’
  • Easy code refactoring and renaming
  • Code completion, occasionally (e.g. was the Array function called include? or includes?)
  • File browsing with folder tree view
  • Graphical SVN browsing, easy branch, merge, get version, diff
  • Easy project file search (Yes, you can do, ‘grep -Ri ‘Logger’ lib/* bin/* app/* | grep -v .svn’, but that is a pain to type)
  • Easy code commenting (Apple-/ which toggles, is much nicer than Ctrl-x, Ctrl-m comment-region / uncomment-region which has to be added to your Emacs configuration)
  • Easy code formatting (Apple-shift-f, is easier than Ctrl-x, Ctrl-m indent-buffer / indent-region)

Reasons I hate NetBeans:

  • Frequently stalls (Especially if you have been out of the application for awhile)
  • Crashes (At least every couple days)
  • Not enough user control (stop indexing everything)
  • Magic behind the scenes (constantly connecting to SVN every time I saved a file)
  • Debugger didn’t work well (ended up running on the command line to get debugging)
  • Ruby Console didn’t work well (ended up using irb on the command line instead)
  • All tasks that NetBeans handles nicely for you like testing or migrations were slower (ended up running all rake task and tests on the command line)
  • Resource hog, making everything else I am running far slower
  • NetBeans ignores canceling tasks and continues trying to run them
  • Booting up takes a few minute before NetBeans completes its various start-up tasks (You can work during some of the start-up tasks, but it is slow and unresponsive until it has completed the tasks)

Things I like about Emacs:

  • Better/more key commands (I love kill/yank - the ability to kill until the end of line is incredibly useful)
  • Incredibly fast, if I am working live with someone I can jump in make an edit and be back live showing them the change on the project (Imagine having to boot NetBeans to do this)
  • Multiple copy and paste buffers. This is something you get with GNU Emacs on an X system. I can use both kill/yank from Emacs while also using my normal copy and paste to maintain two independent copy and paste buffers, very handy
  • Complete control over the editor, no longer do I have to deal with auto closing brackets or any other ‘helpful’ defaults the editor includes (You can turn them all off, but I get annoyed having to go change a bunch of settings)
  • An unexplainable feeling of being closer to the system and the code.

Miško Hevery on Writing Testable Code

Miško Hevery has written up a nice collection of tips on writing testable code on his blog. Some of the tips are a bit hard to understand and apply, but it sounds like he will be going into many of them in more detail in the weeks to come (or you can use this list as a starting point and search for more details on individual tips).

While I don’t agree that there are no tricks to writing good tests, I whole-heartedly agree that a huge part of testing is making your application code testable. This is one of the biggest reasons that unit testing has a low ROI when you start (but that ROI increases as you learn to write testable code).

New site!

Thanks to talents of the one and only Andrew Hyde, devver.net now looks awesome. The text I supplied is far from perfect and we still need to integrate the blog, but it’s a huge improvement. Thanks Andrew - you rule.

Jason Fried (of 37signals) on building great companies and products

Last Thursday, we had the opportunity to hear a talk from Jason Fried, CEO of 37signals. I had already read some of the 37signals philosophy in Getting Real (although it’s about time for a re-read), but the talk was still totally fascinating. Although in many ways they are similar to the Web 2.0 startups (they emphasize releasing early, focusing on the customer, and avoid detailed long-term planning), in other ways they are totally different (notably, they don’t work an insane number of hours a week).

Jason repeatedly said that their process was not the only way to successfully run a company - just the way that works really well for them. While I don’t think every piece of advice will be useful for every startup, I’m betting that everyone can learn at least a few very useful things from Jason. I know it got my mind spinning about ways we could improve how we work at Devver.

Without further ado, here are some nuggets of wisdom from Jason, split roughly into two categories: Running a Company and Building a Product.

Running a Company

Focus on things that don’t change

  • first-mover advantage is overrated
  • the leaders today sat back, watched, and did it better
  • invest in the things that won’t change (example: in ten years, people will still like simple software, so focus on simplicity)
  • don’t try to chase the next big thing

Don’t plan

  • 37signals just wants to build a great products that people love
  • they don’t have a five year plan
  • they know they want to be profitable, but they don’t have a plan to get X users by Y date

Use ‘less’ to your advantage

  • use your constraints to focus your attention on the most important things you can possibly do instead of everything you can possibly do
  • less money is an advantage (you have to be creative to get the word out, which is more effective)
  • less time is an advantage (focus on important stuff)
  • fewer people is a good thing (less coordination necessary)

Work less

  • 37signals don’t work on Fridays
  • now Monday-Thursday people work extra hard, they waste less time
  • they don’t make them cram in more hours (around 8 hours a day, four days a week)
  • the output has been better, they are more refreshed
  • great for employee retention
  • they pay for employees to pursue hobbies outside of work
  • if they pay for hobbies, the person has to teach everyone else the stuff they are learning

Share knowledge

  • they don’t spend money on advertising
  • the most famous chefs are famous because they teach others
  • out-teach, out-share, out-contribute your competitors
  • don’t be afraid of competition stealing your ideas
  • if you teach, you have people’s mind even if you don’t have them as a customer
  • amass an audience, then you can sell them something

Avoid interruption

  • it’s the biggest enemy of productivity
  • look to minimize interruption
  • they don’t talk to each other
  • at 37signals, everyone usually works from home
  • there might be 4 months where they don’t see each other, but they collaborate passively via Campfire
  • there is no such thing as a rock star developer, only rock star environments (those that make developers productive)

Don’t hold meetings

  • no meetings at 37signals
  • they are a huge waste of time
  • they last too long
  • information per minute is really small
  • think about the total cost (10 people attending a one-hour meeting == 10 hours of lost productivity)

Be transparent

  • if you make a mistake, come out immediately, admit it, move on
  • don’t try to hide mistakes
  • be part of the conversation about you screwing up (because the conversation is happening anyway)
  • the more you admit you are wrong, the more people like you

Avoid these words: “Need”, “can’t” and “easy”

  • these are the words that cause things to be late, to be difficult, to be contentious
  • people use the word “easy’” to describe other people’s work (e.g. “That feature should be easy to implement, so let’s have it by tomorrow”)
  • you don’t need most things you say you “need”
  • “can’t” is also unnecessarily strong

Don’t scar on the first cut

  • don’t institute a policy every time one little thing go wrong
  • if problems arise, deal with problem on individual basis
  • treat people with respect, not rules
  • small companies should not try to be big companies (big companies are wishing they could be like small companies)
  • if employees know you trust them, they won’t abuse that trust
  • example: everyone at 37signals has a company credit card they can use for anything they want (not necessarily work related)

Don’t only hire on specific skills

  • curiosity is the most important trait. Curious people want to learn new things and appreciate other people’s work
  • if you want to know how curious someone is, just ask them the last (non-work related) thing they learned
  • always hire good writers, that’s more important than specific skills

Pick your clients carefully [this was targeted at service companies]

  • you can choose the work you do
  • find the right kind of clients
  • you don’t need every customer
  • you can’t make everyone happy
  • if you take on everything you can at first, you’ll never stop, and after 10 years all your projects will suck

Let customers pay right away

  • don’t pester users to get them to upgrade
  • most of their paying customers started w/ paid version (as opposed to using the free version for awhile and then upgrading)
  • ask people for money right away if you want it from them

Don’t worry about the competition

  • they will change
  • you can’t control them

Building a Product

Don’t plan

  • it’s vastly overrated
  • just build the thing
  • don’t let planning scare you into not doing something
  • spend 95% of the time on the real thing
  • you always know more about the project after you’ve started working on it

Eliminate abstractions

  • diagrams, wireframes, proposals aren’t real
  • just work w/ the real thing
  • fake things create an illusion of agreement (if you think you are all agreeing to the proposal, you aren’t. Everyone interprets it differently)
  • get rid of documents, artifacts - anything that you file in the cabinet after you complete them
  • don’t represent the thing you are building, just build it

Error on the side of simple

  • every mistake they have made is because they tried to do too much
  • do the simplest possible thing for any problem
  • get it out, let people try it out, then iterate
  • always do the easier/faster/simpler thing

Don’t focus on details early on

  • it’s a waste of time
  • the things that are done early will probably be redone anyway
  • polish is important, just do it later

Solve atomic problems/make tiny decisions

  • people try to solve problems that are too big
  • break down big problems down to the atomic level
  • you can easily solve small problems (and if you do it wrong, you can go fix it easily)
  • if you solve a big problem incorrectly, you won’t go back to fix it, because you invested so much in it
  • 37signals doesn’t work on anything more than a week
  • they often just solve a quarter of a bug
  • morale is killed by people working on big problems that never get solved

Give up on hard problems

  • they aren’t worth solving
  • let your competition solve hard problems
  • there are so many easy problems that need really good solutions
  • take a step back, figure out what the core problem is
  • take a few days off, look at it again, there may be a simple problem instead

Say “No” much more than “Yes”

  • say no to everything (to customers requests, to features you yourself want)
  • you think you need to give everyone everything they want, but you don’t
  • make a feature/request really fight to be in the product
  • as a product designer, you are the curator, you are the editor, you have to say no
  • once you start hiding stuff in your product, it’s too complicated (if users have to turn stuff off, that’s a bad sign)
  • it’s really hard to take away features from people (even if they are bad)

Be careful when adding features

  • they read every feature request, then throw them away
  • they used to keep a huge list, but no one looked at it because it was too long
  • now they just notice the stuff that gets asked over and over
  • look out for the “bananas in the lasagna” (even if everyone asks for something, if it doesn’t fit w/ the product, don’t add it)
  • think very deeply about requests, even simple features have a lot of implications
  • customers talk in solutions, you need to look for problems and solve those
  • improve things for the majority, not the vocal minority (vocal minority can destroy a product)

Eliminate product management

  • if you have a product manager, the product is too big and complicated
  • the builders should be able to manage the product

Useful Gem Shortcuts Tip

When you are working with projects in the command line all day, it can be really annoying to have to remember the exact location of everything. Often when programming against a gem in Ruby, it can be really useful to read over the documentation. Adding a couple lines to your .bash_profile can make loading up the documentation files for your gems much easier. Thanks to Stephen Celis for sharing this great tip.

Friday fun: What the hell is up with ABC News photos?

ABC News is a respectable news organization, right? I thought so too. That’s why I’m mystified by the abundance of shockingly bad Photoshopped pictures on their website.

It’s been my hobby to collect these visual Frankensteins for the past few months. They range from simply poor in quality:

to tacky:

to just plain strange:

There are also not particularly subtle. If they have a story about money or the economy, they either frame an image with money:


or, better yet, just put a handful of Benjamins in front of said image.

I swear to you that all of these were taken directly from ABCs website. In fact, there was a gem featuring Obama and Hillary in clearly-Photoshopped cowboy hats (I believe it was for the Texas primary), but sadly, I cannot find it.

In fact, I’m not even sure Photoshop was involved. Given the images I’ve seen, it appears ABC executive gave a poor intern a set of safety scissors, a vat of Elmer’s glue, and an old flatbed scanner and let them go to town.

Finally, there are images that are so weird that I defy you to guess the story they accompanied.

Maybe I can get Flux Capacity to combine a bunch of images from abcnew.go.com together to give us all a terrifying vision of the ‘Alice in Wonderland’/Soundgarden-video world that ABC News lives in.

Learning RSpec and Merb

We have been trying to work with some different Ruby technologies lately. We are moving to RSpec from Test::Unit, because we believe it has several advantages. It also seems all the cool projects are moving to RSpec: Rubinius, Typo, Mephisto, and of course Merb.

In learning these two technologies together, I have found a few resources that I found to be really useful. I thought it would be good to share the information for anyone looking to write specs for their Merb projects.

If you are first learning Merb and want to create a basic project and learn to test with Rspec along with development, I can’t recommend enough that you follow the Merb Slapp tutorial. This is a great source for Merb basics that is very up to date, and gives good examples of RSpec tests.

If you are new to Merb, the newest documentation will be your friend. I also recommend checking out the Merb Wiki. For RSpec, specifically check out these wiki pages: Merb Controller Specs, Merb Model Specs, and Merb View Specs.

There were some things I had to search and stumble around a bit for, session variables and mock objects. The reason I needed to mock the session was that a user is expected to be logged in verified by a session variable before allowing the action to continue. I needed a mock object of my ProjectWriter, because it normally makes live calls to a web service. These are easy to do, but are both done differently than with Test::Unit with Rails. I found out about RSpec mocking and Merb session mocking at the links provided.

Here is some code that demonstrates mocking both sessions and model objects.

#create a mock object named ProjectWriter
project_writer = mock("ProjectWriter")
#mock expects this call
project_writer.should_receive(:get_all_user_projects).with('ben')
@controller = dispatch_to(Project, :index) do |controller|
  #mock the session hash
  controller.stub!(:session).and_return({:logged_in => true})
  #return my mocked object
  controller.stub!(:get_project_writer).and_return(project_writer)
  #we aren't testing the view don't render it
  controller.stub!(:render) # don't render this action
end

@controller.should respond_successfully