Each of us has our own set of strengths and weaknesses but we never take the time to figure out what they are. Even if you did would you know what to do with the information?

You’ve probably heard that you need to identify weaknesses so you can fix them. After all, if you’re already strong in an area there’s no need to hone that skill, right? You should focus on your weaknesses so people don’t point and laugh at you when you try to…do whatever it is you’re weak at. Right?

That’s what most people think, but I’ve found this approach to be a recipe for mediocrity.

Becoming World Class
People who become world class at something begin with a strength in that area.

Tiger Woods had some kind of pre-disposition to be a decent golfer. Paul McCartney had some kind of innate musical talent before he picked up a guitar, Yo-Yo Ma was likely a tiny bit better playing stringed instruments than his classmates, and Albert Einstein had something unique about his brain chemistry before he ever thought about the cosmos.

But these strengths take time to develop. To become world-class (or to take it one step beyond and re-define that term in your field) you have to invest thousands of hours of focused practice into that strength. This is known in psychology as the ten thousand hour rule, and Malcolm Gladwell ruined it for the rest of us by beating this idea to death in his book Outliers.

But the idea is that you need something on the order of 10,000 hours of focused practice to master something like the cello, golf, songwriting, or theoretical physics.

Becoming Mediocre
Perhaps Paul McCartney is particularly deficient in the skills needed to properly operate a motor vehicle. I don’t know this to be true, let’s just suppose for the sake of argument.

Suppose that when Sir Paul was young that instead of spending hour upon hour playing music that he had instead focused on learning the skills necessary to drive a car. He practiced steering, using the gas pedal, shifting, etc… all with the hope of becoming a Formula One driver.

He would have become a better driver, but it’s almost certain that he would never have become world class at an activity where he has a particular weakness.

Instead of becoming one of the best known singer/songwriters of all time he would have become a second rate driver.

By focusing on something where he already had an innate strength (or innate passion) he was able to become one of the best of all time. And the same story can be applied to Woods, Einstein, and Yo-Yo Ma.

Football vs. Track
One more example and then I’ll get back to talking about software and entrepreneurship.

In high school I played football because that’s what the popular kids did, but I wasn’t well suited for it. I worked my butt of at becoming a good football player. Every Saturday my dad would take me and my brother down to a park to run routes, practice diving, do speed drills…things that none of my teammates were doing on the weekends.

And I got better. But I was never, and could never have been, great. The skills required for football were particularly lacking in me, and although I was able to improve through literally hundreds of hours of practice, I was never as good as the best receivers in the league.

The track was another story. With my height I was well-suited for the long hurdles and winning races became almost second nature. I worked at it, but the improvements were dramatic as I invested time into running.

I excelled at it from the start and ended up setting a school record, winning the league, and going to the state championships. A far cry from my mediocre performance on the gridiron.

I’ve always wondered how much better I could have been on the track had I never played football, and instead invested that time into becoming a better runner.

Now Back to Software
Let’s translate this to being a software developer / entrepreneur.

Most people have no idea about their strengths and weaknesses. So that’s the first step – learning what they are.

And secondly, when most people find out they have a weakness they want to improve it.

“Oh my gosh, I’m a terrible public speaker…I need to become better at it!”

But this is the polar opposite, 180 degrees off, wrong way to approach it.

Instead, figure out your strengths and re-configure your career to amplify and build on them. Avoid any position that requires a lot of public speaking, but instead take that job (or start your own company) where you do a lot of solo coding (if that’s what you’re good at). Some people excel at not needing social interaction and being extremely productive on their own.

After struggling for years, wondering why I was unhappy at most of my jobs I came to realize that they were pushing me to improve upon my weaknesses. After a few years of introspection I decided to change my career path and became a Micropreneur. Micropreneurship fits well with my strengths and has lead to more career happiness than I’ve experienced in years.

Now Back to You
Most people, and developers in particular, are unhappy with their jobs. And I conjecture that much of that is because you’re doing something that requires you to utilize one or more weaknesses, and at the same time not taking advantage of your strengths.

If you’re not a good public speaker and you don’t enjoy it, don’t take a position in management where you have to present to executives every month.

If you’re not a good writer and don’t enjoy it, don’t start a blog.

It’s not only more productive to capitalize on your strengths, it’s way more fun. You’re good at it from the start; better than most, in fact. So you will experience a lot of victory in that area. This will mean the activity will be enjoyable from the start.

So what can you do? Spend $13 to buy StrengthsFinder 2.0 (or any other book that helps you find your strengths – this one isn’t magic; it just happens to be the one I’ve used). For a more fact-based justification of this entire approach read the pre-cursor to StrengthsFinder called Now, Discover Your Strengths.

Take the test and figure out your strengths.

Consider making a change in your career path.

It may mean you need to change jobs. You may need to do something rash like start a startup or start building apps on the side and become a Micropreneur. Or you may be amazingly lucky and your current situation is already making you extremely happy (and ask yourself if it’s because it’s amplifying your strengths so you know how to find this optimal situation in the future should things change).

But whatever you do, don’t focus on improving a weakness. I’ve been there. It doesn’t end well.

My roof is leaking. In five places. Whoever thought it was a good idea to build a house with a flat roof should be forced to duplicate Google’s PageRank algorithm in assembler.

So I called a roofer, Fred, to give me a quote to fix this mess. His skin is like leather and his voice sounds like a cheese grater…signs of a good roofer in my book. And damn does this guy knows what he’s talking about.

Expertise is fascinating. On the web we marvel at the forward-thinking genius of Paul Graham or the design expertise of 37 Signals. But a lot of industries don’t have this.

People who put hot tar on roofs do not tend to talk about the passion they have for their trade.

But the first thing Fred did when he saw my roof was to get downright upset at the shoddy work. They hadn’t sealed a roof jack correctly, and had left the flange outside of the [insert technical sounding word here] so they had to seal it with [hot something or other] and it was a complete kludge. There were at least six other comments along this line.

To me it looked like a normal roof. To him it was an insult to his craft.

Fred gave me a few options for fixing the leaks – a cheap one ($400) that would fix a few things but may leak as soon as next year, a more expensive one ($2400) that would fix everything and last 2-5 years, and a brand new roof ($6300) that would fix everything for 20 years.

And the look on Fred’s face when he was giving me the options was like something you see when you hand a developer a legacy website that’s suddenly started crashing under the weight of its own processing. He opens the code and sees calls that don’t close database connections, no database column indexes, and a snarl of spaghetti he knows will take a few months to untangle.

Sure, he can throw some hours at it and patch a few holes. But in the end the site will never scale and most of it will have to be re-written if anyone ever plans to take it big.

Passion translates into something incredible. It motivates co-workers, bosses, partners, investors and customers. People know when they’re in the presence of someone who really cares about their code/product/startup. Passion is impossible to hide.

If you don’t have passion for your code/product/startup everyone will know. It’s obvious you aren’t that into it, and people will not take you seriously. Without passion it’s impossible to convince people to believe in your vision.

Passion translates into being insulted when people don’t care about things as much as you do and are willing to hack a crappy solution together. It’s an insult to you, your product and your craft.

Whether you’re trying to get hired, promoted, funded or close a sale…passion wins. Ask Gary Vaynerchuk or Seth Godin.

I encourage you to show your passion for the one thing you care about most in your work. If doing so causes problems you’re in the wrong place. There is a home for people who are passionate about pretty much anything, you just need to find the partner/company/customer who is passionate about the same thing you are.

Fred shows up tomorrow to install my new roof. I have a feeling it won’t be shoddy when he’s done with it.

Product naming is hard.

Too many factors come into play when looking for a name and it’s almost impossible to decide on the right name once you’ve stared at the same list for a week straight. This is the kind of thing that keeps you up at night, even after you’ve made the decision.

