1. I write software: business applications. I love what I do. I love getting something to work right the first time. I love seeing people use the software I wrote to do their jobs and run their businesses. I can't imagine doing anything else.

2. The software I have inherited in all 88 companies I have worked at has sucked. I mean really sucked. Nothing to be proud of. Nothing to want to work on. I think it's because business software is now where medicine was 100 years ago.

So I have a choice. Work on other people's crap or write my own. I have done both, but I have to write my own to be happy in this industry. If I could only work on other people's software, I think I'd rather work in a grocery store.

Starting a software business is the most direct way to do what I really want to do.

I realize that other people have different reasons; this is just one answer to your question.

Original thread:  http://news.ycombinator.com/item?id=1708413

You have to get your prospects to think that what you're offering was their idea all along.

How do you do this?

Get to know them. Spend time with them. Find out what their lives are like, what they have to go through to compete, and what makes them suffer. Jump into their pool at the deep end and learn how to swim. Walk through their warehouses, customer service departments, and general offices. Sit down at their computers and try to do their jobs. Get them talking.

Once they see that you are sincere and have something to offer, they will not be bashful. They will tell you everything you need to know to help them. This will do 2 critical things:

1. It will provide specific feedback about what you're building or have built, whether or not it makes sense for them, and what to change/fine tune/refocus. It they need it like that, chances are that many others do too. Your first prospects have unwittingly been the best focus group you could have assembled.

2. You will be offering exactly what they asked for so they will have few excuses not to buy. Do not underestimate the solid gold of this approach; it works incredibly well.

Call this good sales and marketing if you want but I never have. I just call it doing whatever it takes to help your customers. Becoming successful is a byproduct.

Original thread:  http://news.ycombinator.com/item?id=1723140

Nothing interesting about my first story: I got a boring cubicle job in a large enterprise that needed 12 programmers to do anything, blah, blah, blah. But I did do some good work for a vice president who remembered me when he moved to another company, which leads to my second story, my real story:

He brought me in to his new company to do a consulting job to answer 2 questions, "What do we have to do to get Order Entry, Shop Floor Control, and Standard Costing written and running?" and "How many programmers do I need to hire?"

They had 400 employees, were missing all of these mission critical apps, and had only 1 programmer. But he was all they ever needed. I worked with him for 3 months and he wrote all of the software needed using tools and techniques none of us had ever seen before.

He did instant analysis and design, wrote disposable apps, did rapid prototyping, stepwise refinement, and extreme programming years before anyone ever heard of these things. He never wrote the same line of code twice, writing standard functions and reusable components. If he knew he needed something twice, he wrote a parameter-driven code generator on the fly and had me collect the parameters for him. He even coded in Boolean algebra and had an engine that converted it into production source code. He threw things into production long before anyone else would, figuring it was easier to just keep reworking them instead of waiting until it was perfect.

He was a one man shop in a $150 million company. He was smart, he worked hard, he loved what he did, but most of all, he didn't know that "it couldn't be done", so he just did it.

Three months watching Dick build stuff, and I was hooked for life. I had to do it, too. And I've been doing pretty much the same thing ever since, pausing only long enough to add a few new technologies to my tool box along the way.

Sometimes I wonder what horrible cubicle I'd be wasting away in if I hadn't met Dick and saw what was really possible.

Original thread:  http://news.ycombinator.com/item?id=1709074

I've been doing this for 30 years and I'm more jazzed than ever.

Wanna know the biggest difference between you and me? I'm pulled. You're pushed. Let me explain...

I love building stuff. Nothing gives me a bigger rush than getting something working the first time (well almost nothing). But I couldn't care less about the technology. If an abacus, two tin cans on a string, or some BASIC code on a Kaypro II did the job, then that's what I'd use.

What I really care about is how my software is used. And who uses it. There's an endless stream of people who need stuff and an endless stream of problems to solve. For individuals, groups, and businesses. When I encounter a new problem to work on, I use whatever I can apply in my tool box. Sure, I have to upgrade that tool box every so often because I need more to solve my problems, not because I love the toys so much.

You sound like the opposite. You love the toys and look for places to use them.

My suggestion: Take a break from the technology and put yourself in more situations where people can share their problems. This will give real human meaning to the technology. I bet you'll be chomping at the bit to build something for someone in no time. For me, being pulled by a demand motivates much better than being pushed by a supply. Maybe it can be for you too.

Original thread:  http://news.ycombinator.com/item?id=1726641

This reminds me of 2 pieces of advice I received from 2 early mentors, both 3 words, and diametrically opposed.

1. "Scratch an itch."

2. "Find a customer."

#1 comes naturally to a hacker. I'm always building things for myself. Then I think, "If I need it, someone else probably does, too."

#2 does not come naturally at all. I have to work at it. Frankly, I'd rather build stuff than talk to people (although that has changed quite a bit over the years).

FWIW, I have found very little success with #1 (one big exception: a program generator I wrote for myself was very well received by others).

#2 has worked beautifully. Every time I have ever found and satisfied a first customer, the second, third, fourth, etc. were much easier to find and satisfy because they needed the same thing. What great advice. I wish I had listened much earlier.

Original thread:  http://news.ycombinator.com/item?id=1535646

