ed weissman

Here’s the dirty little secret about B2B software: 

It’s not about the money. 

It’s about the risk. 

I tell my customers that if they can find a free generic horizontal piece of software that provides them value without risk, then by all means, use it. 

Then I ask them to consider questions like these:

- Is the website up? 

- Is the fulfillment system up? 

- Is the phone system up? 

- Did we get that order? 

- Did that order ship? 

- Did the customer pay? 

- Did the bank get the money? 

- Did the material get received? 

- Did we make payroll? 

- Did we get the best price? 

- Where are our revenues below plan? 

- Where are our margins below plan? 

- What are our numbers for the day? Week? Month? Quarter? 

Then the killer question: “If we don’t know the answer to any of the above because of our free software then who are you going to call?” 

If you have a good answer to that question, then you may want to consider a free software alternative. Otherwise, paying for legitimate software and support is simply the price of doing business. The risk to your business and its stakeholders is simply not worth the couple of bucks saved on free software. 

I believe that there are two ways to get good at anything, “push” and “pull”.

Push: You learn from books, classes, mentors, and studying examples, then apply what you have learned.

Pull: You have a problem that you must solve, then you learn what you need, any way you can, to build the solution.

I suppose there are pros and cons of each method, and I imagine that many people here have used some of both.

For the record, I am 100% Pull. I have absolutely no formal training. It took me 2 years to find my first job and then I was thrown into the deep end. It was simultaneously frustrating and exhilarating. There were so many times I didn’t know what to do or didn’t have enough “tools” in my box. So I had to figure it out and find sources of learning. But I always did. Any when I got that first thing working and then saw my customer’s eyes light up, I was hooked.

Your CS degree may make you think that you’re a “push” learner, but may I suggest that you adopt a “pull” approach. Forget what you think you know and find a job or a project or someone who has a real need. Then build what you need. You a several advantages over me: (a) It shouldn’t take you long to find that job/demand/customer. Just keep looking. (b) You already have tools in your tool box, maybe not the right ones for the job, but you have “something”. And (c) It’s easier than ever to adopt a “pull” approach. Help is everywhere.

You may feel frustrated, but I don’t think you have a problem at all. You’re in a great (and very normal) situation. Just adjust you attitude, find something to build, and do it.

Don’t scroll down until you’re done.)

1. You push your cart through the supermarket 

a. In a pre-defined manner 

b. Randomly 

2. When watching football on TV, you focus on 

a. the quarterback 

b. the defensive linemen 

3. You drive to work 

a. the same route every day 

b. with a different route every once in a while 

4. Which card game do you prefer? 

a. bridge 

b. poker 

5. To plan for tomorrow's weather 

a. You check the TV or internet. 

b. You go outside, looking for signals. 

6. Who do you prefer? 

a. Andrew Carnegie 

b. Marie Curie 

7. You prefer 

a. your keyboard 

b. your mouse 

8. Which subject do you prefer? 

a. history 

b. literature 

9. Which would you rather do? 

a. take a walk in the woods 

b. a crossword puzzle 

10. Which is more important to you? 

a. time 

b. space 

Answer: If you tried to figure out (game) the test as you took it, you have a programmer’s aptitude. If not, you don’t, and probably don’t even understand this answer. 

I have always been a “fearless” programmer, but never realized it until recently. Here’s how:

“Fear of not knowing the best way to do things (best practices).”

The sooner you realize that there is never a best way of doing anything, the sooner you can release this silly fear. Some ways are better that others, but “any way” is better than “no way”. Just get the thing done. Later, when you refactor, you’ll have the best of all worlds: code that did the job right away, a better way of doing things, a satisfied customer, and a great learning experience.

“Fear of not using the right tools and languages.”

Give me an adjustable wrench, 2 screwdrivers, and a big hammer and I can fix just about anything. Same thing with programming. I’m too busy getting work done to learn every new tool or technique. As I’ve told many programmers over the years: “Whatever you can do, I can do in BASIC. Maybe not as pretty, but probably just as fast and just as effective.”

“Fear of errors (especially compiler errors).”
 
You’re in the wrong business. Errors are what point you in the right direction. The sooner you learn to embrace errors and use them to refine your work, the sooner you’ll become fearless (and better).
 
“Fear of schedules.”

“I see only one move ahead, but it is always the correct one.” - chess master Jose Raul Capablanca. That’s what my schedule looks like. One item. One day. Project managers can’t stand this, but then again, I get way more work done than they do.

“Fear of publicity (what will other programmers think about this code?).”

I never publish my code. Ever. Users get to give me feedback, but I don’t care what other programmers think. Sure, I learn from them, but never in the context of reviewing the code I wrote. I learn from the code of others and apply those lessons to my own work.

Just a little personal experience:

 BOSS: "There will NOT be a layoff." 

REALITY: There was a layoff.

 BOSS: "There will be no more layoffs." 

REALITY: There were more layoffs.

 BOSS: "This will be the last layoff." 

REALITY: There were more layoffs.

 BOSS: "I will be the next person laid off." 

REALITY: He wasn't. Someone else was.

 BOSS: "I am instituting 35 hrs. pay for 40 hrs. work." 

REALITY: It lasted one pay period before the layoff.

 BOSS: "The corporate jet will be the next thing to go." 

REALITY: The corporate jet was still in place after the layoff.

 BOSS: "Customer XYZ will pay their bill next week." 