And asking opinions is fine, but more often than not the people you ask are not in your demographic:

“Hi Mom. Things are good, thanks. Hey while I have you on the phone, what do you think I should call my enterprise level encryption engine?”

About two months ago Patrick Thompson, a member of the Micropreneur Academy, was in search of a name for his speed reading eBook reader for the iPhone. We emailed several times about the process he followed to find his optimal name, and given his creative approach I wanted to share it here.

As an aside, his application launched last week and you can find it at http://www.quickreader.net/ or in the iPhone app store under the name “QuickReader.”

The Approach
A while back Patrick contacted a handful of Academy members and asked for opinions on potential product names. Our task was to choose a few names we liked from a long list of ideas. From this data he culled a short list of potential names – around 40 – and put a survey on Amazon’s Mechanical Turk. He got the idea from these two links: here and here.

He asked people to view a screencast of the application, offer suggestions for the name and give their feedback on the app. He received 29 responses and paid a total of around $7.

With a successful test run in his pocket he put out a 14-question survey looking for 500 respondents. He paid $.055 per survey (including Amazon’s $.005), and had 50 respondents in the first 3 hours.

The Findings
Five days later Patrick had 250 responses and enough information to decide on a name, but let the survey run because he was receiving solid information from the other (non-naming) survey questions, as well as leads who were interested in being notified when the app launched. At the time of this writing he’s at 460 responses.

While the purpose of the survey was to choose a name for his application, he (wisely) took the opportunity to also ask about demographics. Among other things, he found that:

• A slight majority of respondents were female
• Nearly 75% were between 18 and 35
• 63% were in North America; 20% in India
• 28% of respondents were in his target market (meaning they owned an iPhone or iPod touch)
• 25% of respondents had ever read a book on a mobile device (not bad!)
• More than half had an interest in speed reading
• 21% volunteered to beta test and provided their email
• 20% asked to be notified when the app was available and provided their email

Obviously the population taking the survey was skewed towards a younger, technology savvy audience. But it’s close enough to his target market to work.

Regarding the product name, which was the original purpose of the survey, a list of 40 names was given to each respondent was asked to choose up to 3 names. While QuickReader wasn’t the top name for the entire population, it was a close second among people that had an interest in speed reading and 3 of the top 5 overall names had the word “quick” and “read” or “reader” in them. And QuickReader works well for some of Patrick’s future plans for the app.

The top name overall, throughout the survey, was iReadFast. While he decided not to use this for the product name (as it doesn’t fit well for a general e-book reader), he did grab the ireadfast.com domain name to use as a blog or education site in the future. I’m surprised the name was available.

Lessons Learned
Overall, Patrick said that using Mechanical Turk for the survey was a great experience and obviously quite cost effective. It cost him $27.50 for 500 responses ($.05 per respondent + .005 per respondent for Amazon’s cut). He was able to decide on an app name. He found out something about what devices Turks use and their attitudes about reading and speed reading, and he got a list of close to 100 e-mail addresses of people wanting to be notified when the app launched.

And finally, here is the advice he provided from his research and first-hand experience:

• Always do a small trial or 2 of your survey task before you start the real one
• Try to make it interesting for the Turk
• Providing a link to a screencast of the app was a good idea (the Turks enjoyed it)
• Provide a confirmation code in your survey, on the final thank you page, once they have answered all of the questions. This is what the Turk enters in a form at the end to prove that they took the survey.
• Executing the survey in an external survey site, rather than doing the survey directly in Amazon’s form, allows you to use the built in reports of your survey provider (rather than just getting the excel data.)
• Keywords are important. When you publish your task, try to add as many relevant keywords as possible.
• Even if your goal is narrow (e.g., selecting a name), use the opportunity to find out more about your potential users and market.
• Always have a question asking how you can improve the survey.
• Pay Quickly. It annoys Turks when you don’t.
• It’s addictive. It is hard to keep yourself from constantly checking to see if new results have come in.

Conclusion
Patrick’s search for a product name demonstrates a creative approach for Mechanical Turk. He invested a few hours and around $20 and wound up with a name he knows is a good choice for his market and a nice list of prospects to notify about his launch.

The reason I like his approach comes back to my desire to measure and quantify marketing. If there’s one thing wrong most people miss about marketing, it’s measuring and tweaking everything: your message, your copy, your videos, your tagline, even your price.

And while you can’t easily tweak your product name, Patrick took the next best approach by measuring in advance instead of thinking about it for week and going with a gut feeling. Quantifying these kinds of things will improve sales and, trust me on this one, will allow you to sleep at night.

A few weeks ago a Micropreneur Academy member asked about getting started as a freelance developer since freelance development can be more conducive to getting started as a Micropreneur.

My first reaction is that becoming a freelance developer (or starting your own consulting firm) can also be a lot less conducive to launching a product. Instead of being able to justify a somewhat fixed salaried workday, you find yourself working longer and longer hours as client demands increase. In addition, freelance development requires a lot more mental energy than being a salaried employee. Mental energy that can’t be spent launching your product.

The next step after becoming your own boss is to realize that you only get paid when you work. When you take a week off you get squat. So even if you raise your rate dramatically, you discover that you have to be constantly working, in addition to having no leverage. Bah – that isn’t what you signed up for!

But that’s an aside.

In terms of his question about becoming a freelancer, by far the most challenging part of becoming a freelancer is finding work. To ensure a steady stream of gigs (and income) you can’t just jump in and expect to pull jobs from Elance and Craigslist. Those are low-dollar meat markets and you’ll be lucky to pull in more than minimum wage since you’re competing against people halfway around the world.

A better approach is to focus on your strengths and from there determine the method(s) that will work best to differentiate yourself from every other the freelance developers around the world.

My Experience

Back in 2002/2003 I spent hours writing a sales letter and emailing it to 15 local design firms, offering my services as an outsourced development staff (I coded in PHP, .NET and Java at the time). I combed my local Craigslist daily and responded to posts looking for freelancers, and I kept an updated resume on Craigslist, Monster, Dice, Guru, and Elance.

I spent well over 100 hours over the course of a couple months, and all of this resulted in exactly 1 contract amounting to about $10,000. This was good, but I quickly realized I wasn’t going to make a full-time living (in the U.S.) with that approach.

A friend of mine runs a small consulting firm and he made 1000 or so cold calls last year. That approach may or may not be for you. He keeps his people busy so it obviously works for him, but I don’t have the verbal salesmanship nor the fortitude to make that many phone calls.

Writing and Launching

What finally broke the door open for me was starting this blog. Actually, it wasn’t starting the blog, it was sticking with it for a year. I invested around 500 hours during the first year and absolutely no one was listening.

Then a strange thing happened. Through a series of events – (a) I figured out my market and (b) came out of the Google Sandbox – my traffic and subscriber numbers increased dramatically over the course of a few months and I began receiving requests from people asking if I would do freelance development work for them. I increased by rate nearly 30% in 3 months due to the amount of work coming my way.

Sticking with my blog had completely changed the game for me.

Another thing that brought in a very nice contract was an article I wrote for asp.netPRO. The article took me 10 hours to put together, I got paid $500, and got a $30k contract out of it. Not a bad deal.

I also received several development requests when I launched a Micropreneur venture called FeedShot (which I later sold). FeedShot became popular right out of the gate and I received several requests for freelance work the few weeks after it launched.

Moral: Do Something Publicly

Every public artifact I created (this blog, articles, launching a new site) incrementally increased my credibility, and increased the number of development requests I received. In the end you have to invest time to build your name. In my case, and I’ve heard this is typical, it was years.

But the way I looked at it I was either going to invest 500 hours on my blog, or make 1000 cold calls.

In the end you’ll need to find your gifting and figure out a way you can use it to do something people will notice.

