

What's A Non-Programmer To Do? (How I keep myself busy.) - spencerfry
http://spencerfry.com/whats-a-non-programmer-to-do
I wrote a comment for Hacker News back in August in response to a guy's question about what a non-programmer should do in a startup. My response received 164 up votes and is the tenth most popular comment of all time. In this article I add some depth to most of my previous twenty bullet points.<p>Original comment thread: http://news.ycombinator.com/item?id=779378
======
gsaines
I'm actually the guy that started the thread, and I really appreciated your
well-thought-out response. Since putting that up, things have picked up
tenfold for me, I had been doing a lot of the things you mentioned, but our
customer base was small, and all the little stuff really hadn't reached a
level where it was challenging to organize. Boy did it change, and I'm really
happy for it. These days I'm finding myself getting buried in an ever-
deepening list of must-do items. It's sometime stressful, but then I think
about having too little work and smile, so it all works out. A couple of
specific comments about your post:

1) You said that the business guy should keep his eye on the macro focus. I
find myself doing this to a point of fault. One of my cofounders works in the
same room as I do and one day he just had to say: "Look, I can't work with you
talking about the future all the time, we need to keep our heads down and
develop at this exact moment." I'm curious: do you guys have physically
separate work spaces or are you just better able to control your forward
looking urge than I am?

2) Customer service: I've taken over most of this, and it's been great. I love
interacting with customers (even if I get some requests about a hundred
times), and as we grow, I'm ecstatic to report it's eating up larger and
larger chunks of my day. Eventually I'll have to figure out a way to continue
producing new content (I double as the designer, but I traded that workload
with our third guy for the book keeping), but for now it's great. I was
curious, we have a one day policy so that people always get a response in a
day, oftentimes it's much faster, but sometimes we'll be focused on designing
a new feature together, it slips. People have told us they don't mind getting
a response one or two days after, do you think it's worth investing high
energy in making sure it's super fast?

3) We've been having troubles with our user's guide and we're thinking about
pulling it altogether in favor of a more dynamic feature-specific overlay
system. We're keeping the FAQ though. Do your customers appreciate a user's
guide because it's a collected resource, or do you think it would work as an
enhanced tooltip system? This is just personal style, but I was curious.

Again, I really appreciated your comment back when I posted, and this blog
post is great. Thanks for helping me out.

~~~
spencerfry
I'm stoked that I was able to help you. That makes writing this article
completely worthwhile.

1\. Dave (designer) works in our NYC across office right across from me
([http://www.carbonmade.com/blog/2009/09/24/150000-portfolios-...](http://www.carbonmade.com/blog/2009/09/24/150000-portfolios-
and-new-office)). Jason (programmer) works back in Chicago and is moving to
NYC in May or sooner. What I find works best is to plan for the future, but
not to necessarily bring it up with the other folks until it's time. I
actually find myself saying "let's focus on the present" a lot more than I
find myself sharing my thoughts for the future. Sharing those thoughts are
best left for when you've completed a new version or a major segment of your
product. Keep everyone focused on the task at hand and bring out your plans
for the future only at the appropriate times.

