10 Tips for Moving From Programmer to Entrepreneur(zz)

http://www.userscape.com/blog/index.php/site/10_ti...

Many of the people over at BarCamp are working on/struggling with the transition from programmer to entrepreneur. While I was never a truly “hard core” programmer (meaning lock me in the basement with Mountain Dew for a week and I’ll come out with 100,000 lines of code) I did have to make this transition. Also, doing the entrepreneur thing for the last few years with HelpSpot has really given me some insights into why many people fail at this transition. So here’s a few observations:

Code is 5% of your business
One of the biggest issues I see is developers getting caught up in the code. Spending countless hours making a function perfect or building features which show off the latest technology. Now you have to write code to be in the software business. It has to be high quality code that isn’t filled with bugs or is insecure. However, the best code in the world is meaningless if nobody knows about your product. Code is meaningless if the IRS comes and throws you in jail because you didn’t do your taxes. Code is meaningless if you get sued because you didn’t bother having a software license created by a lawyer.

I see way too many entrepreneurs in the forums and blogs talking about code issues when they should be discussing and learning about the business aspects. Of course that’s harder then talking about code, but nobody ever said this would be easy!

Design is everything, relative to the competition
Your product has to be nicely designed. Standard programmer square boxes with gray backgrounds don’t cut it! Remember though that your design only needs to be nicer than the competition. So if you’re building a back office IT system there’s no need to bring your design all the way up to the level of a 37 Signals type app. Of course it’s great if you do, but the goal here is simply to make it clear for your customers that you have the nicer design when they compare your product to the competition. People DO judge books by their covers.

Get used to thinking long term
There’s nothing a programmer likes better than turning code around fast. Getting bugs in and squashing them. The problem is that most non-programming related tasks in a small ISV don’t happen quickly. You really need to think long term. Things like getting your marketing and product positioning in place can take months to years. There’s no instant gratification like you get from writing code, so you must always force yourself to think long term. Where do you want the product, marketing, and sales to be 6 months from now?

Admit that you don’t understand the end user and rectify that
There’s a good chance that the software you are writing is in a domain you are not an expert in. That’s where the opportunities are and that’s great, but you have to realize that you need to do more than just research the market. You need to understand the actual customers. Talk with them. I know you don’t want to but it’s an absolute must. Without talking to the actual end users you’ll never know what features you’re wasting your time on and which ones you don’t have that are critical.

A big mistake people make here is implementing the feature set of the competition to get started. That’s a bad move. It’s like when you copy your friends homework. You both end up with the same mistakes. By talking to the customers you can avoid the mistakes your competition has already made.

Love your customers
Many software developers come from a back office IT background. In most of the IT shops I worked in there was generally disdain for the customer (internal customers). It’s not surprising since IT is often asked to do far too much with far too little.

It’s time to put all that aside though. I see a lot of ISV’s who seem to carry this over and there’s no place in commercial software for it. The only way to be successful is to love your customers. That means meeting their needs as much as possible and going to great lengths to do so. When you can’t you need to explain why. When they choose a competitors product be respectful and remind them the visit you again if that product doesn’t end up meeting their needs.  I’ve found that I’ve switched lost sales back to me simply by being nice to the customer on their way out the door.

Remember to design for ease of use. Even advanced users like easy.
Your user interface is no place for fancy technology tricks. Keep is simple. Advanced users love simple just as much as newbie’s. The most important reason to keep is simple is for your trial users. A trial user is only going to give you a few minutes of their time. If you waste it by making them figure out a complex interface you can bet they’ll be off looking for another solution.

Remember to bounce your ideas off people who aren’t working on the project
Make sure to always take time to show off your latest builds to someone who’s not very involved with the project. Fresh eyes will often find big holes in your user interface. Even if the person doesn’t know much about your domain, you’ll be surprised at how many issues they’ll point out that you’ve never seen before!