• If you can write, write articles or blog
• If you code, become a high profile contributor to open source projects
• If you enjoy speaking, start speaking at user groups

Anything relevant that you can do in public will increase the chance that someone will come to you looking for development work. And that’s the position you want to be in.

Consider this the Year in Review for Software by Rob. Here are my seven most popular posts from 2008:

The Software Product Myth
“A certain percentage of developers become unhappy with salaried development over time (typically it’s shortly after they’re asked to manage people, or maintain legacy code), and they dream of breaking out of the cube walls and running their own show. Some choose consulting, but many more inevitably decide to build a software product.

‘After all,’ they think ‘you code it up and sell it a thousand times – it’s like printing your own money! I build apps all the time, how hard could it be to launch a product?’”

Should You Build or Buy Your Micro-ISV?
“None of the products I’ve built or bought required skills beyond that of a mid-level developer. Let’s be honest, building an invoicing system does not involve insanely complex algorithms and coding chops. Most successful Micro-ISV products (and a lot of not-so-Micro-ISV products) could have been built by a few solid mid-level developers.”

Lessons Learned “Selling” My Micro-ISV
“Within a week of my ‘for sale’ post I received 20 email inquiries, sent out nearly that many NDAs, distributed 13 sales packets, and spent about 10 hours answering questions via email. I set a deadline for offers, and by the time the deadline passed I had three suitable offers on my desk. Two of them were nearly identical, with a down payment and monthly payments. The third was something I hadn’t expected.”

The Five Minute Guide to Becoming a Freelance Software Developer
“This advice is intended for someone looking to become a freelance software developer or web designer (or looking to start a small web design/development/consulting firm). If you intend to seek venture capital then move along…these aren’t the droids you’re looking for.”

8 Ways to Recession-Proof Your Programming Career
“So in this age of uncertainty how should someone react who simply wants to collect a few greenbacks in exchange for their brilliant programming acumen? You could hide under your imitation Aeron and hope no one notices, or you could start pursuing ways to recession-proof your career.”

The Single Most Important Career Question You Can Ask Yourself
“Some people are consumers by nature; they consume vast quantities of knowledge purely for learning’s sake. Others are producers; they consume knowledge with the intent of one day acting on the knowledge and producing something, be it a book, a song, a blog, a startup, etc… Neither is better than the other. The key is to answer one question: which are you?”

How to Recruit a Developer Entrepreneur for Your Startup
“If you’re a non-technical founder looking for a developer entrepreneur, these are questions you should ask yourself. Having been on the developer side of the coin a number of times, here is my take.”

A few months ago I received a review copy of Debugging Your Information Technology Career: A Compass to New and Rewarding Fields that Value Computer Knowledge. I haven’t written many book reviews on this blog, but this book caught my attention as it relates to some of my past posts on job dissatisfaction and the potential for an IT job crunch.

I’m intrigued by the unique concept of this book: to provide alternatives to IT workers looking to change careers, but who want to leverage their existing technical knowledge.

The book lists 20 positions and includes an overview of each, a job description, an example of the typical workday, advice on where to look for this type of job, and a look at how the job is likely to hold up to outsourcing and a recession.

A few of the job titles include:

• Product Manager
• Systems Engineer
• Technology Due Diligence Analyst
• Technology Insurance Underwriter
• Intellectual Property Lawyer

For someone looking to leave software development, this book would serve as a good starting point for additional research. I would not recommend it to the casual reader (the text is a bit dry), but if you are seriously considering leaving programming it’s a good way to get an idea of where you might find refuge.

If you’re in this position drop me an email and I will send you my copy. (sent)

Micro-ISVs. I’ve been contemplating the issue of building vs. buying for the past four years.

I’ve been on both sides of the coin: I’ve purchased 10 profit-oriented software products or websites, and built three.

Knowing what it takes to develop the initial version of a non-trivial software product (read: hundreds of hours), I’ve become a fan of buying. This is based on two factors:

1. I have no spare time and a bit of spare money
2. Hmm…no, I guess #1 is the only reason

As a software consultant I’m booked full-time and I bill a reasonable hourly rate. So to spend 348 hours (2 months) building a product means I’m approaching a mid-five figure investment into a software product. That’s not play money; those are real dollars that don’t wind up in my pocket.

And I don’t have the confidence in my ability to know a market well enough that I would drop that kind of money on an untested product idea when there are less risky alternatives.

Looking at the products I’ve bought and built, none of them required skills beyond that of a mid-level developer. Sure, there are products that are more complex, but let’s be honest, building an invoicing system does not involve insanely complex algorithms and coding chops. Most successful Micro-ISV products (and a lot of not-so-Micro-ISV products) could have been built by a few solid mid-level developers.

With this in mind, spending 348 hours of my time doesn’t seem like the best business decision when I can:

1. Hire someone to build the application (in my case, use the team I already have in place), or
2. Find a proven product that may already have a customer base, sales website, etc… that I can buy for less than I can build it

You probably think I’m nuts, preaching “buy” over “build” to a group of software developers. So let’s take a closer look at the scenarios:

Building It
I love writing software, so this has historically been my path of choice. However, the amount of money (based on lost consulting hours) I would spend on a 1.0, plus building a sales site, documentation, SEO, pay per click (PPC) campaign, etc… would be at least $40,000.

I have faith in my ability to build and market software, but that’s a lot of faith to put into something that’s generating zero cash. You’d be nuts to buy a software product with no revenue for $40,000.

However, if you want to run a Micro-ISV because you enjoy writing code, or you have a lot of non-billable spare time, then this is a viable option.

But I must caution you – laptops around the world are filled with the remnants of half-built products. Committing 200+ hours of your spare time to build and launch a product is no joke. Writing code 50 hours per week you would have a 200 hour project launched in 4 weeks…no problem!

But if you’re coding in your spare time you’ll be lucky to get in 10 hours of coding per week, and your productivity will be low because it will be 2 hour blocks when you’re already tired from schlepping mindless reports all day for “the man.” Trust me – I’ve done it. It’s not easy.

Soon that 200 hour project turns into more than 20 weeks of your free time…almost 6 months. The first month is a breeze, it’s the last five that’ll kill ya!

Hiring It Out
Hiring someone to build your software is a good middle ground, and allows you to maintain some control over the technical piece without it sucking the coding life from your veins.

The advantage of hiring out product development is that it gives you time to build the sales site, write documentation, focus on SEO, marketing, PPC advertising set-up, payment processing, and the hundred other things I’m forgetting to mention.

If you’re doing things right, the effort to get your product built is around 50% of the total time it takes to launch a Micro-ISV.

I’ve found success in outsourcing code and graphic design, and handling everything else myself. “Everything else” means the business side of things…the piece where you will  likely learn the most, where you can bring the most value, and that you can’t easily outsource.

And think about it…a lot of people can build a good invoicing application. A lot.

But how many can work the necessary marketing angles, form partnerships, create a profitable pay per click campaign, and build a compelling sales site? Finding someone who can execute on these is much more difficult (and more expensive) than finding a developer who can build your application.

The single most important factor in the success of a Micro-ISV is marketing and sales, not the software itself.

In no way am I arguing for mediocrity in software development – your software has to get the job done. However, don’t believe for a minute that great software beats great marketing. It never happens.

There’s a reason Bob Walsh doesn’t help developers write better applications. He helps educate them on sales and marketing.

FogBugz is good, but probably not the best bug tracking software on the market. Yet I bet it outsells most of its competitors by a huge margin based on marketing.

If you don’t know how to work the marketing angles, form the partnerships, and do the other things I mentioned above you’re going to need to:

1. learn fast,
2. find a partner, or
3. stick to the day job.

Seriously…building (or buying) a great application is not going to get you there.

