6 ms·

What's A Non-Programmer To Do? (How I keep myself busy.)

154 points by spencerfry 17y ago

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. Original comment thread: http://news.ycombinator.com/item?id=779378

JohnIdol 17y ago
learn to code? :) --> http://www.cplusplus.com/doc/tutorial/ http://www.cplusplus.com/doc/tutorial/
- eru 17y ago
  Yes. Though I'd recommend another _first_ language. C is a fine second or third language.
  - Brushfire 17y ago
    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 17y ago
      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 http://www.pythonchallenge.com or http://rubyquiz.com/ http://rubyquiz.com/
  - JohnIdol 17y ago
    C was my 1st and it worked out fine - curious to know which language you'd recommend.
    - eru 17y ago
      Yes, C can work fine. I learned C64 Basic, QuickBasic, C, Pascal, some Prolog and Lisp, Forth, Redcode (assembly), more Scheme, C++, and Python, Java. (And later Clean and Haskell.) I would not call this an optimal sequence. And it heavily overlapped. E.g. I only really got Scheme after playing around with Python a bit. And for some strange reason, I saw the light of higher order functional programming only when I began with Clean. In Scheme it felt too clumsy. But what's `optimal' depends on what your goals are. If you happen to be in that part of the population that just can not not program, then you will eventually learn how to do it. Even if somebody locked you up in a dimly lit closed with just a reference manual. Just the amount of fun you will have, and projects you accomplish will vary. I learn programming languages for fun. Python has a very nice library called PyGame that let's you produce some interactive graphics and sound (i.e. a game) quite fast. It's nicely documented. And in PLT Scheme images are first class objects, you can even embed them in your source code. I looked into Squeak, a smalltalk implementation, once, but it did not click for me. If I had to start again on the same hardware, I'd spend less time with C64 Basic and tried to get Forth for the C64 or do some assembly there. On modern hardware I'd take Python as the first conventional language, and Haskell or Clean as the first real language. (I am not sure whether I should start with a conventional language.)
- scott_s 17y ago
  No. This guy is making it possible for the developers to code and design. If he started doing their work, they'd have to start doing some of his work.
  - JohnIdol 17y ago
    just joking :)
spencerfry 17y ago
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 http://news.ycombinator.com/item?id=779378
- eru 17y ago
  Thanks!
- mpotter 17y ago
  Great mix of more general advice (like the previous set of bullet points), combined with specific context around your experience. It's a nice change of pace from the "your startup has to do this" blend of articles because it acknowledges your biases with the appropriate context. Thanks for sharing!
- falsestprophet 17y ago
  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.
rebelvc 17y ago
Market Market Market...Sell Sell Sell. Even, if your product is not ready yet, start building relationship with your customers and other helpful people.
alabut 17y ago
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 17y ago
  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 17y ago
    "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.html http://www.oreillynet.com/pub/a/oreilly/tim/articles/straw.h... 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.
gsaines 17y ago
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 17y ago
  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-and-new-office http://www.carbonmade.com/blog/2009/09/24/150000-portfolios-...). 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.

154 points by spencerfry 17y ago

JohnIdol 17y ago

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

eru 17y ago
Yes. Though I'd recommend another _first_ language. C is a fine second or third language.
- Brushfire 17y ago
  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 17y ago
    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 http://www.pythonchallenge.com or http://rubyquiz.com/ http://rubyquiz.com/
- JohnIdol 17y ago
  C was my 1st and it worked out fine - curious to know which language you'd recommend.
  - eru 17y ago
    Yes, C can work fine. I learned C64 Basic, QuickBasic, C, Pascal, some Prolog and Lisp, Forth, Redcode (assembly), more Scheme, C++, and Python, Java. (And later Clean and Haskell.) I would not call this an optimal sequence. And it heavily overlapped. E.g. I only really got Scheme after playing around with Python a bit. And for some strange reason, I saw the light of higher order functional programming only when I began with Clean. In Scheme it felt too clumsy. But what's `optimal' depends on what your goals are. If you happen to be in that part of the population that just can not not program, then you will eventually learn how to do it. Even if somebody locked you up in a dimly lit closed with just a reference manual. Just the amount of fun you will have, and projects you accomplish will vary. I learn programming languages for fun. Python has a very nice library called PyGame that let's you produce some interactive graphics and sound (i.e. a game) quite fast. It's nicely documented. And in PLT Scheme images are first class objects, you can even embed them in your source code. I looked into Squeak, a smalltalk implementation, once, but it did not click for me. If I had to start again on the same hardware, I'd spend less time with C64 Basic and tried to get Forth for the C64 or do some assembly there. On modern hardware I'd take Python as the first conventional language, and Haskell or Clean as the first real language. (I am not sure whether I should start with a conventional language.)
scott_s 17y ago
No. This guy is making it possible for the developers to code and design. If he started doing their work, they'd have to start doing some of his work.
- JohnIdol 17y ago
  just joking :)

spencerfry 17y ago

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 http://news.ycombinator.com/item?id=779378

eru 17y ago
Thanks!
mpotter 17y ago
Great mix of more general advice (like the previous set of bullet points), combined with specific context around your experience. It's a nice change of pace from the "your startup has to do this" blend of articles because it acknowledges your biases with the appropriate context. Thanks for sharing!
falsestprophet 17y ago
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.

rebelvc 17y ago

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

alabut 17y ago

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 17y ago
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 17y ago
  "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.html http://www.oreillynet.com/pub/a/oreilly/tim/articles/straw.h... 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.

gsaines 17y ago

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 17y ago
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-and-new-office http://www.carbonmade.com/blog/2009/09/24/150000-portfolios-...). 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.