ed weissman

I had a friend in college (I’ll call John) who would shoot hoops, play golf, or play table tennis with anyone at any time. But he would never play anything else. He wouldn’t play touch football, softball, bridge, or even shoot a game of pool. I could never understand it until I finally figured it out: he wouldn’t play anything unless he knew that he would win. How sad, I thought. 

I just realized (to my horror) that years later, I am just like him. I don’t push boundaries like I used to. I don’t call on that extra customer, volunteer for that project, or apply to programs like yc if I think there is any chance I won’t win. There’s always a reason: the software is missing too much, the demo sucks, there are 14 other things that have to be done first,… You get the picture. 

I never thought of this as “fear of failure”. I just got so used to succeeding in everything I did that I didn’t want to do anything else where I didn’t succeed. I became John without even realizing it. 

I’ve got to change this stinkin’ thinkin’. A good failure would probably do me good. Or maybe I should just try something I would have never imagined a month ago. 

“If you’re capable of writing the best web framework in the world in your spare time, chances are you can also create a business at the same time.” 

Don’t make the mistake of underestimating yourself. 

I’m not suggesting that you’ll go out and write Rails in 3 weekends. What I am suggesting is that the more I meet “famous” hackers and the more I meet people from this community (online and offline), the more I realize that there’s not really all that much that separates us. 

Lot’s of people are obviously brilliant. And even for those who are a little less brilliant, brilliance is only one part of the equation. Work habits, determination, perseverence, passion, and maybe most of all, belief, are just as important. Don’t sell yourself short. 

I have no idea if I am as brilliant as others. Odds are against me. But he inspires me to achieve things just as cool as theirs. And I just know that I can. I suspect most people can too. 

Enterprise software sucks. 

We don’t talk about it much, but think about it. Every man-made object you encounter every day was manufactured somewhere. And moved, more than once. Now add in all the sales, marketing, customer service, operations, accounting, finance, human resources, etc., needed to support that manufacturing and distribution. Next, add financial markets, healthcare, energy, entertainment, etc., and you have tons of stuff.

But you don’t see it and rarely think about it. Kinda like most of the iceberg being underwater. 

And all of this needs software. And most of what they have sucks. I mean really sucks. Enterprise software is so bad that there are multi-billion dollar industries devoted to consulting on how to use it, how to share it, and how to store it in data warehouses and harvest it. It’s so bad that lots of people have to dump the data out of their enterprise systems and into Microsoft Excel just to get anything done. 

When Willie Sutton was asked why he robbed banks, he said because that’s where the money is. 

What banks were in the 1930’s, enterprise IT is in the 21st century.

If you want to be famous, go be an entertainer, athlete, or politician. 

If you want to be a programmer, check your ego at the door. The two biggest roadblocks to success in programming are incompetence and attitude. BigEgo = BadAttitude. 

I measure my success not in fame, but in the value gained by those who use my software, and the value gained by those they serve, and so on, and so on. I don’t know them and they don’t know me, but I’d like to think the world’s a better place because of all the ones and zeroes I’ve arranged. They are the stars and that’s good enough for me. 

1. Find someone who needs something.

2. Start building it.

3. Trust that when you need to learn something, you will.

The education you will receive this way will be way better than any formal education for multiple reasons.

First, you will automatically triage your lessons; you will learn what you need, not what someone else (who probably doesn’t know) thinks you need. Second, almost all the “data” you will need in this education is easily available and free. Third, for the education you need from other people, you will begin building a network you’ll need anyway. And finally, this is exactly what you’ll have to do “whether or not you get any more formal education”, so just skip the unnecessary step and get on with on. From your own self description, you already have way more formal education than you need.

This may not seem intuitive, but believe me, this is the way things get done in the real world of software development. At this point, the cream rises to the challenge regardless of education. Save your money for living expenses and start-up expenses. You’ll probably need it. Best wishes!

“1.- We’re always wrong.” 

SometimesWereWrong + SometimesWereRight != “We’re always wrong” 

“2.- If something can break, it will break.” 

Good thing this isn’t true. I’m am continually amazed that some of the crap I have to maintain ever ran in the first place, much less that it continues to run. But it does. Sometimes for years without ever breaking. I call it “dodging the raindrops”. 

“3.- All code is crap.” 

Whoever said this must have never seen really magnificent code for him to say this. What a shame. It’s out there. 

“4.- There is always a bug.” 

False. The first step in writing bug-free code is believing that it’s possible. 

“5.- The most important thing is the client.” 

Lots of things are important, but it’s hard to argue with this one. 

“6.- Design on paper doesn’t work.” 

Sure it can. Just because it usually doesn’t work doesn’t mean that it can’t. I prefer prototyping, but blueprinting can be effective too.

 “7.- Less is more.” 

Generally, yes. That’s what great design and refactoring are for. But there are counterexamples to this. 

“8.- Coding is only 20% of what we do.” 

If you actually believe this, then you’re not spending enough time coding. I’d say more like 50 to 80%. 

“9.- The customer doesn’t know what he/she wants NEVER!.”

False. The customer often knows “exactly” what he/she wants, but may have trouble communicating. That’s when you expert analysis and prototyping skills come in handy.

“10.- Someone has done it before.” 

Similar to #4, the first step in inventing something new is believing it’s possible. Lots of stuff that needs to be done hasn’t been done for all kinds of reasons. Maybe no one thought it was possible or no one has understood its potential. But we know better. 

“Bonus: Hey! Our job is cool!” 

Yes! I agree! 

Being told “how” instead of “what”. Use this API to access that database to do this process. Don’t tell me how to do something. Tell me what you want. Let me figure out how. That’s my job. 