With this in mind, let’s take a wild swing at the costs involved in this approach:

The graphic design and HTML will run from $500-$1500 if you offshore (optional depending on your personal view). Doing it in the U.S. will cost $2,000-6,000.

Two months of development (a safe estimate when hiring someone to build a small product from scratch) will run $14k-$21k here in the states, or around $7k if you offshore.

Total you’re looking at $16k-$27k in the states, $8-9k if you offshore. These are obviously very rough numbers based on a typical Micro-ISV product requiring two months of development.

The potential pitfalls of this approach are obvious: if the developer is bad, you get software that doesn’t work. A key strategy here is to screen your developer carefully and only hire really good ones.

Also, design the DB and screen mock-ups yourself. Not only will you get much closer to the product you envision, you’ll be able to maintain it in the long-term.

Buying It
This is the approach I started favoring about two years ago. It started with my interest in buying (and later selling) domain names and websites. I soon realized that there are bargains to be had when buying a product or site that’s already making money.

DotNetInvoice (my ASP.NET billing product) is a good example – I purchased the product, sales site, payment processing code, search engine rankings, and a small customer base for about 20% of what it would have taken me to build it, and yes, even cheaper than I could have hired someone to build it. It was built in Florida by two professional developers in their spare time. Quite a deal, indeed.

The reason these products and websites sell for such low valuations is that the market values revenue, and most of the product developers don’t have the marketing and sales knowledge to bring their product to its full revenue potential.

This means there are completed software products and websites for sale, selling for literally pennies on the dollar compared to your cost to build them. I realize this sounds like a late night infomercial, but believe me, it’s true. And how much would you expect to pay for this information? Just kidding…

The pitfalls of this approach:

1. You’re taking on risk in buying a product you didn’t build
2. You can’t search for a specific type of product; for the most part you’re limited to what’s for sale

As an example, I didn’t go looking for an invoicing system. I happened across DotNetInvoice and made an unsolicited offer. If you read my original account of the purchase you’ll know there were some early hurdles that I had to overcome. But once I worked out those kinks I’ve never doubted that I made the right decision.

One aspect I really like about buying a product is that it forces you, right off the bat, to not think about code.

As developers we want to spend all of our time working on technology because it’s where we’re most comfortable. But as I mentioned above the real hard work, and where you should spend the majority of your time, is on marketing, PPC, SEO, and partnerships. Buying a product forces you to think like this because the thing’s already built.

If you don’t want to spend the majority of your spare time on non-technical issues like marketing, I suggest partnering with someone who does, or sticking to the day job. The day job will probably pay better, anyway.

A friend of mine wrote the other day:

If you include parentheses ( ) anywhere in the directory path of a website, the error list in Visual Studio 2005 SP1 will not report the File/Line number/Column number for any compile time errors in the website project.

This has been a known issue since at least last year (I found blog posts dating from back then). One of the developers here [at his current place of employment] reported it to Microsoft months ago when they were on-site and nothing happened. I asked about it again last week after spending a couple of hours tracking down an error, so he opened a support ticket for it. A week later MS gets back to him and says “change the parenthesis to brackets and it will work fine.”

Except that we are on 3.x of the application and it’s all in MS Team Foundation Server (TFS), and TFS doesn’t allow you to rename a project (according to the guy I’m working with).

First of all, ouch.

Secondly, can anyone confirm or deny that you can’t rename a project in TFS?

Third, if you can’t rename a project in TFS…Microsoft, this is lame…fix it!

Giles Bowkett published a post titled Two Flaws With “Time Off From Programming” that disputes some of the thoughts in my recent article The Technology Cliff: How Time Off From Programming Affects Your Chops.

The first point he disagrees with is that leaving programming hurts your coding skills. Giles took a similar leave from programming that was similar to my foray into management, except he became a “starving artist”:

…what I lost in technical knowledge I gained in perspective…After that period, the code I wrote upon returning was more compact and more powerful. The things I built were more inventive, more original, and more worth building in the first place.

I can’t dispute first-hand experience, but I have a hard time agreeing that leaving coding for 2-4 years to become an artist is going to leave you in a better place to come back and hit the ground running writing code. Leaving for a short sabbatical is fantastic; want to throw clay pots for 6 months? Awesome…I bet you’ll come back more motivated and energized.

But the premise of my article was that becoming an artist, a manager, or a shoe salesman for several years is going to take its toll on your coding skills; I don’t see any way around it.

Next, Giles comments about my statement that “4 years could include 2 or 3 new releases of your language”:

Consider how different this sentence would be if Rob wasn’t assuming that you use one language, you choose that language, you settle on that language, and four years later, even though you haven’t written any code in it over the past four years, that language is still your language.

4 years could include 2 or 3 new languages you might use.

Suddenly it sounds like fun!

This is true; if I came back to programming after 4 years I would consider switching to a new language. But I don’t see how this changes the conclusion.

Whether you try to learn the past 2-3 revisions of a language you know, or try to learn one from scratch, the learning curve is going to be similar. I would argue that if you are an expert in a language (I don’t mean in the syntax, but the class libraries, architectures, standards, style, etc… a truly deep expertise) and you come back in 4 years, you’re going to have an easier time returning to your expertise in the language that you left, as opposed to something completely new.

Learning a new language is fun? Definitely. Easier to transition into? No chance.

Finally, Giles concludes with:

If you want time off from programming to be good for your programming skill, choose a way to spend that time off which will be good for you in general…Time away from programming is very, very healthy, and you should definitely take it now and again.

I agree with him here. I’m a hearty proponent of sabbaticals, long vacations, and lots of travel. Short times away from programming have always done me good and allowed me to return to work refreshed and with new perspective. But stepping away for multiple years is going to take its toll on your expertise, whether through new technology releases, or simply memory loss.

[tags]programming, sabbaticals, coding[/tags]

By the time I was 13 I had been selling candy and comic books to my classmates for almost 3 years. Though I did quite well, I was itching to try something bigger, and that meant extending my reach beyond the walls of Math class.

This was the late 80s, so resources were limited for a 13 year old living in the country. I ordered all of the free information available in the work at home section of the Penny Saver (a free newspaper consisting entirely of ads), and started going to the library twice a week to read up on entrepreneurship. I was searching for a business idea that I could pull off at 13, and after literally hundreds of books, booklets, and information packets I decided to publish my own booklet on comic book collecting.

“Smart”
Since I was seven years old I’ve been an avid reader. I consumed 2 or 3 books a week during my childhood, including a large collection of “crazy facts” books and the Guinness Book of World’s Records (every year). By the time I was 13 I’d been reading 2-3 books a week for 6 years, and the breadth of my knowledge was astonishing for someone my age.

I knew how the stock market worked, why Beta had lost to VHS, why Apple was losing market share to the PC, and how double-entry accounting worked (although I couldn’t do double-entry accounting). But I had no idea how to start a business. With all of my book knowledge about the business world, I had no clue how to execute an idea.

I’d read several books on self-publishing and writing non-fiction, and I could have a really good conversation about them, but I’d synthesized the information for knowledge-sake, rather than to act on it. That made a big difference.

And so it continued for months…I didn’t have the guts to start writing the booklet for fear I wouldn’t know what to do next. Instead, I visited more libraries and sought magazines that did nothing but rehash information I already knew. I filled my head with the same information from piles of resources, but I still couldn’t get things going.

After months I finally took the leap. I spent 60 hours researching and writing the booklet. I printed it at Kinko’s, placed a few classified ads, and sold 9 copies at $15 apiece, breaking even on the cost of printing and advertising. Financially it was a wash, but I learned a valuable lesson.

The Question
13 years later I went through a nearly identical scenario when I started my consulting firm, The Numa Group.