Don’t be afraid to pull things out
There’s nothing I hate more as a programmer than pulling perfectly good code out of an application. Alas, you’re going to have to do it. Through the process of developing you’re going to discover features that should never have been. Ideally you’ll find this out before actually shipping. When you find these features you need to pull them before they cause any trouble.

For example, when I was half way through developing HelpSpot I discovered that one of my features just wasn’t working. I had built this tool for importing customer information into HelpSpot. This was a bad idea because it basically turned HelpSpot into a half baked CRM. It meant my customers would have to keep HelpSpot in sync with their real CRM and generally made the UI more complicated. So I scrapped a few weeks of work and pulled it out.

It turns out to be one of the best decisions I made. Rather than the syncing I came up with the Live Lookup system which allows customers to run queries against their existing CRM from within HelpSpot. It’s turned out to be a unique feature which is used by the majority of HelpSpot installations very successfully.

Patience is a virtue
There’s invariably a lack of time to get all the things done you need to. What would normally take a day takes weeks. Try to learn patience. I’ve found that I have to actively work at this or I get frustrated that I’m not making enough progress. Avoid setting up dates and expectations with your customers when possible. Don’t promise something in a month if it might take 3. I’m still working on that one myself

Treat it like you are learning to program all over
Remember when you first learned to program and you read every book. You bought 8 different books on that first language all of which basically said the same things but you read them all anyway because you couldn’t get enough. That’s how you have to treat the transition from programmer to entrepreneur. Read everything you can get your hands on about your target market, running a small business, marketing, general management, time management. Ideally you should read it before you even start coding. The mistakes you’ll be able to avoid by doing so are well worth the time commitment.

As always I look forward to your feedback. If you have made this transition yourself, please add your tips for others to learn from.

http://www.menshealth.com/cda/article.do?site=Mens...

17 things you've probably never done, but should

1. Approach and engage a pretty girl in conversation with no prompting from anyone. She might not want to talk. She might even tell you to go jerk yourself a soda. But she might not.

2. Be debt-free. Compounding interest is like a sorority girl on Ecstasy. She'll go both ways, but you get a hell of a lot more out of it when she's going your way.

3. Try the sport that you ridicule most. Golfers and skateboarders wouldn't be so friggin' smug if they knew how difficult the other guy's favorite activity really is.

4. Finish something early.

5. Let someone else brag about that cool thing you did.

6. How 'bout a mercy flush?

7. Disagree with the person you fear most.

8. Read a novel with more than 300 pages, written before 1950, set somewhere other than the United States.

9. Eat brussels sprouts. To make it easier, pretend a gun is pointed at your temple and you have a choice: Take them orally or another way.

10. You think you're tough? Say exactly what's on your mind when you're at your most vulnerable. We'll see how tough you are.

11. Say "Cool tat" the next time you see intricate tribal art on the small of a woman's back. She knows what you're really saying, but verbal subtleties like this can mean the difference between receiving an amused smile and waking up in the ICU wearing a diaper packed with ice.

12. Embrace the male carpe diem death cliché. You will die, friend, and dozens of bungee-jumping, skydiving, scuba diving, rock-climbing, boxing, surfing, and motocross outfits are depending on your "holy crap" realization of mortality to make a living. Why wait? Fix your roof when it's sunny.

13. Leave work early for a midweek afternoon ball game. Tell no one. Go alone. Strive to notice the subtleties TV doesn't show: the third baseman cheating a step before the pitch; where the center fielder sets up; whether that sweet creature two rows over really likes baseball or is just there for her boyfriend. Toss the ticket stub on the way out; you were never there. We guarantee you'll remember this game longer than if you got permission from the wife and went with five buddies.

14. Go a week without quoting anyone. When you consider movies, late-night monologues, sportscasters, bosses, wives, kids, founding fathers, regular fathers, Shake-speare, philosophers, and Homer Simpson, this suddenly becomes a lot harder than you thought, huh?

15. Pursue a woman not because she's so hot but because she's so cool.

