ed weissman

“My goals with programming is to create web and desktop (mac, iphone) apps if that’s relevant.” 

Then you have it backwards. You should be building, not reading. 

Slow way: Read book —> apply what you learn 

Fast way: Write code —> Get stuck —> Find a book 

I know this is not intuitive, but trust me, it works much better. We all love the feeling of cracking open a fresh new book (or pdf) and bathing ourselves in all this newfound knowledge. But this method is not very efficient. Much of what you read you will never use and much of what you need you will never read about, no matter what the book is. 

Better to pick a project and just start building it. Come up for air every once in a while and consult whatever book fills in what you need to know to build your project. True learning comes from building, not reading. This method takes the best of both worlds and gets you to your stated goal much quicker. 

“…how do I get my mojo back and get that level of technical excellence back?” 

You decouple your day job from your need for technical excellence. 

You do something on the side. Maybe a pet project. Perhaps a little service work for customers you find. Contribute to an open source project. Or best of all, start your own business.

This is what I did and it changed everything. I have never complained about the lack of stimulation of any day job I have had (well maybe just a little). Better yet, I have used to crappiness I encountered during the day to push myself to “never do that” at night. 

The day job is comprised of quality right in the middle of the bell curve and it’s good enough to pay the bills. The side work gives me a chance to push all the way out to the right hand side of the bell curve with cool stuff. 

The ultimate plan is for the side work to take over and make working on someone else’s crap during the day unnecessary. Give it a shot. 

Five minutes after winning the presidential election of 1904, Teddy Roosevelt vowed not to seek re-election in 1908. Six minutes after, he regretted what he had just said. He tried to return in 1912, but failed and regretted his hasty decision the rest of his life. 

Why do I mention this? Because whenever I feel like I’m in a difficult situation (not all that much different from yours), I promise myself not to pull a Teddy Roosevelt and do something hasty that I’ll regret forever. Neither should you. 

For what it’s worth, time is not slipping away. In spite of what you may think, 30 is not old. 

My suggestion: keep your job and stay on your path, but find a way to do it and your startup at the same time. You have to get creative. Put in a few hours on your startup before work, not after. Get rid of you TV set. Block out huge blocks of time on weekends. Use your PTO for your startup. Work from home a few days a week and squeeze in extra startup work with the time/energy you save. You get the idea. 

You’re already creative enough to build a startup. Now use that creativity to free up more time and energy to work on it. Forget about the competition and time slipping away; just do the best you can. And don’t pull a Teddy Roosevelt. 

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. 

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.- 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! 

Sometimes I think I’m living in two worlds, the customer world, where everyone is scrambling to get stuff done, and the startup world, where everyone is talking about what the customer world should be like. 

Don’t misunderstand me, though. I love the startup world. There is an underlying current of optimism that I rarely see in the customer world, where people are just too busy to see the possibilities if they hit them in the nose. Sometimes I have to grab my customers and yell, “Let’s slow down for 5 minutes and think about a better way to do this!” 

In the startup world, it’s often too easy to lose sight of the definition of success. Success is not starting a business, getting into an incubator, or securing funding. Success is satisfying paying customers over and over again. 

In the past 6 months, I’ve had 5 different customers ask me for the same thing. I described my approach to satisfying them to a startup investor acquaintance. He told me that no one would ever pay for it. Now I know I’m on to something. 

I like living in 2 worlds. It helps me maintain perspective. Sounds like it works that way for you too.

The most important lesson my mentor ever taught me: 

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.” 

A smart accountant once told me that the answer to “How much money did you make?” is always, “Who wants to know?” If it’s an investor, the answer is “A lot.” If it’s a customer, the answer is “A little.” If it’s the IRS, the answer is “None.”

Same thing here. The answer to “Who is a superstar developer?” is always, “Who wants to know?”
 
To a project manager, the programmer who hits every deadline (regardless of quality) is a superstar.

To a customer, the programmer who solves their problem quickest is a superstar.

To a business owner, the programmer who makes them the most money is a superstar.
 
To a PHB, the programmer who makes them look the best is the superstar.

To a journalist, the programmer who tells the best stories is the superstar.
 
To a junior programmer, the best mentor is the superstar.

To another programmer, the programmer they are most likely to want to go into battle with is the superstar.