I’d read stacks of book about entrepreneurship, startups, management, leadership, consulting, and running a service business, but I had no idea how to get started. I was waiting for the one book that was going to kick me into action by telling me exactly how to proceed given my skills, strengths, goals, and financial situation. Alas, that book never appeared. I finally realized that I needed to take a leap of faith and go to a place where no one else could lead me.

Through these experiences I realized the following:

Some people are consumers by nature; they consume vast quantities of knowledge purely for learning’s sake. Others are producers; they consume knowledge with the intent of one day acting on the knowledge and producing something, be it a book, a song, a blog, a startup, etc… Neither is better than the other.

The key is to answer one question: which are you?

I want to say again that neither is better than the other. If we were all consumers we wouldn’t have anything to watch; if we were all producers no one would be reading our blogs or listening to our podcasts. What matters is:

There is a huge benefit to finding out if you tend to be a producer or a consumer.

Which Are You?
If you convince yourself that the zillions of books, blogs and podcasts you’ve consumed over the past 2/3/4 years are in preparation for that glorious day when you’ll tell your boss to stick it in his ear because you’re heading out the door to starting your own company, you are wasting your time. Don’t read another blog post about startups, Micro-ISVs, or the business of software. Once you’re done reading this post (or even before), go start building something (a product, a blog, a company…). Because until you do, the knowledge you’re gaining is all but worthless to you.

But if you realize that one of the pleasures in your life is to read about code/startups/entrepreneurs/music, then embrace that you are a consumer. Knowledge for knowledge’s sake is not bad as long as you realize that you are not working towards an end beyond your own edification, which again, is not a bad thing.

Likewise, if you’re someone who has an unquenchable desire to produce something, then stop reading about other people, and start doing it yourself. Seriously, don’t read another blog post, tweet, or issue of Fast Company until you’ve made a visible move towards that goal you so desperately want, but think that reading and dreaming about will somehow make it come true. Once you’ve made that single action towards advancing your idea, you can come back and read a few more posts.

While it’s true it’s not either-or, that you are likely a mixture of both types and will experience fluctuation in your ratio of production vs. consumption from one month to the next, unless your name is Robert Scoble you really do have to choose one or the other.

To recap:

• Consuming for the pure love of learning is absolutely ok.
• Producing purely because you have a fire that won’t die until you do is fine, too.
• But don’t kid yourself about who you are.

If you’ve been reading startup blogs for years and never started anything, it’s time to accept that your tendency is to be a consumer. It’s not to say you can’t break out of that classification by starting something, but if you haven’t done it thus far you’re not likely to do it soon without some external motivation (maybe this post?).

If you have 50 software product ideas and your hard drive is littered with folders containing 30 lines of code from each, you tend towards being a consumer (or at least a producer who has trouble finishing things).

And if you figure out that you are a producer, stop daydreaming about the day you’ll make things happen. Start making it happen in the next 30 days, or forever hold your peace.

Additional information: Baker University

I received an email the other day asking how long it took to get my coding chops back when I moved from management back to development. The author asked:

Once you adopted your ‘Write Code’ mantra, how difficult was it to reverse the ‘management lobotomy’ (an excuse a prior manager had when he no longer could provide detailed technical value). Did you find yourself struggling to get back into ‘for loops’, ‘if statements’, ‘datasets’, and the like?

Chops
Allow me to answer this simple question with a story only moderately related to software development.

I’ve played the guitar since college. I’ve played in several bands, written a few dozen songs, and performed in front of tens of people (not a typo). I haven’t played seriously in almost 4 years, but I can still pick up a guitar and sound pretty good. That’s the thing with the guitar – it’s easy to play; it’s hard to be good (sounds a bit like writing software).

If you compare my proficiency today with the “me” of 5 years ago, we are worlds apart. Five years ago I played at least an hour a day, and often practiced with other musicians. Playing the guitar every day has an amazing effect: the scent of the wood becomes tantalizing, the tone of your playing becomes warmer, strumming and picking becomes effortless, and your muscle memory allows you to play difficult pieces with no conscious thought. You begin to feel tied to your instrument, as if it’s an extension of your body instead of a big piece of wood and strings. It’s almost as if the guitar plays itself.

But these days it’s a struggle. My fingers and wrist hurt after about 5 minutes, my strumming is stiff, and my fret-hand feels like it has arthritis. But even as far as I’ve fallen, I could get back to my glory days with about 8 weeks of daily playing.

The similarities between guitar playing and coding are obvious so I’m not going to discuss them here. It’s one of the differences that I think is important: not playing the guitar for 4 years means you lose muscle memory and a few songs, but leaving programming for 4 years is like a death sentence to your technical knowledge. Not because you’ll forget what an if statement is, but because programming languages move so quickly that 4 years could include 2 or 3 new versions of your language. Think of a VB6 developer who took 4 years off between 2001 and 2005 and tried to pick up .NET 2.0 based on his existing VB6 knowledge. We still put DLLs in System32, right?

Returning to the guitar after 4 years is a lot like going back to programming after 4 months…all you’ve lost is muscle memory. But return to programming from management after 4 years and you’ve lost something else: first-hand knowledge of the new technology that’s released (seemingly) every few months. There’s a point around 12-18 months where returning to coding becomes exponentially more difficult.

This is good to know if you’re approaching the point where your technical skills are about to fall a full version behind. Realize you’re falling off a technology cliff that you will have to scale if you ever decide to code again.

The Real Answer
Back to the original question: the first time I returned to development was after a 7-month management hiatus, and it took 3-4 weeks to get back to full speed.

The second time was noticeably worse; I was a non-coding technical lead for nearly 2 years. When I emerged from my cave I was almost two .NET Framework releases behind, and not only did I face getting up to speed with new language features like Generics and LINQ, I ‘d missed out on a slew of new ASP.NET Controls, and concepts like ORM and MVC had started their rapid move to the forefront of the .NET development community.

As expected, I got back to full-speed coding within 6 weeks, but it was at least 6 months before I climbed back up the cliff.

[tags]programming, management, guitar[/tags]

Every once in a while I find myself in a conversation about scanning for viruses from code (yes, my life is that exciting). The scenario often goes like this:

A middle-manager, having recently learned about viruses from his son’s copy of Wired magazine, realizes you’re saving user-uploaded files to your web server, and asks if you’re performing virus scans on the uploaded files. You panic, mumble something about how it’s “in the works,” and rush off to look for an open source virus scanning component.

You frantically search Google for “virus scan from [language of your choice]” but the results are dismal. You try 5 or 6 other searches and they all yield the same result: people like yourself asking this same question on forum after forum, with no helpful answers.

A while ago I went down this rabbit trail (sans the middle-manager) trying to scan for viruses from ASP.NET / C#. After working on it for a few days I arrived at the following conclusions:

Symantec and McAfee hose you
One of these companies doesn’t have any kind of API, the other has a command line tool that gives you the false confidence that you can hit it from code, but 7 hours later you’ll realize that although it runs fine on the command line, executing it from code inexplicably results in absolutely no output. In other words, you can run it but you’ll have to guess what the results were. (I forget which company does which, but spend 2 or 3 hours on their websites and you’ll find the answer).

There are a bunch of virus scanning companies you’ve never head of
Seriously. I had no idea there are so many companies in this space.

Sophos has a good command line interface
After pulling my hair out with Symantec/McAfee for a couple days it was a snap to get a call working from .NET to Sophos’ command line interface. In a couple hours I had a fully functional virus scanner. Hooray!

Sophos’ server license is expensive
Sophos runs about $100 for a license, but as soon as you install it on a server they charge for a server license, which is around $1000. Ouch.

It’s likely this is all a waste of your time
If you have one or more real-time anti-virus scanning engines running on your server, as soon as you save an infected file to the file system it will disappear (quarantined by your a/v software). And since you can’t scan a file without first saving it to the file system, none of this is really necessary. The quick and dirty approach is to save the file to the file system and check if it exists. If it does, no virus. If it’s gone, virus.