2\. Someone mentioned in a response to one of my posts (and I'm paraphrasing)
that "a response to a support ticket takes the same time today as it does
tomorrow, so you might as well answer it today." I think that's very true. You
shouldn't let it derail you if you're deep in concentration, but if you see it
and you can take a minute to respond, why not respond then and there? By
responding it won't weigh on you for the rest of the day and affect your other
work.

3\. What troubles have you been having? I think the decision of having a user
guide or not should be based on whether your product needs one or not.
Luckily, ours is simple enough that a few FAQs do all the work for us.

Let me know if you have any other questions here or via email [at] spencerfry
[dot] com. I'm also open to having lunch/coffee/beer with you if you're in NYC
at any time.

------
spencerfry
I wrote a comment for Hacker News back in August in response to a guy's
question about what a non-programmer should do in a startup. My response
received 164 up votes and is the tenth most popular comment of all time. In
this article I add some depth to most of my previous twenty bullet points.

Here's the original thread: <http://news.ycombinator.com/item?id=779378>

~~~
falsestprophet

      2. Doing all the business related tasks.
      3. Doing all the customer service.
      4. Handling all incoming e-mail.
      5. Doing all of the social networking stuff (facebook, twitter).
      8. Tracking all of our expenses, etc., into Excel and getting everything ready for accountant (see 7).
      13. Handling payroll. I do that.
      14. Dealing with the bank accounts. I deal directly with the small business rep at our bank.
      16. Handling all incoming advertising requests, setting up their campaigns, etc.
      17. Dealing directly with all our merchants (credit cards + PayPal). Dealing with the very few chargebacks we receive.
      18. Paying all of our bills (server expenses, software licenses, domains, advertising, etc.) and monitoring our cash flow.
      20. Anything that requires a phone call. Incoming or outgoing.
    

Frankly, this sounds like work for an administrative assistant more than an
equal equity partner.

    
    
      1. Writing the copy for the website. Mainly keeping the support documents up-to-date.
      6. Doing all of our marketing. Handling Google AdWords, banner advertising, text advertising, etc.
      7. Dealing exclusively with our accountant
      9. Handling all legal work with our lawyer.
      11. We all come up with ideas for product development.
      10. Doing all of our networking. I'm the guy that goes to all of our relevant events.
      12. Blogging. I do all the blogging.
      15. Market research. I find out as much as I can about our competitors, what they do, etc. I also learn about our market as a whole.
      19. Pitching. I handle all of that.
    

There is no reason a technical founder wouldn't be able to do these things and
continue to work on the product.

~~~
christonog
Hm, I think it's all a matter of cost/benefit. What value would hiring an
administrative assistant bring compared to just having an equity founder with
more of an incentive? At least the founder can abstract everything business
related away, so all you need to do is code. And, to me, that's hard enough as
it is.

~~~
eru
More incentives and the communication barrier may be lower.

~~~
joeythibault
Plus I would never outsource copywriting. Good way to end up with a FAIL.

------
alabut
One thing I'm curious about - I don't see user research on the list, the
closest ones to it are the customer support and maybe the market research as
well. Does your designer cofounder run usability tests? Or do you all take the
37signals approach and rely more on a combination of your gut instincts and
customer feedback?

Just to disclaim my bias: as a designer, I've slowly dropped the more esoteric
UX/interaction tools like card sorting or mental models over the last 2-3
years as I've focused more on startups but usability testing is the one most
resistant to being dropped and I still see it as pretty much the gold standard
of design feedback.

~~~
spencerfry
Dave took the gut instincts approach for the current version because he built
Carbonmade for himself originally rather than for anyone else. The new release
that we're working on is a combination of gut instincts and user feedback.
Your users don't always know what's best, so you can't base new features or
approaches on user feedback alone.

I think we'll get more heavily into some A/B testing, but really only on
select pages. For example, I want to set up A/B testing for our new sign up
page. Right now you can't upgrade immediately when first signing up. You
instead need to sign up for a regular Meh account and then upgrade to Whoo!
later. I want to test allowing people to upgrade immediately when they first
sign up and see how that goes.

~~~
alabut
" _because he built Carbonmade for himself originally rather than for anyone
else_ "

That works pretty well for a v1, Tim O'Reilly had the colorful phrase "fishing
with strawberries" to explain why it works so well:

[http://www.oreillynet.com/pub/a/oreilly/tim/articles/straw.h...](http://www.oreillynet.com/pub/a/oreilly/tim/articles/straw.html)

I'm down with user feedback and a/b tests, I guess I was asking specifically
about usability testing though since I don't see it talked about much around
here. It's categorically different from the other stuff and yields much more
qualitative insights (why did they just do that?) versus the more quantitative
results (which page layout has a higher conversion rate?). Plus it's actually
a hell of a lot of fun to do! If done right.

~~~
spencerfry
Wow! Brilliant article. Love it.

"On one level, the difference between the two points of view is simply the
difference between selling one on one to a very targetted prospect and selling
to a mass market, where you are casting a wide net, and some set of potential
customers will match your own "strawberry" profile."

------
rebelvc
Market Market Market...Sell Sell Sell. Even, if your product is not ready yet,
start building relationship with your customers and other helpful people.

------
JohnIdol
learn to code? :) --> <http://www.cplusplus.com/doc/tutorial/>

~~~
eru
Yes. Though I'd recommend another _first_ language. C is a fine second or
third language.

~~~
Brushfire
What language would you (or others) recommend?

I'm just curious, as I'm doing Ruby (for the obvious RoR), but python also
seems smart.

Or would recommend people start more basic, like with Scheme or something?
Scheme was my true first language in school way back when, but I think others
could benefit from a comment that dealt with some advise on recommendations
about languages that I'm not qualified to give.

~~~
weaksauce
Python is a nice language because of the everything and the kitchen sink
approach to the built-in libraries. It also has a clean look because of the
significant whitespace. Ruby is another nice language. It seems to be a bit
more esoteric as far as some of the more advanced language features but for
the beginner the language lets you accomplish it in more than one way. C is a
fine language too but you will spend your time working on memory protection
instead of getting things accomplished fast. It is more useful on memory
constrained systems.

Every language is useful in a different way and each have a domain or two in
which they excel at.

The real takeaway is that the shift from knowing one language to another is
fairly easy. The real trick is knowing the idioms of the particular language
and how to use them.

<http://www.pythonchallenge.com> or <http://rubyquiz.com/>

