Chatting to bradfitz this morning, he mentioned he was going to try using Go to do some scripting-style tasks on the Android platform.

It turns out getting Go running on an ARM-based Android phone is easy. First, build Go for linux/arm:

~/go$ hg update -r release
22 files updated, 0 files merged, 1 files removed, 0 files unresolved
~/go$ GOOS=linux
~/go$ GOARCH=arm
~/go$ cd src
~/go/src$ ./all.bash

For testing purposes, we’ll use the most trivial of all Go programs:

package main

func main() {
    println("Hello, Android!")
}

Compile and link it (the ARM compiler and linker is called 5g/5l):

~$ 5g hello.go && 5l hello.5

This will produce a binary called 5.out, that we now need to transfer to the phone itself. To do this, enable USB debugging on the phone, plug it into your computer, and use the ‘adb’ tool from the Android SDK to upload the file:

~$ adb push 5.out /data/local/hellogo
1036 KB/s (155648 bytes in 0.146s)

Our binary will now be at /data/local/hellogo. Now we need to open a shell on the phone, and execute the program:

~$ adb shell
$ data/local/hellogo
Hello, Android!

Once you are able to achieve some real “traction” with your business (paying customers, revenue stream), it may seem the time to relax a bit, but in fact this is the point where many founders start to flounder. All the skills and instincts you needed to get to this level can actually start working against you, and you fail to scale.

Investors often say that successfully navigating the early stages of a startup requires lots of street smarts, guts, and luck. For successful scaling of the business, there has to be a transition to “executive” mode in the more traditional business sense. Certain behaviors between these two modes are incompatible, and can cause real problems.

Way back in 2002, John Hamm published some early work on this subject in "Why Entrepreneurs Don't Scale." From my experience, here is my interpretation of that work, identifying some strengths of an entrepreneur during early startup stages which can become problems for scaling:

• Perseverance. This is generally a required quality for a successful entrepreneur, but it can turn into an unhealthy stubbornness during the scaling stage. The key is to make decisions from data and feedback, once your business has real customers and real products. Trusting your gut at this stage isn’t good enough.

• Absolute control. During the early stages, you are the company, processes are not documented, you don’t have much help, so you need a fanatical attention to detail. To scale the business, you have to find people who can do the tasks, and delegate appropriately. Control freaks are doomed to failure.

• Individual loyalty. Most founders form very close relationships with the small team that gets the startup off the ground, and that is important. Scaling requires that you expand the team, probably with people you haven’t known. You also have to deal with the inevitable personnel challenges, even within the original team. Total loyalty can be toxic.

• Isolated and insulated. Working in isolation is fine during the creative phase of the startup, where the founder is often the designer and architect, as well as the builder. Now this same individual has to step into the spotlight, and meet with customers, analysts, and investors. Insulation from the real world will not work during scaling.

• Tactical versus strategic. Early stage startup founders have to think tactically. Even business school courses don’t teach you to operate strategically, deal with people objectively, and create loyalty within a diverse workforce. These are areas where past stumbles are the best teachers. Investors don’t want to fund your stumbles.

Every founder moving into the executive role has to step back and take a hard look at what works, and what doesn’t work. The best ones can do that, and they adapt. Investors and advisors see this as a critical part of their role, and often are the “bad guys” who ask the founder to step aside, while they bring in a “more experienced” CEO to take over the helm.

Unfortunately, some founders won’t adapt, and won’t step aside. Even if they are pushed out, they can cause terminal damage to the business by negative versions of their strengths, now seen as stubbornness, unwillingness to give up control, testing loyalty, and hiding from reality.

Thus my best recommendation, if you want to scale and to survive, is to open up and work closely with an “outsider” that you trust, such as a respected board member, a coach, a mentor, or an investor. The key is to expedite your learning, and take deliberate steps to confront your shortcomings. That way, you will become the leader your company needs, learn to stop floundering, and begin to fly.

Marty Zwilling

What other areas of study would improve a graduate's ability to be a great software designer?

1. Algorithms and data structures is the most essential study.
2. Computer hardware architecture.
3. Application areas, especially business data processing, database techniques and data mining.
4. Psychology, especially perceptual psychology, since the user is all-important.

1. Dipping:
As a decision maker you rely on information being passed to you by the people who report to you.  You’ll get sales information from your VP of Sales, marketing information from your VP Marketing, tech information from your CTO and so on.  But as a CEO you can’t rely solely on this information.  You need to “dip” down into your organization and learn directly from employees at all levels and with all skills.

It’s not just a Reaganesque “trust, but verify” issue although that’s certainly part of it.  As a leader you need to have an intuitive sense of your business that can only be formed by hearing directly from staff in every corner of your businesses.  Think of it kind of like running a national chain of restaurants and occasionally stopping in to wait tables to have a more intuitive sense for your processes, work conditions and the quality of your products.