16. Buy a stock based on research you did all by yourself, from scratch. Restaurant crowds won't fall silent when you speak, but nailing a six-bagger on your own beats Maria Bartiromo's sloppy seconds any trading day.

17. Ask questions first. Save your bullets for later.

Blogging about RubyConf 2006

Saturday October 21, 2006 2:38AM
by Curt Hibbs in News

RubyConf 2006 started today in Denver, Colorado. I wasn’t able to go this year, but fortunately others are (and will be) blogging about it. Please send me links that you find to RubyConf 2006 blog posts, and I’ll update this posting to keep track for everyone (send to curt at hibbs dot com).

Videos

• Matz’ keynote, RubyConf 2006
• Adam Keys’ USSRuby Sketch from RubyConf 2006
• Rich Kilmer’s Web 2.0: Beyond the Browser

Day 0

• Pat Eyler: Before RubyConf 2006
• Austin Ziegler: Ruby Conference 2006 - Day 0

Day 1

• Austin Ziegler: Ruby Conference 2006 - Day 1
• Austin Ziegler: Ruby Conference 2006 - Day 1, Evening
• Pat Eyler: RubyConf 2006: Day One
• Kevin Williams: RubyConf 2006, Day One

Day 2

• Kevin Williams: RubyConf 2006, Day Two
• Pat Eyler: RubyConf 2006: Day Two

Ruby Implementors Summit

• I wanted to break this one out separately, because I believe that it could eventually turn out to be very important. (Pat Eyler)

Blogging by Speaker/Topic

• History of Ruby by Masayoshi Takahashi (Nick Sieger, Kevin Tew)
• Nathanial Talbott: Dynamism in Business (Nick Sieger, Kevin Tew)
• Evan Phoenix: Sydney & Rubinius (Nick Sieger, Kevin Tew)
• Glenn Vanderburg: Rinda (Nick Sieger, Kevin Tew)
• Geoff Grosenbach: Graphics with Ruby (Nick Sieger)
• Zed Shaw: Fuzzing (Nick Sieger)
• John Long: Radiant CMS (Nick Sieger)
• Matz Roundtable (Nick Sieger)
• Laurent Sansonetti: Mac OS X and Ruby (Nick Sieger)
• Tim Bray: I18N, M17N, Unicode and All That (Nick Sieger, Kevin Tew)
• Michael Granger: Natural language generation and processing in Ruby (Nick Sieger, Kevin Tew)
• Matz Keynote (Nick Sieger, Kevin Tew)
• Rich Kilmer: Web 2.0 Beyond the Browser (Kevin Tew)
• Lightning Talks (Kevin Tew)
• RejectConf Summary (Kevin Tew)
• Justin Gehtland: Streamlined (Kevin Tew)
• Koichi SASADA: YARV: on Rails? (Nick Sieger, Kevin Tew)
• John Lam: You’ve got your Ruby in my CLR (Nick Sieger, Kevin Tew)

Update 1: Pat Eyler and Kevin Williams are also blogging the conference. I have added their links above.

Update 2: Keven Tew and Nick Seiger are blogging by speaker, rather than by day. I added their links above.

Update 3: Added Day Two.

Update 4: Four mose individual sessions reported by Kevin Tew.

Update 5: Nick Seiger posted a couple more individual sessions, and Pat Eyler posted about day two.

Update 6:Pat Eyler reported on the Ruby Implementor’s Summit.

Update 7:Added links to videos from RubyConf 2006 (including Matz’ keynote).

some tip useful

Subject: Enumerable and WIN32OLE
From: "bpettichord gmail.com" <bpettichord@gmail.com>
Date: Wed, 27 Sep 2006 06:51:48 +0900

I make a lot of use of the WIN32OLE library, with many thanks to Nobu
Nakada.

One of my common idioms is to take a WIN32OLE object that implements
the IEnumerable interface and extend it with the Ruby Enumerable Mix
in. Thus:

      rows = @ole_worksheet.usedRange.rows.extend Enumerable
      rows.select do |row|
        entire_row = row.entireRow
        entire_row.columns(1).text == '' and # comment
        entire_row.columns(2).text != '' # no action
      end