REALITY: Customer XYZ never paid their bill. Layoff instead.

 BOSS: "Finish this project and we're in the clear." 

REALITY: The project was finished. Then came the layoff.

 BOSS: "Indispensable employees will be spared." 

REALITY: No one was indispensable.

 BOSS: "We made our numbers. We'll be OK." 

REALITY: The SEC and IRS disagreed. We went out of business.

 BOSS: "U.S. manufacturing is solid and protected." 

REALITY: 400 jobs shipped to Haiti within 90 days.

 BOSS: "A layoff will be the last resort." 

REALITY: Layoff + executive auto leases still in place.

 BOSS: "I will promote you next week." 

REALITY: The company newsletter reported his girlfriend getting my job.

 BOSS: "Just help me get through this and I will reward you." 

REALITY: I helped him get through it. He didn't reward me. 

Sorry to say, moral of the story:

Q: How can you tell if the boss is lying? 

A: His mouth is moving. 

In my first failed start-up, I did what is now considered standard advice and it was an utter failure (which might explain why I still question all advice, no matter how standard). 

The software was a small business system for manufacturers and distributors. I was the technical person, my co-founder was the business person. 

How we did things:

- We determined the customers' most critical requirements. 

- We built what they needed from those requirements. 

- We installed the hardware and software. 

- We got them up and running in test mode. 

- We adjusted, reworked, and went live.

What ended up happening:

- Critical features were invariably missed. I had to add them. 

- There was always some scaling issue we missed. Always. 

- Architecture had to be reworked with every install.

- My co-founder was able to sell far faster than I could build. 

- My co-founder was unable to help me build. 

- Customers became disillusioned. 

- I collapsed, vowing never to go through this again. 

What I now believe:

- Make sure your MVP is enough. 

- Beware being consumed by customer service. 

- The first two founders must be technical. 

- Your architecture must scale, even if your app doesn't. 

- Always be brutally honest with each other at all times. 

- Make sure all your failures are recoverable ones. 

- Plan for 40 hours/week. Stop working at 80. 

- Never quit. Start over, but never quit. 

Top Ways for a Company to Blow a Job Interview 

1. Make me wait in the waiting room past our appointment time. My time is as valuable as yours. 

2. Make me meet with Human Resources first. My time is as valuable as yours. 

3. Make me fill out forms. This can be done in advance. 

4. Don’t shake my hand. (I have no idea why this happens, but it does.) 

5. Begin the conversation with anything other than, “Hello,” or “Nice to meet you.” Again, why would the first words of any interview be, “How would you handle mass emails?” 

6. Don’t give me your business card. As a job applicant, I’m just as important as any vendor or business associate. This is a good chance to demonstate it. 

7. Criticize my job history. Here is the reason I’ve had 9 jobs in the past 5 years: Because there were poorly run businesses, assholes, and mismatches. The reason I’m here is to try to fix all that. Move along. 

8. Expect me to have 10 years experience in every possible technology your entire enterprise uses. I will learn what I need. Promise. 

9. Ask me how many gas stations are in the United States, how many ping pong balls fit in a bus, or why manhole covers are round. Frankly, I don’t care. There, now you have the results for both your I.Q. test and your personality test. 

10. Don’t follow up. I know that I’m probably not the only person your interviewing and this may take some time. Extend me the same courtesy you would the window washers. Don’t make me email you every week. 

Small business owners are always concerned about revenue. Always. They know there are 2 ways to solve almost any small business problem: (a) Work like hell on 42 different things, or (b) Add sales. Find a way to show them new orders and you will get their attention. 

Small business owners often feel like they must defeat someone else in order to win (whether it’s true or not). 

Always leave a little wiggle room in price or terms so that they can enjoy the feeling of a victorious negotiation. 

Small business owners appreciate simplicity. Confuse them with technology or jargon and they will move on to something they understand better. 

Small business owners understand the importance of other people in their business. Show them that you do too and that will go a long way toward your credibility. 

Every small business owner has a few pet peeves that drive them nuts. It might be the outrageous cost of something or how difficult it is to get something done. Discover and solve these things and you could go far. 

Small business owners are especially sensitive to bullshit. If you’re a poser, save yourself the trouble and move along. 

Small business owners often have a bigger “real mission” for being in business. Find out what that is and help them achieve it. They will really appreciate you for that.

The old town drunk died. His two sons, the bank president and the new town drunk were at his funeral. An onlooker, surprised at how different the two sons were, asked each one how he turned out the way he did. 

The bank president responded, “With a father like that, how else could I turn out?” 

The new town drunk responded, “With a father like that, how else could I turn out?” 

For what it’s worth, I am like the bank president. I have no idea why. All I know is that no matter whatever anyone ever did to me, it didn’t matter. I have no idea if someone who turned out like the new town drunk can change (although I imagine it happens all the time). All I do know is that “it is possible” for a victim to succeed and overcome all of his “darkness”. 

Try designing an enterprise production/distribution system where:

- set-ups must be minimized 

- backlog must be minimized 

- inventory must be minimized 

- trucks must be full 

- warehouse space is limited 

- deliveries must be on time, but not too early 

- sales people must have stock on hand 

- plant absorption must be maximized 

- bills must be paid on time 

- down time must be zero 

- working capital must be put to the best use 

- stockholders must be satisfied 

Say what you want about enterprise programmers, but they get stuff built that handles all of these while academicians screw around with linear algebra and OO castles for years.