An obvious example would be in sales.  As a CEO you never stop needing to go on sales calls (or to work the phones in telesales or customer support) and ceasing to do this as your company grows because you’re focusing on investors, recruiting, PR or whatever is a mistake.  By going on sales calls you pick up directly the feedback of what customers want and also what they’re telling you about competition.  You’re also learning directly about the skills of your sales staff by observing them in action.  It might tell you that you need better sales training or to hone your key selling messages.  They will tell you directly which features they think are necessary to win more deals (take this information as data points rather than conclusions).

I also liked to sit in on sales pipeline meetings.  I didn’t lead the calls – our VP of Sales or country managers did – but I listened in to hear about deal specific dynamics so when it came time for forecasting between the VP of Sales and myself I had direct knowledge of the deals from having heard the sales reps talk about their individual pipelines.

Similarly I liked to keep myself apprised of the technical decisions we were making.  I had long ago ceded the knowledge and responsibility for making the detailed technical recommendations about platforms, databases, hosting solutions, etc.  But I knew that to be a good decision maker I needed first hand knowledge rather than just a summary from my CTO.  So I would go to lunch with our senior architect and ask 50 questions about the differences between Postgres, MySQL and Oracle databases.

At my first company we went with Oracle because it had better handling of “clustering” at the time where we could have multiple instances of databases that we could keep synchronized.  By the time of my second company MySQL was a much more robust solution and worked well when you had to read a lot of information but was less performant on “write” activities.  As a content management system we had lots of write activities and went with Postgres.

I helped make this decision by “triangulating” between our DBA, lead technical architect and our VP of Engineering (who had a better grasp of the financial costs & development costs of each decision).  I could never have been involved in this decision without “dipping” below my CTO to understand the details.  If my CTO would have given me his update much detail would have been lost in translation.

I provide this level of technical detail because I want to remind CEO’s that you need to own these decisions.  If your company is small then make sure you’re asking CTO’s of other companies how they made their decisions about whether to self host or go with Amazon AWS.  How did they decide whether to use RightScale or to manage AWS themselves?  You might be a business person rather than technical but for key decisions you need information to make the best decisions.

It’s why when I’m evaluating an investment I often ask the CEO lots of detailed questions about all parts of their business.  Attention to detail matters.

Everybody Wants A Developer Ninja/King/Expert/….

There are a million words to describe a qualified developer. The most critical thing all companies want to avoid is a developer who will drag their feet or simply doesn’t know how to program efficiently. If you are a developer and you can’t program efficiently and keep churning out crappy code, don’t be too hard on yourself, just realize that the key aspect that separates the “developer geniuses” from the rest is that they are constantly learning, everyone else just sucks at life.

Granted, talent is important. If you aren’t the most logical (or intelligent) person on the block, you may want to try another profession and leverage your strengths. However if you are a curious individual, programming may be the profession for you. Best of all, developer salaries are rising quickly. Every company I know is looking to hire developers. Yes, you need experience. Don’t have experience? Sharpen those swords ninja!! Practice makes perfect so start building the “next hot app” and even if it doesn’t work out, you’ll at least improve your programming skills.

The wisdom that comes with experience seems like such a valuable asset to have. You have advice that people should listen to, you think, as you smirk condescendingly at the kid with the big idea and no clue what terrible obstacles stand between her and success.

I sometimes feel that skepticism creeping into my thinking when I look at a new idea being presented by an eager and innocent young entrepreneur. It’s a relatively recent thing, and I want to stamp it out like a cancer.

There’s no room in my world for that kind of nonsense. Who am I to tell someone that they can’t change the world? I say fight on. And if you fail I’ll give you a solid fist bump and tell you to get back on the horse, or whatever the saying is, and try again. Because you’re going to get it right, whether it’s this startup or another one.

What is LaunchPad?

LaunchPad is an easy-to-use development tool intended for beginners and experienced users alike for creating microcontroller-based applications. At $4.30, the LaunchPad offers everything you need to get started with your projects.

The LaunchPad development kit is a part of the MSP430 Value Line series. LaunchPad has an integrated DIP target socket that supports up to 20 pins, allowing MSP430 Value Line devices to be dropped into the LaunchPad board. Also, an on-board flash emulation tool allows direct interface to a PC for easy programming, debugging, and evaluation. Included are free and downloadable software development environments for writing and debugging software. LaunchPad can be used to create interactive solutions thanks to its on-board pushbuttons, LEDs, and extra input/output pins for easy integration of external devices.

I wonder it this works ok with the existing Arduino shields. Maybe not able to stack the pin-out headers, but at least you can jump the pins directly. :D