Of course, there’s a big assumption there that your real-time a/v software is running. Using this method depends on your risk tolerance: for 1% of the work you can have 99.5% of the security. If you (or your middle-manager) need that last .05%, see below.

For the last .05%, try MetaScan
After a few days of working through this issue I found a product that essentially wraps the major virus scanning engines and provides you with an API. It’s not cheap (pricing is here), but a better approach than cobbling something together on your own, and it allows you to scan the same file using multiple engines.

I haven’t actually used it so I can’t recommend it per se, but currently it’s the only game in town so worth a look. Note: this is not a sponsored post and I receive no kickbacks from MetaScan.

[tags]antivirus, virus scanning, asp.net, php, java, sophos, metascan[/tags]

Regular reader (and former co-worker from 8 years back) Matt Youell posted the following comment on my post about moving to Boston:

Do me a favor and post on how you move your tech stuff. I just did a modest 600 mile move back in January and it was a pain in the ass. My computers made it intact but then getting set back up, getting services, etc. was a real struggle. Of course I hadn’t moved in almost 7 years, so I was pretty entrenched. I’d love to know how you manage with all your moving.

Matt and I emailed a few more times on the subject, and he brought up some specific problems he ran into during his move that I’ll discuss below. Having moved 9 times in 7 years I’ve gotten pretty good at staying lean in the “stuff” department, and staying mobile with my technology.

Get Rid of Your Desktops
I used to host a few development “servers” at my house (in quotes because they were crappy, white-box desktops that my former employer called “development servers”). But once desktops (and now laptops) became powerful enough to run enterprise database software, an IDE, a browser with 15 open tabs, UltraEdit, NUnit, and a media player, I no longer had the need for an external machine. I also found that I spent more time and money than any sane person should spend keeping up with patches, defragmentation, replacing bad components, and keeping software up to date. It wound up costing several hundred dollars per year (which I could live with), and 40+ non-billable hours per year (which I couldn’t).

So I got rid of everything and I’m now a single-laptop developer. It’s a beefy dual-core Dell, but it handles the workload nicely and I don’t have to worry about hardware issues since everything’s under in-home warranty. Of course, the software issues haven’t gone away, as my virtual machines need patches and active anti-virus subscriptions.

At some point after that hardware cleansing Mike Taber turned me on to Windows Virtual Private Servers (VPSs). Linux has had VPSs for years, albeit through a different virtualization technology, but paying $40/month for your own Windows Server is a sweet deal.

If you’re a small software shop, check out HostMySite. I’ve been using their VPS for about 6 months and it makes a fabulous test and continuous integration server.

Use a KVM Switch
Ok, I lied when I said I don’t have any desktops. I have a single personal machine with a huge hard drive that I use exclusively for video editing.

For proper ergonomics my laptop sits on a Griffin laptop stand, meaning I need an external keyboard and mouse. In addition, I have two external monitors for the complete three-screen viewing experience, which means I have a lot of hardware sitting on my desk.

A few years ago I also had an additional keyboard, mouse and monitor for my video editing desktop, but this was before I discovered KVM switches. I use a $20 KVM switch I bought on Amazon. I hit a button and my keyboard, mouse and monitor are connected to my laptop. Hit the other button, and I’m controlling my desktop.

Bam! Half the hardware, half the crap to move, half the crap to re-cable and reconnect when I get to my new house.

Keep Your Packaging
Everyone doesn’t have the space for this, but I am a fiend about keeping boxes for my electronics. I have boxes inside of boxes inside of other boxes from 3 years back. I hate having “stuff” around, but having the original boxes and packaging for the stuff I do own has made moves much simpler. Keep what you can for the most fragile pieces, and before your next move head down to a local computer store and ask if they have any spare boxes.

Migrate Your Old Media
As recent as a few years ago I had two boxes of floppy disks lying around with data I didn’t want to toss. I still had a floppy drive at the time, so I moved the data from the floppies to a $20 Flash Drive and chucked the originals (it’s amazing to me that thumb drives can now hold thousands of floppies).

If you don’t have a floppy drive, look on Craigslist for an archiver who can burn your data onto CD or DVD. This is also a great way to get rid of old VHS tapes, which take up tons of room and don’t hold up over time.

Internet Connectivity at Your New Home
Matt mentioned a 3-week delay in getting FiOS connected at his new house since they had to dig a small trench in his driveway (FiOS is at-home fiber optic internet service). I ran into a similar delay during a 2003 move, and found a decent hack to get around it.

The phone company used to require 10 days from the time a phone line was active until DSL could be activated. They had a lame excuse about “vetting the line,” but I always assumed it was just a limitation of their software. Nowadays you don’t have to wait 10 days.

In any case, due to buyer/seller issues I couldn’t get a phone line installed before our move-in date, so I was facing 10-days without connectivity. At the time of this move I was nearing the end of a big project and being down for even a few days was not an option. I was a bit panicked at the prospect of having to hoof it into town every day and pay for wireless (at the time there wasn’t free wireless in Pasadena).

After some research I found that the cable company could activate their service instantly. Since cable was 2-3x more expensive I wanted to go with DSL long-term, but I hooked up cable internet for a month, and then disconnected it once DSL was in place. There was no delay and the transition was seamless, aside from an extra $30 I had to pay due to the overlapping days of service.

Other Suggestions?
Any suggestions from readers who’ve had a good or bad moving experience?

[tags]technology, moving, relocation, programming[/tags]

I write this post with mixed emotions. I acquired DotNetInvoice (an asp.net billing system) 15 months ago, fixed loads of bugs, added 50+ features, provided support, turned the customer base around (they were close to mutiny), and grew revenue by 6x. This program has become part of me as much as any code you work with for over a year. My intent was to turn it into a full-time Micro-ISV, but it appears that life has other plans.

I’ve come to realize over the past year that the time I’ve spent developing and supporting DotNetInvoice (DNI) has virtually replaced the time I used to spend working on my blog. Long-time readers will notice that my posting frequency dropped pretty substantially at the start of 2007 (due to my acquisition of DNI).

Debating this internally for the past several months has forced me to evaluate my goals and plans for the future. Through this I’ve decided to invest more time into growing this blog, and into an opportunity that I’ve been chasing for years (more to come later)…all of this means I have to make sacrifices to create room in my life.

So I’m selling DotNetInvoice.

Own Your Own Micro-ISV
Those who know me personally know I am not a fan of marketing language (nor am I good at writing it). So believe me when I say:

If you’re a .NET developer and dream of owning a Micro-ISV, this is a rare opportunity.

DotNetInvoice is a mature product with a substantial customer base, recurring revenue through support contracts, a high price point ($295), existing sales channels and partnerships, a highly tuned Google Adwords campaign, an existing sales site with 1000+ monthly visitors, #1 ranking in Google for many key terms, a monopoly in its niche, and everything in place to continue sales growth.

DotNetInvoice is a web-based application written in ASP.NET (VB.NET) 2.0/3.5 and SQL 2000/2005, and heavily utilizing MS AJAX. Customers download and install DotNetInvoice on their web server or shared hosting account to perform invoicing and billing. The best way to get a feeling for the functionality of the product is to try the online demos, and take a peek at the feature list.

This sale is not going to function like a Sitepoint auction where we exchange product for money and the deal is done. I will provide you with access to the DotNetInvoice Subversion repository so you can pull down the source, including bug fixes and features added since the last release, and I will provide you with 2 months of access to my FogBugz on Demand account so you can see all of the bug fixes and feature requests implemented to date, and feature requests in the queue for future releases (most of them requested by customers), and have plenty of time to transfer them to your own tracking system.

