Despite the obvious look of shock and panic on the faces of my WePay teammates, I recently committed my first lines of production code.  Although It took over a year and a half for me to contribute to WePay’s code base, and it’s still not particularly substantive (a few lines of html on the exterior of our site), it still feels pretty darn good.

I’m not trying to become a developer. Trust me, there’s a ton of other stuff that needs to get done at WePay. I just discovered something that our site needed (and something that I really wanted because it would make my job easier), which wasn’t going to get built unless I found a way to build it.   We’ve received quite a few requests for “How To” guides, and I’ve also gotten tired of answering the same “how do I…” questions over and over again, so I built the How To section of our site. Specifically, How to Collect Money Online, How to Send Bills, How to Collect Donations, and How to Sell Tickets.

In addition to my first official commit, WePay also just hired Rasmus Lerdorf, the creator of the PHP programming language. All in all, I thought this was an appropriate time for me to reflect on the non-technical things I’ve learned about programming since founding WePay.

[Side Note: In a lot of my posts, I think I come off as a self-loathing non-Hacker, which is entirely unintentional and mostly untrue. During our summer in YCombinator, I was one of the few non-developers, and I was frequently asked: “if you don’t write code, what do you do all day?” The question annoys me for a variety of reasons, but mostly because I did a lot. I think there are abundant non-technical factors that lead to a startup’s success, and the responsibility for making those things happen tends to fall on the shoulders of the non-technical people (assuming the company has those – in our case, we did). At some point, I’ll write another post about what a non-engineer does, or should do, during the early stages of product development. In the meantime, I just discovered this post, which is pretty damn good].

So, without further ado, what I’ve learned:

1. Don’t be Helpless. As the only non-developer at WePay, it’s pretty tempting to become technically helpless. That would be a big mistake, and there were times when I’ve gotten pretty close, and it has paralyzed the company. Programmers != Technical support, and a team of developers does not an IT department make. Installing software, setting up a network, changing copy on the site, etc. is not necessarily the job of the developers (in fact, it may necessarily not be their job). I’ve seen arguments about the difference between a programmer and a hacker, and from what I understand, the difference boils down to one thing: hackers will always find a way to get something done.  If you’re a programmer, you can also be a hacker (I would argue that our programmers are), but you don’t have to be a programmer to be a hacker. One of our corporate maxims: everybody’s a hacker.
2. Almost nothing is trivial. I used to say: “this should be a pretty trivial change,” a lot more than I should have. Just because something is logical and it makes sense, does not mean that the code can easily support it. From what I can tell, nothing is more frustrating to an engineer than a non-engineer asking for something complex, and treating it as if it’s trivial.
3. The 90/10 rule. When you first start building a piece of software, you can pretty much do whatever you want because you’re not constrained by what you’ve already built. So the first 90% goes by very quickly, and you can see a ton of tangible progress. You go from nothing to a lot very quickly, and it’s exciting. The other 10% takes forever (literally forever, see #4), and it’s hard for non-engineers to see that progress being made.
4. Software is never finished. Software is like a living breathing organism. It’s never “complete”. For startups this is obvious: the application changes and morphs, it adds features and takes them away, it scales, etc. Even for non-startups, though, the software is never finished. It needs to be updated, vulnerabilities need to be patched, and bugs need to be fixed. I used to think that you build the product and then you get people to use it. As it turns out, these two things happen at the same time, from the beginning, and throughout the entire lifecycle of the company.
5. Non-engineers are not “designers” by default. It’s easy to say: “since I don’t write code, I’m in charge of designing the site and improving the user experience.” And after saying that, it’s easy to put together a bunch of wireframes and say: “make this”, then do some QA and say: “fix that.” That’s not design and it’s certainly not improving the UX. There is both an art and a science to design and UX work, which takes as much time to master as it does to master most technical skills.  I think most non-technical founders working on their first Internet company miss that point. Because you are non-techinical, does not mean you are by default an authority on design and product; in fact, it could easily mean the opposite. If you want that role, you have to work for it (more details in a later post). Edit: Just read a comment that said: “don’t automatically assume engineers can’t design!” I couldn’t agree more.
6. Don’t pretend to be more technical than you are. Especially in the Bay Area. First of all, it’s incredibly transparent (even to non-technical people), and you will lose all credibility. It also pisses off engineers. On the other hand, being honest about your technical skills, genuinely asking for help, and trying your best to contribute, is like trying your best to speak the local language in a foreign country- it’s a sign of respect and humility.

Good advice? Give WePay a try, it’s free to sign-up!