Ten Things I’ve Learned in a Start-Up

Ten things I’ve learned as a developer at WooMe:

  1. Be clear what your dir­ec­tion is. Identify your key pro­pos­i­tion and focus on it. Don’t get dis­trac­ted by unre­lated fea­tures — some­body else is prob­ably already doing those bet­ter than you.
  2. Be mer­ci­less with fea­tures that don’t cut it. No mat­ter how much you like it, if your audi­ence doesn’t like it, either change it or kill it fast. Wasting time on your per­sonal pet pro­ject when there’s no clear demand for it is time you should be spend­ing on fea­tures users want.
  3. Use what’s already there rather than invent­ing your own. Need a mes­sage queue? Video pro­cessing? Load bal­an­cer? Email dis­tri­bu­tion? Payment sys­tem? Use some­thing that already exists rather than waste time you should be spend­ing on fea­ture development.
  4. Quick and dirty is bet­ter than late to mar­ket. At the rate this industry moves, cap­tur­ing your audience’s atten­tion first is more import­ant than hav­ing a well-engineered solu­tion. For the most part, users don’t care about your code qual­ity, as long as it works.
  5. Don’t optim­ise until you need to. Sure, you may end up chas­ing your tail for a bit when you need to scale, but until you hit that point you’re wast­ing valu­able time that should be spent on fea­ture development.
  6. Scaling is most often a data prob­lem. When you do need to optim­ise, scal­ing won’t be about the per­form­ance of your applic­a­tion. Scaling web applic­a­tions hori­zont­ally is easy. Scaling data­bases ver­tic­ally is expens­ive. Scaling data­bases hori­zont­ally is very, very hard. Don’t worry about what web applic­a­tion frame­work you use, worry about what data­base you put behind it.
  7. Abstraction is great, as long as you under­stand what you’re abstract­ing. This has been a con­stant pain with Django’s ORM. Yes, it’s a power­ful and use­ful abstrac­tion, but without a solid under­stand­ing of what the data­base is doing behind it, it’s easy to get into very deep trouble, very quickly.
  8. Log everything. Nothing is harder than try­ing to find prob­lems on a live envir­on­ment without detailed logging.
  9. Storage is cheap. It’s bet­ter to store everything than to throw away data. You never know when you might need something.
  10. Communication is crit­ical. Not just out­side your organ­isa­tion, but within it. Tell people what you’re doing, fre­quently. Ask them what they’re doing just as often. Not only do ideas per­col­ate through this pro­cess much more effect­ively, but when things go wrong, clear and fre­quent com­mu­nic­a­tion will stop them from get­ting worse.

One Comment

  • My favor­ite “don’t optim­ize until you need to”, actu­ally the oppos­ite of “build it and they will come” which I think is a load of bull­shit that is applic­able to a small per­cent of real life situ­ations. More like, when they come then make it better.

    thanks Seb!

Post a Comment

Your email is never shared. Required fields are marked *