Being told “what” instead of “why”. So you need a 4 GB csv download of the entire database every day at noon? Why? Oh, in that case, why don’t you just use which has been right at your fingertips all along. If you don’t understand the system, ask and I’ll be glad to help. But don’t make up unnecessary work for me. 

Being asked for data to put into your Excel spreadsheet which you will screw up 8 minutes later. Then you want me to fix it. Forget it. If you have a business problem, tell me about it. We will find a solution together. 

Lone rangers don’t get help. I’m not Tonto.

Calling me every 42 minutes for 3 days asking, “Is it done yet?” No, it’s not. I’ll let you know when it is and if there’s a problem, I’ll let you know about that, too. 

Not calling me for 3 weeks after a release. Either it’s working perfectly or no one’s using it. It would be nice to know which. 

Criticizing my work in a meeting in front of others without talking to me first. Big mistake. You don’t want to piss off your waiter and you don’t want to piss off your programmer. 

Meetings when a phone call would have sufficed. 

Phone calls when an email would have sufficed. 

Status meetings. Pointless. I’ll email status. Any questions, click “Reply”. 

Code walkthroughs that are more concerned with syntax than function. 

SQL SELECTs inside of iterations. Please go work at McDonald’s. 

Sarbanes-Oxley (SOX). 

“Why is it so hard to find programmers? Are people afraid of joining a start-up?”

Let’s not overlook the big differences between working at most start-ups and working at most companies:

1. Every programmer, no matter how good, is at least a little insecure. Every one of us doesn’t know “something”. Is the something you don’t know going to make or break the next project? In a start-up, there’s rarely a safety net to catch you, but in a larger company, there’s probably a better chance that someone else can help you along.

2. It takes a special mentality to work in a less certain environment. This is more a matter of personality than skill. My mentor was fearless. He used to say, “I didn’t know I couldn’t do it, so I did it.” This attitude, as much as skill, determines how well one would thrive in a start-up.

3. What happens when things go wrong? (And they will go wrong.) The ability to recover from problems in a larger company is a great asset. In a startup, it’s a necessity. I’ve met many enterprise programmers who could crank out great code between 8 and 5, but melted under the pressure of an all night emergency. They would never survive in a startup.

4. What happens if you don’t feel well or if your mind is “someplace else”? In a larger company, you could coast for a day or two (maybe more). That’s rarely an option in a start-up; time lost is time lost forever.

5. In a larger company, you can do quite well whether you have deep domain knowledge or you’re a jack of all trades. In an early start-up, you better be both.

6. Ever wonder why waterfall development refuses to die, even though it’s not as effective? Because so many of us have to have a road map in order to function. “Road map” personalities don’t fare nearly as well in roadmapless environments (many start-ups).

7. A start-up programmer must have at least a little maverick blood. If you believe everything you hear and do everything everyone else is doing, how can you differentiate yourself? In a larger company, you may not have to. In a start-up, you probably do.

8. Is there something you simply have to do? Then you probably belong in a start-up environment. It’s tough (although not impossible) to get the same opportunity in a large company.

9. Do you think the work is really cool? I know lots of good enterprise programmers, but have trouble thinking of very many who think their work is cool. They like their jobs, but work is “just a paycheck”. Not the type of people who would thrive in a start-up.

10. Do you do a happy dance whenever something works for the first time? Then you may be more
comfortable in a start-up than in a big company.

I love how everything has a fancy name now. We’ve been doing StartInTheMiddle / MinimumViableProduct / Prototyping / GetSomethingOut / StepwiseRefinement for years: 

Customer: I must have anything I want from the database without asking you. 

Me, 1 hour later: No problem, here’s your screen. 

Customer: This only does does Customers. I want to pick “any” table. 

Me, 1 hour later: No problem, now you can pick your table. 

Customer: This dumps every column. I want to pick my own. 

Me, 1 hour later: No problem. Now you can pick your columns. 

Customer: This doesn’t sort. I want it to sort. 

Me, 1 hour later: No problem. Now you can sort. 

Customer: But I want multiple sorts, some ascending, some descending. 

Me, 1 hour later: No problem. Sort any way you want. 

Customer: It dumps the whole table. I want to filter. 

Me, 1 hour later: No problem. Now you can filter. 

Customer: It only give me local columns. I want columns from other tables, too. 

Me, 5 mins later: Give me an example. 

Customer: Here. Give me these linked columns and accumulators, too. 

Me, 2 days later: OK. I figured out how to give you all this data too. 

Customer: OK. This will work. Why didn’t you do all this in the first place? 

Stepwise Refinement Method: Time to beta: 1 hour. Time to production: 3 days. 

Waterfall Method: Time to beta: not applicable. Time to production: who knows? 

Release early and often. 

Get eyeballs, then monetize. 

Bootstrap. 

Get basic version working, then add features. 

Get basic version working, then scale. 

Get basic version working, then license the technology. 

Get basic version working, then sell to enterprises. 

Get free version working, then upgrade them to premium.

Get free version working, then sell support. 

Get free version working, then sell services. 

Get free version working, then put it on your resume. 

Raise money, hire wisely. 

Be first to market. 

Be second to market. 

Wait for market to clear, then enter with second wave. 

Find your niche. 

Have the lowest price. 

Have the highest price. 

Use technology as a barrier to competition. 

Win a business plan competition. 

Get into an incubator. 

Get into a seed accelerator. 

Find an angel. 

Find a mentor. 

Crowd source fund raising. 

Get press to raise money. 

Raise money to get press. 

I think I’ll just fall back on the only thing I know:

Build something people will pay for.