I have invested a lot in this product, and it’s in my best interest (as a public figure in the developer community) to ensure DotNetInvoice continues to thrive.

If You Are Interested
Based on revenue, the sale price will be 5-figures ($25k-65k). If you are a serious buyer and are interested in discussing it further, please email me at rob -at- softwarebyrob dot com and I will provide you with the NDA. Once you’ve signed it I will answer all of your questions and send over every bit of detail you can imagine about the product.

[Update]: The deal has closed. I’ll be posting about it soon.

[tags]asp.net, microisv, micro isv, dotnetinvoice[/tags]

I received the following email a few weeks ago:

I graduated with an MIS degree while serving in the Military. I took some programming classes like JAVA, C++ etc… I am now back in Boston, MA and find it difficult to find employment where I can learn to become a better programmer. I don’t have the experience but I am willing to learn. Can you please provide me with some direction on what to say on my resume, to gain the experience in the civilian workforce so I can become a better programmer?

My response:

To begin, read the following posts on my blog and think seriously about following the steps I outline in each. It will take time, but I’ve been doing this for almost 10 years and can tell you from experience that they work:

Advice on How to Become a Programmer
Nailing Your Technical Interview
Self-Marketing for Software Developers

Second, check out this article on programmer resumes.

Third, there are no magic words that you can put on your resume. The key is to have a good-looking resume that’s clean, free of typos, and that highlights your strong points (your education and military experience) at the top.

The tech economy, especially in the bay area and Boston, is healthy right now, so you should have no trouble finding an entry level position as a developer, especially if you are open to learning PHP or .NET. Also, start learning PHP or .NET in your spare time – build some sample web projects to show off (put them online so you can easily forward a link). This is the most impressive thing I’ve seen from young programmers, is when they’ve built something in their spare time and taken the time to put it online. Bonus points if you build something that people are actually using.

Lastly, read software blogs. Read Joel, Eric, Paul, Jeff and Scott, and now and again you can slum it on my blog. These sites will lead you to other good blogs. The closer you are to the community the more you’ll understand what people are talking about and looking for in their hiring.

Good luck,

Rob

[tags]programming, resumes, hiring[/tags]

Many a moon ago (nearly two years), I had a funny and somewhat sad email exchange with a co-worker named Matt. We had a lot of exchanges along these lines, and in a fashion atypical of this blog I wanted to share this one.

The situation: I made a mistake on a set of Release Notes and he let me know he’d corrected it.

Me: Aaaargh. Sorry about that. Getting sloppy in my old age.

Matt: Don’t sweat it. I’ll send corrections when I come across them. If this was the only thing wrong with any release notes I get, I’d be a happy man.

Me: Thanks…but wait, you forgot the protocol:

First, you’re supposed to storm around the IT department looking for me, waving a piece of paper in your hand (not even the release notes, but it just looks good), wondering where I am. Saying things like “Where’s Rob? He’s never here! And his release notes are screwed up again! He always does this!”

Then, when you’ve made at least 2 or 3 laps around the office, sit down and send an email to me, cc-ing my boss, his boss, his boss, and the CEO explaining professionally and politely how I’ve once again screwed up the release notes.

Wasn’t this explained to you at orientation?

Matt: Ha ha. Ouch. That hits a little too close to home. Sit down here while I spin a yarn…

At the last place I worked, I tried the consulting thing. Big financial place in Pasadena. [Company name here], don’t ever work there.

I was hired as the Change Management guy, but I was not cleared to have the password to the source control server because of ‘security concerns.’ They considered the source control server a production server.

So here’s how it went: I need to change the permissions on a project. I fill out a form and send it to IT. They put a typo in the permissions file for the project, which makes the project unreadable. Everyone gets locked out of source control. IT runs around telling everyone how inept I am (same vision of a guy running around with a random piece of paper in his hand, combover flapping in the breeze.) I can’t log into the server to see the mistake but I’m smart enough to know by the error messages what happened. They roll back the changes. Tell everyone they ‘fixed’ the thing I broke. I’m forced to re-submit the same exact request again, which they get right this time.

This same kind of thing happened about every week. I’ll never again make the coin I was making there as a consultant, but I walked out on that contract a month early, with no job prospects, and did the jobless thing for a month and a half (a side effect of having low expenses, too much capital, and opportunities to play hockey in the middle of the day. Ha ha.)

I received this email the other day:

I’m looking for a software developer to build a simulator program.

Payment would be made from revenues after the product is available and producing revenues. The estimated market for this product is 100 million users with a target price of $50 per unit. After all your development costs have been covered from revenues, we would then share the proprietary rights to the product and net revenues on a 50/50 basis.

Are you interested in continuing?

My reply:

Thanks for your email.

I have one question for you: in this type of arrangement, you would be marketing and selling the product. Do you have experience marketing and selling software on the internet, and if so could you pass along links to previous successes?

I’ve developed and sold a lot of products on the web, and have learned that coming up with the idea and developing the software are two of the easier steps in the process (even though development is time intensive). Getting people to come and buy your product without spending a zillion dollars on advertising is the real challenge in this game.

If you have proven experience marketing software I would be interested in hearing more about your idea. Or, if you have a marketing plan of the steps you would take to market the product, I would be interested in seeing it. If not, you are going to have a difficult time finding a good developer to spend hundreds of hours working on a product that may never sell. Every one of the good developers I know have tens if not hundreds of ideas for software products…it’s not a lack of ideas, but a lack of time that keeps us from building and marketing them ourselves.

I look forward to hearing from you,

Rob

And you know what? He was quite cordial in his reply (an excerpt):

I don’t have any marketing experience and realize I’ll need help in that area after the product is available. Your other comments are right on.

===

Wrap Up
If you’ve never launched a product you have no way of knowing that it takes three legs to make this stool stand: the idea, the market, and the execution.

Finding a market you can afford to market to and executing the idea (including the marketing) are insanely hard.

Finding an idea is the easiest part.

This is why there are websites and blogs all over the place where people share their startup ideas with the world.

[tags]software, software consulting, product development[/tags]

In case you missed Gates VP’s comment about The Fallacy of Management on my recent post Q & A on Leaving Management for Development, I’ve re-printed it below:

===

I have a working theory that I’ve titled The Fallacy of Management.

The basic definition is that current managers would have us believe that the work they do is the very reason for project success and therefore they believe (and have convinced others) that their’s is the most important role.

The real truth is that most managers are just overhead, projects would likely self-assemble without them, especially with good devs on the job. However, companies do things like targeting management for bonuses and taking other steps to make management a “position of privilege.” The truth is, good managers don’t deliver projects on time, good programmers deliver projects on time and managers just guide the process.

The concept of “separate streams” begins to address the problem of Technical Expertise vs. Managerial Expertise. But it’s also an industry thing. “Similar” professional industries, like engineering or accounting, all have a kind of set progression chart from grunt to project manager. Most current “managers” don’t actually recognize the difference between our and the engineering field, let alone begin to address the number of engineering project managers who probably shouldn’t be there anyways.

It’s the Peter Principle + poor management + uncertain staff (like yourself at times) that allow the whole vicious cycle to keep turning. Every once in a while, people get off the cycle (like you), but right now we’re still early in the game and there are more people hopping on the bike rather than off.

In 10 years, people will know better, the industry will mature (a little) and the Technical / Managerial divide will be well-documented. There’s a trend right now that’s dividing the industry and that’s the “Great Development Houses” vs. “The Body Shops.” Expect that the former will pick up on (or has picked up on) this divide and that they’re capitalizing by hiring the right people into the right positions.

===

[Rob]: Gates makes several excellent points, and I hope he continues to flesh out this theory.