It strikes me that it might be reasonable to expect the Ruby win32ole
library to do this for me automatically. Do you agree?

Bret

IE Tip: Cheeky way to see the current state of the page

Category: HTML, IE, Tip

Who needs debuggers and add ons, when you can simply put the following in your IE address bar:

JAVASCRIPT:

2. javascript:'<xmp>'+window.document.body.outerHTML+'</xmp>';

Posted by Dion Almaer at 10:21 am

4.1 rating from 59 votes

13 Comments »

Comments feed TrackBack URI

or for IE:

javascript:'<xmp>'
+window.document.documentElement.outerHTML
+'</xmp>';

Comment by michael — February 23, 2006

Or, push it to a new popup window so you don’t lose the page:

javascript:window.open(”javascript:'’ +opener.window.document.documentElement.outerHTML +'’”);

Comment by James — February 23, 2006

Oops, the previous comment should say:

javascript:void(window.open(”javascript:'’ + opener.window.document.documentElement.outerHTML + ‘’”));

Comment by James — February 23, 2006

OK, hopefully the last time (HTML and quotes were being converted):

javascript:void(window.open("javascript:'<xmp>' + opener.window.document.documentElement.outerHTML + '</xmp>'"));

Comment by James — February 23, 2006

So simple yet so cool. Dunno why I never thought of this…

Thanks for the great tip!

Comment by Jc — February 23, 2006

It works in IE and Opera. The same bookmarklet for Firefox&co is here:

javascript:''+document.getElementsByTagName("html")[0].innerHTML+'';

Comment by llook — February 23, 2006

I mean javascript:'<xmp>'+document.getElementsByTagName("html")[0].innerHTML+'</xmp>';

Comment by llook — February 23, 2006

And just for giggles, here’s all three rolled into one!

javascript:if (window.document.body.outerHTML != undefined){'’+window.document.body.outerHTML+'’} else if (document.getElementsByTagName(”html”)[0].innerHTML != undefined){'’+document.getElementsByTagName(”html”)[0].innerHTML+'’} else if (window.document.documentElement.outerHTML != undefined){'’+window.document.documentElement.outerHTML+'’} else { alert(’Your browser does not support this method of viewing the page source.’) };

Comment by c@M — February 23, 2006

Sorry about the double post… forgot to escape the < and > when I posted. Duh… live preview further down on the page. Let me strap my helmet back on….

javascript:if (window.document.body.outerHTML != undefined){’<xmp>’+window.document.body.outerHTML+’</xmp>’} else if (document.getElementsByTagName(”html”)[0].innerHTML != undefined){’<xmp>’+document.getElementsByTagName(”html”)[0].innerHTML+’</xmp>’} else if (window.document.documentElement.outerHTML != undefined){’<xmp>’+window.document.documentElement.outerHTML+’</xmp>’} else { alert(’Your browser does not support this functionality’) };

Comment by c@M — February 23, 2006

Instead of using document.body.outerHTML, I would recommend using document.documentElement.outerHTML : That way, you will also get the root node of the document you’re checking.

Comment by Arve Bersvendsen — February 24, 2006

Instead I just wiggle my fingers and websites do what I need them to do

Comment by Mojoe — February 24, 2006

[…] Found a interesting little post on Ajaxian, often in the SEO bussiness you want to fund the source code as fully rendered by the browsers. This is an easy method to do so, place this code in your address bar when viewing the page. javascript:’’+window.document.body.outerHTML+’’; […]

Pingback by Search Engine Marketing Blog » See the current html state of page in IE — February 25, 2006

Great tip. I vote for the last comment by James. At least that works best for me in IE…

Comment by B@rney — September 15, 2006

讨厌和无趣的人一起吃饭

认识yihuang是在python.cn列表上他问个crawler的问题，今天看到他的blog, 其中有两篇挺有意思的，转过来留个底. 我应该在有时间的时候仔信看看这两个项目，一直对stackless python很感兴趣的说.

他的url是http://codeplayer.blogspot.com/

一个是来自PLY(一个100%的lex, yacc的python实现)中lex.py的一段代码， 获得caller的信息
try:
  raise RuntimeError
except RuntimeError:
  e,b,t = sys.exc_info()
  f = t.tb_frame
  f = f.f_back           # Walk out to our calling function
  ldict = f.f_globals    # Grab its globals dictionary

另一个是stacklesssocket的有趣的异步应用.

import sys
import stacklesssocket
import stackless

sys.modules["socket"] = stacklesssocket

import urllib
import time

def download(uri):
    t1 = time.time()
    f = urllib.urlopen(uri)
    s = f.read()
    t2 = time.time()
    print "Downloaded", uri, "in", "%.1f" % (t2-t1), "seconds"
    return t2-t1


print " === Serial === "
t1 = time.time()
download("http://www.stackless.com/wiki/Tasklets")
download("http://www.stackless.com/wiki/Channels")
t2 = time.time()
print " --->", t2-t1

print " === Parallel === "
t1 = time.time()
stackless.tasklet(download)("http://www.stackless.com/wiki/Tasklets")
stackless.tasklet(download)("http://www.stackless.com/wiki/Channels")
stackless.run()
t2 = time.time()
print " --->", t2-t1

% spython async_fetch.py
 === Serial ===
Downloaded http://www.stackless.com/wiki/Tasklets in 2.6 seconds
Downloaded http://www.stackless.com/wiki/Channels in 2.7 seconds
 ---> 5.34717988968
 === Parallel ===
Downloaded http://www.stackless.com/wiki/Channels in 4.0 seconds
Downloaded http://www.stackless.com/wiki/Tasklets in 5.4 seconds
 ---> 5.43875193596

% spython async_fetch.py
 === Serial ===
Downloaded http://www.stackless.com/wiki/Tasklets in 2.6 seconds
Downloaded http://www.stackless.com/wiki/Channels in 2.7 seconds
 ---> 5.32963705063
 === Parallel ===
Downloaded http://www.stackless.com/wiki/Channels in 2.2 seconds
Downloaded http://www.stackless.com/wiki/Tasklets in 2.7 seconds
 ---> 2.71087312698

本来就没时间+懒得洗衣服，所以总是攒到周末洗，现在水管和洗衣机接口的地方坏掉了，花花的漏水:(
现在洗个衣服还要在家里等着，555
唉，接口是多么重要啊.

Livehttpheader is well, not bad. But it's not easy to program with, and get the stuff interests the most. And ethereal is too big and cannot see it live.
Also, this is a test post from live writer, pretty nice, i don't have to wait for the slow connection of space:)

From: John J Lee <jjl <at> pobox.com>
Subject: Tracing HTTP with tcpdump
Newsgroups: gmane.comp.python.wwwsearch.general
Date: 2006-10-08 21:16:30 GMT (4 days, 6 hours and 59 minutes ago)

Not very enthusiastic about using ethereal since I discovered just how 
huge it is and how regularly buffer-overflown  (seems a particularly 
bad thing to be for a network sniffer!).  So I started using tcpdump 
instead.  Since it took a bit of experimentation, thought I'd post the 
command I'm using ATM for looking at the loopback interface:

tcpdump -i lo -X -s200 'tcp port 80 and (((ip[2:2] - 
((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'

(I copied the stuff in brackets verbatim from the manpage and am too lazy 
to read it, but it's just picking apart the datagram bytes to discard some 
of the boring underlying TCP/IP mechanism)

Bump up the -s200 to something larger to look at POST requests.

Leave off the -i lo if you want to look at external traffic.

Livehttpheaders &co are nice too, but sometimes you need to be sure you've 
got the thing byte-for-byte correct, and tcpdump shows you that.

John