Typical way that competent developers end up with technical debt:

1. Customer/user/consumer has a vague idea of what they need but doesn't know how to express it.

2. Developer works with customer to learn their business and understand their requirements.

3. Developer throws together a prototype to confirm that he understands the problem.

4. Customer sees that developer is on the right track. If these 9 enhancements are done, then we'll really have something.

5. Developer quickly adds 9 enhancements to prototype.

6. Customer loves it! Move it to production so we can play with it for a while.

7. While customer plays with it, developer maps out a plan to architect, refactor, and scale the prototype to be "production worthy".

8. Developer is pulled away to 5 other urgent projects.

9. Customer continues to use prototype as production software.

10. Two years later: "Who wrote this shit?"

Which quadrant does that fit into?

Original thread:  http://news.ycombinator.com/item?id=881330

We went to a client to work on Problem X. He quickly determined that solving Problem X would achieve nothing. Problem Y was the real problem, but was way outside our areas of expertise.

So what did he do? He slept 4 hours a night for the next 2 weeks studying everything he could find about Problem Y. He reviewed reports, industry literature, called experts, and talked to as many people in the company who knew anything about that subject area. Within 2 weeks, he presented a brilliant solution that no one had ever considered but was instantly understandable by their experts. (That solution included work done by us and we had a great client relationship for years.)

Later, I asked him why he tried to accomplish something so difficult with such a seemingly tiny possibility of success. I'll never forget his reply...

"I didn't know that I couldn't do it, so I did it."

Original thread:  http://news.ycombinator.com/item?id=1114531

This is interesting, the comic makes it kinda cute, but OP's conclusion is exactly the opposite of what I firmly believe. I have learned over the years that the best way to win and keep quality business is to find a way to say "YES".

Buyers of software products, like small children, hear one word more than any other: "no". "No, it can't be done." "No we don't do that." "No, if you did that it would screw up everything else." "No, that's stupid" It doesn't matter if you're right, all that matters is that you're just another person saying "no".

You differentiate yourself from others by giving the exact same answer, but with the word "yes" instead of "no".

"Yes, in order to do that, we'd also want to look at..."

"Yes, let's make it 'pop' using some of the things we bring to the table..."

"Yes, no one even thought about that, and we should now before we get any further into this thing..."

or even the extreme:

"Yes, there's a way to do that. No one has ever done that before, so now is the time for someone to be first..."

As I've told my customers many times, "The answer is always 'Yes'. You may not want to do it once you understand what it will take, but the answer is still 'yes'."

No other word has helped me more to find myself and do my best work for others.

Original thread:  http://news.ycombinator.com/item?id=976397

This reminds me of a project I worked on in a large enterprise years ago. All of their systems, believe it or not, were batch. Inventory, accounting, order processing - all data was entered into hold files, or worse, filled out with pencil and paper and turned into keypunch. All databases were updated in a large batch overnight. (Today, it's hard to believe anyone ever did that.)

Our project was to migrate all apps to a new real time package. They spent millions of dollars and when it was all done, the controller complained, "Who decided that we needed real time Accounts Payable? Why would we ever want to pay our bills faster?"

No one had ever asked that question before. No one even thought about it. We had spent $1 million on a module nobody wanted because IT decided it. Eventually he added procedures to continue to fill out all accounts payable transactions with pencil and paper and enter them into the on-line system at the end of the day. What a waste.

Same argument here. Some things you want faster. And you're willing to pay for them, one way or the other. But other things should just stay the way the are.

Some things never change: you actually have to think about your apps before you implement them.

Original thread:  http://news.ycombinator.com/item?id=919161

Don't ever do this. Just a few reasons...

1. You say "during the application process". Have you even met the hiring manager at this point? Worse yet, have you met anyone or are you just stuck in some automated process? Never forget that employment application is a two way street; you're evaluating them as much as they're evaluating you. They haven't earned the right to see your code yet.

2. This approach should be a red flag to any applicant. They want to see old code to evaluate you when they are 64 betters ways to do that? Something's fishy here - someone has no idea what they're doing.

3. Do not allow anyone to read your code out of context. You need to be there to explain the background, motivation, approach, and answer any questions. Cutting and pasting preempts yourself. Bring hard copy along only after the process has progressed far enough.

4. Only bad things can happen. This is like being the first the mention a number - you can't win. If someone wanted to hook up with you but asked for a dirty underwear sample first, would you give one? This is the same thing.

5. If your code is proprietary, who knows where it could end up? You may also be violating confidentiality agreements. Not worth it.

6. The employer-employee relationship is a never ending tension. You will always be "negotiating" money and working conditions, whether you realize it or not. Giving in to such an unreasonable request so early in your relationship marks you as a chump. You may never recover the equal footing you need (and deserve) in the ongoing relationship.

7. If they have a problem, move on. You're probably saving yourself a lot of trouble down the road.

You sound like a competent developer who should have no trouble finding a job without bending over. So don't.

[Aside: Because of this kind of thinking, I never give references before being hired. In essence, I'm telling the prospective employer, "You decide." They then have the right to rescind the offer if they don't like a reference.]

Original thread:  http://news.ycombinator.com/item?id=1683360