While I agree with most of what’s said above, I have to chime in that a good manager is more than overhead. I’ve worked with managers who made a real difference on our projects, including motivating and rewarding the team, removing political obstacles, and removing the crappy tasks from our plates so we could produce. While most managers could be considered dead weight, a good manager can be invaluable.

Secondly, I question whether 10 years will make a difference in the cycle of developers moving into management. This cycle has a lot to do with figuring out your strengths and desires as a professional, and I think each person needs to go down this path for themselves.

After all the writing I’ve done on the joy of coding and my two trips to management and back, a developer friend of mine has decided to get his MBA so he can go into management. I forwarded him a link to Why Good Developers are Promoted into Unhappiness and he replied:

“I hear you, but I have to experience it myself.”

I can’t argue with that.

[tags]management, programming, software development[/tags]

I’ve received several emails about my post Why Good Developers are Promoted Into Unhappiness. One reader asked some interesting questions on his quest to decide between development and management.

Here are some excerpts from our conversation:

Q: Does leaving management for coding greatly cut your salary?
Going back to coding may cut your salary, but it’s quite possible it will not. In my case, the first time I went from management to coding I was fortunate enough to move into a higher paying development position. The second time I didn’t receive additional money for my “promotion” into running a development team, so going back required no monetary sacrifice.

Obviously I was lucky, and it’s a very real possibility that leaving management could have an effect on your salary. However, I haven’t worked at a company where the development manager makes tremendously more than the highest-paid senior developers. Senior Developers in L.A. can make $125k, in the bay area they can pull $140k+. These are enterprise application developers; highly specialized developers could definitely earn more.

So the question is: how much money do you need to be happy, and is it possible to earn that while still writing code?

Q: Coders seem to be considered commodities and low level craftsman. Why would someone go back to that?
Enterprises that consider developers “commodities and low level craftsman” are doomed to have (at best) average developers working for them.

A close friend of mine works for a company that has experienced a mass exodus of developers for this very reason. The best left first, the mid-range followed. What’s left are the people who clock in 9 to 5 for the paycheck and don’t take pride in what they’re building. The company now has what they asked for: a team of low-level code jockies. The people with initiative, energy, and passion have left.

Since you don’t want to work for a company like that, how do you determine if they view developers this way? The last time I interviewed for a salaried position I brought a list of questions with me and interviewed the company as hard as they interviewed me. I also made it a point to speak to one of their developers, and asked him several questions about the working environment, hours, etc… Most developers won’t lie to you about this sort of thing.

Q: I like coding, but isn’t management a more secure job?
Not in my book – developers have hard skills. I could move to nearly any city in the country, walk in to a company, and demonstrate that I know my stuff. It’s true that the job market is wide open for great managers and coders, but not only is it easier to prove you know how to code, there are more development positions than development manager positions.

Q: Doesn’t a manager generally make significantly more than a coder?
If I posted this on my blog we’d get 50 different answers (cue you, the reader, to post your opinion in the comments). At my job with the City I managed 10 people and I made more than most of them (the few who made more than me had been there for many years).

At my next position our manager made a tad more than us (around 10%), and he received more stock. He put up with 100% more headaches than we did, so we considered ourselves ahead on the deal.

Q: I’m trying to find something I love that pays very well. I’m really exploring if there is more of a ceiling as a developer than as a manager. If there is, I need to figure out how to get above it.

One thing about this industry that I still don’t understand is no pay over 40 hours. Virtually everyone does this. My question is why and why do developers accept it? If they calculate their per hour pay against that 60 hour week, they could probably do better working as a laborer on a pipeline. Does that really make any sense?

Here’s one way to get around the salary cap and get paid for every hour you work: start your own consulting firm or become a contractor. (A quick aside on how I differentiate consultants from contractors: consultants do a lot of work away from the client’s office, and they perform more project-oriented work. Contractors tend to have a cubicle at the company’s office and often do the same tasks as salaried employees.) Either way you’re paid well to write code and are typically paid for every hour you work.

This is why I left a salary in favor of running a consulting firm – for the freedom to choose what work I do, the ability to get paid for every hour I work, to continue to code, and to make more money than a salaried employee.

Q: If you want to keep climbing the corporate ladder up into Direct or VP, don’t you have to go through a management role to get there?

Yes. If that’s your goal, then go into management.

I know of only one exception to this rule. It’s a company in New Jersey that has a technical advancement track that parallels the management advancement track. In other words, people can stay completely technical and still advance in their companies.

At this company, if you don’t want to become a manager when you’re up for a promotion there’s a technical track you can request. I don’t know the exact titles, but these “Technical Directors” are on the same level in terms of power and seniority as their management counterparts; the major difference is they don’t have anyone reporting to them. They operate relatively independently in the company, but at a very technical level. The problem with the management track is that there’s a limited number of slots, because the company needs to have people reporting to a manager. But a company can have as many technical directors as it wants because they don’t require people underneath them.

Another big advantage of technical directors is that when cutbacks come, they don’t need to worry about retaining their team sizes. As a manager if enough layoffs happen and nobody reports to you, then by default your job is unnecessary. The technical director doesn’t have this problem.

A question for you, dear reader: How have your experiences been the same or different from what’s been said above?

[tags]programming, management, salary[/tags]

I relocated from Los Angeles to Connecticut a few months ago, and a few of my geekier friends joked that I had to meet Joel Spolsky and Paul Graham before I came back to California.

Joel is in the midst of his 21-city FogBugz World Tour and one of his first stops was in New York City, where I saw him demo FogBugz 6.0 two weeks ago. In fact, in the picture at the top of Joel’s post about the session, you can barely see my head peeping out over the guy with the black shirt and white stripes on the left side. Those stinking paparazzi never leave me alone.

FogBugz 6.0
The demo went well; it wasn’t spectacular, but it was a good 40-minute overview of FogBugz’s main components: a wiki, forums, bug tracking, and scheduling. But it didn’t need a big flashy presentation – the application itself is seriously impressive.

I don’t know when FogBugz became a complete project tracking and support tool for small software shops, but it’s no longer just a bug tracker. The wiki looks really sharp – the WYSIWYG editor is completely custom, and the AJAX everywhere makes for a fantastic user experience. Joel said they spent between 2 and 3 person-years developing their AJAX library from scratch since they encountered too many issues with third party libraries.

I’ve been using FogBugz on Demand (their hosted solution) for the past several months and I hadn’t even noticed there’s a wiki (intended for writing specs and documentation), forums, group email (perfect for a support team serving external customers), and the awesome evidence-based scheduling piece.

Evidence-Based Scheduling
In evidence-based scheduling a completion date is constructed from developer estimates, but the completion date is actually a range of dates with probabilities that each date will be met. So you can look at the calendar and say “We have a 50% chance of finishing by October 31st, and a 90% chance of finishing by November 23rd.” In addition, the schedule is based on the developers’ past estimating accuracy, so the better their estimates (compared to their actual time spent), the tighter the completion timeframe. Bad estimators means a wider timeframe.

It’s the right way to handle the task of determining a completion date, and now that they’ve implemented it I’m amazed no one has done it before. Some form of evidence-based scheduling is going to find its way into every project management tool over the next few years. If you’re not happy with your bug tracking or project management application you should take another look at FogBugz.

The Wrap-Up
The capstone of the morning was during the casual Q&A session after the official meeting. Most people left quickly and I found myself in a room filled with about 10 other attendees and the entire staff of Fog Creek Software.

After talking to a couple Fog Creek developers I wound up having a 15-minute conversation with Joel about consulting vs. products, leverage, and SaaS. He’s as smart in person as he sounds in his blog, and it’s obvious he’s given a lot of thought to the issues we discussed. Having read Joel’s blog since 2000 it was cool to finally meet him face to face.

[tags]joel spolsky, fogbugz, evidence based scheduling, programming[/tags]