growing a pair

What the hell is a business guy? 8 things a “business guy” should probably be able to do.

tl;dr: too easy to say “I’m a business guy” when you don’t have any technical chops. A good business guy actually has particular competencies: (1) passion, (2) clear vision, (3) user focused mentality, (4) balanced focus and knowledge of what features make sense and why, (5) a good eye for design and UX (and what design actually means), (6) the ability to network, (7) good eyes / the ability to find utility when it’s not super apparent, (8) the desire to actually be a good person. 

—-

I find that it’s too easy to say, “Oh yeah, I do the business stuff while my partner focuses on building the product” in a startup with just two or three partners. I hear it so often that it almost sounds like a cop out. “Oh yeah, I have no technical skills to speak of, so I’m going to say I’m a business guy.” 

Some people are amazing at being a business guy and can justify it with a track record of previous ventures, but it’s tough when you’re a first timer, so it’s a very different role to play from a developer’s or a designer’s. That said, I always wonder how people judge the business guys value add to an early stage company. 

This is how I go about judging value of a business person (and note that this is how I do it; by no means is it right or wrong, but its what my encounters have taught me). A lot of this can come from a conversation: 

1) Passion:

Any business guy that doesn’t have a personal connection to the work he’s doing won’t do it nearly as well as someone who does. That’s one of the big reasons I think ideas are worth sharing with other people. Unless someone actually cares for what you’re working on enough to dedicate a huge chunk of time to it every single day, chances are they won’t steal it, and even if they do, they won’t do it as well as the next smart guy that actually cares. I’ve had a lot of sweet ideas for projects that were cool, but…they didn’t maintain as much relevance to my life as what I’m working on now. Because of that, my interest in them only lasted so long. The better of those ideas fell in the realm of publishing, annotating, food delivery, conference efficiency, and location-specific communication. None of those were things were connected to my lifestyle enough for me to pursue, so I didn’t have the founder-market fit needed. 

2) Vision:

A vague characteristic. This ties into the importance of having a definable goal. What I think is really important is that the business guy can paint a vision of the world with the product he’s creating that is a better one for the stakeholders of the product than the present world. It’s also important to realize how every single piece of the puzzle fits into the achievement of that vision. Vision is not just for the overall purpose of the company and product, but also for the team members to have a full grasp on the importance of their work. Being a team member needs to be fulfilling.

This might be a peeve of mine, but I need to hear that presentation of vision without jargon or buzz words. I’m not a fan of “disrupt,” “revolutionize,” or other words in that family. I like defined explanations of how improvements are made. Improvement is a really unsexy word, but it makes a lot of sense. Who cares if an industry is being disrupted if it’s not being improved?

3) User focused mentality:

The business guy is too commonly also known as the idea guy. I think that’s dumb. If you have a brain, you have ideas. If you’re a good business guy, you’ll ensure your ideas are geared towards the net happiness of your users. Your users make your product what it is. The least you could do is make them as happy as they could possibly be as a result of your work. As Tony Hsieh (Zappos) says, a business guy needs to deliver happiness. Ideas are nice, but unless the elements of that idea are making the users happier, why would you pursue them? That ability to prioritize and keep those considerations…considered, is key.

4) Balanced focus:

This is something I picked up in working with Mike K. of  Skillshare for a project I contributed to for them. Mike made it clear not to go overboard with features and things you could do. It’s easy to okay a shit ton of “cool” features. You know what’s not easy? Eliminating 99% of those potential features, focusing on what will yield the maximum happiness among your users. For more on this, see Mike’s post, as he’ll say it better than I ever could.

5) A good eye for design and UX:

Now this isn’t a key requirement. I know a lot of business guys who don’t know the first thing about fine details or beautiful design. You don’t need a degree in user interaction, but you do need to understand the creation of a fine experience. 

I know why I like Dropbox as a solution much more than Google Docs, why I’m using GMail over Windows Live, why I use Twitter over a news site or RSS feed, why I use a Mac over a PC, why I use Quicksilver over Spotlight, why I use Rdio over Spotify and why I use Chrome over Firefox. I’m also familiar with why some may disagree with my preferences and why certain experiences that I prefer don’t align with their preferences. 

It’s important to know what user you’re catering to and ensure that you’re cognizant of what would get them to hit the X button versus what would get them to stay on your site. It took me weeks before I could finally figure out how to get my users to the functionality they wanted in two clicks or less on their first use of Alternote. It took a lot of creative thinking, but I know a third click could lead to unneeded churn.

6) Networking ability:

There are a lot of people that help a startup reach success. It’s not the founders. It’s the 

•  customers who used your product, 
•  the journalists that got your name out when you needed them, 
•  the friendly entrepreneurs and investors that dropped critical advice, 
•  the pre-product users that explained why they didn’t like the product concept and why they did, 
• the friends that decided to help out in any way they could - reviewing site content, marketing pitches, potential UXs, etc.,
• the people that got your recruiting emails and whatnot out so that you found the right person for your team, 
• the technical people that were busy with their own products but explained to you, the partner-less business guy, what stack would probably work best for your product, what languages would be optimal to achieve your desired UX, etc. 

Those people don’t magically show up. It takes a boat load of emailing, tweeting, blog commenting, and coffee meetings. I have spent full days emailing people to schedule meetings and get some critical feedback, and without that, I wouldn’t have the vision or product concept I do now. You need to give people a damn good reason they should talk to you. Part of networking involves knowing what value you bring to the table.

7) Good eyes:

I don’t mean literally. Rather - and I don’t mean this in a reducing-humans-kinda-way - it’s extremely valuable to see where others could help you. Too often, I see people let good opportunities slip because they didn’t quite realize how certain people could help them (and, even more important, how they could help those people). When you’re working on formulating your idea and aren’t really thinking about the design but you meet a designer in a coffee shop who happens to be extremely friendly, it’s usually good to help them however you can and develop a strong relationship so that when you need help tweaking a font on InDesign and don’t know the first thing about how to do that, they’re there for you. That said, always focus on near-term actionable goals, but be able to zoom out and realize how different people you meet could be helpful could make all the difference. That’s not something everyone can do very well.

8) A desire to be good:

It’s easy to be on the lookout for yourself and focus on just your product and make yourself great and all that jazz. It’s not NEARLY as easy to help people along the way. I think the most successful business guys are the ones who genuinely want others to succeed and will help them make that happen. I know this is the shortest paragraph here, but it’s easily one of the most important.

There’s a lot to being a good business guy, and my list is very biased to what I’m familiar with. I am, by no means, a guru or someone who ever really knows what he’s talking about (if that’s what you’re looking for, go some other place, but what I do know is that being a good business guy isn’t something everyone can do, and there needs to be some sort of representation of someone’s abilities for us non-technical folk. Starting some cool stuff that isn’t necessarily a business could help (psst, this is what I did last summer). 

Watch and learn

I’ve been working with two awesome technical guys recently, and being kept in the loop of their debates on the best implementation of somewhat complicated functionality is absolutely awesome. I can rarely contribute anything of value to these conversations, but just reading them closely is valuable in of itself.

Objects and Arrays

got lazy in the midst of the hurricane, so instead of trying to turn my blog notes into a well-written post, i’ll scrap the formalities and post the notes that I had that I intended on turning into a blog later. 

after the next chapter of JS, I’ll be running through the HTML5/CSS3 tutorials of http://codeschool.com (thanks to my man [and crazy awesome Thiel Fellow] Ben Yu for the reference)

things I learned / notes I had on chapter 4

# how to create an array; it’s cool that things are tying together with previous chapters. In this chapter, that happened when we started using loops and for() methods to create arrays. We also skimmed upon how to take lots of information, parse it for a particular string, and isolate that string and put it into an array for comparison purposes. 

side note: using the word ‘parse’ makes me feel a lot smarter than I was a few days ago. It’s always been one of those words that held a very “only real programmers say shit like that” association. I know it’s not super complicated, but just…sharing.

# also went through how to push values into an array and pop them out. I’m starting to make connections between conversations I’m having about Alternote with more technical folks. I might be totally off on this, but I’m guessing that push updates on a real time service are adding values to more complex arrays that sort and style the information in a way that’s defined by other html/css elements? I might be completely off, but I’m just venturing a guess.

# learned how to find specific characters in an input to pick out desired sections using charAt() methods and slice() methods. I like how the Eloquent JS book goes through the inefficient methods AND the efficient methods of going about achieving certain goals. I think it’s really important, in understanding a process, to understand the simpler way of going about achieving the same goal. Helps me develop respect for what’s going on. 

# also realized how important it is to pay close attention to what the problem you’re trying to solve actually is. Obviously, when you’re building your own product, you’re the one outlining the problems. In my case, I was doing an example that asked me to product a boolean (true/false) output depending on if the first of two strings started with the letters of the second string. I was slightly confused because I wasn’t sure how much of the second string was supposed to match to yield a true output. Because of that, I just assumed if the first letter matched between the two strings, I’d get a output of true.

After opening up the solution, I found that the prompt was asking for a true/false output based on if the first string began with ALL the characters of the second output. The example used (“rotation”, “rot”), which made it pretty clear to me. Long ass explanation for something simple, but the point is, stay focused and be meticulous. It’ll help you do things right.

# I can’t stress enough how important it is not to dwell on things you can’t figure out immediately. It’s hugely discouraging and detrimental to constant progress. If you could get through the whole chapter once in 2 hours vs. 4 hours if you dwelled on all your issues, chances are you’d be more excited to get on to the next chapter with zeal. Call it a reckless approach that doesn’t do justice to the information, but when you’re a noob like me, you’ve gotta gain a reasonable surface layer understanding and appreciation for the content. 

# this chapter began to get a little confusing because, as I was going through an extended example of parsing emails for information to turn that information into an array that we needed to create, we were creating functions that did little steps of the final solution the entire time. Something I think the chapter didn’t make entirely clear was that the console was internalizing specific functions the entire time, so that when a later script called for a function, it would work. However, if I refreshed the page and didn’t run those functions earlier on, the scripts would return errors. That wasn’t explained anywhere, and made it semi-confusing when I was trying to figure out how functions were being used in what I thought were independent scripts. 

# this gets super rough when one solution is calling for 6-7 functions that we made earlier in the chapter, as I wanted to ensure that I understand every detail of what was going on. Because of that, I always had to go back to recall each function before confirming that my assumptions about what was happening in the script was correct. 

# It’s so crucial to type out code. Writing stuff out will improve your coding skills tenfold. It’s like practicing cursive when you were a kid. Unless you write it, you won’t actually…learn how to do it. I say this because it’s easy to read the chapter without actually trying to type what you see. 

# Another good point the book makes is that there are often libraries of values already written somewhere, especially for more common functions like finding the sum of a range of values, finding the values of exponents, rounding a value, etc.. The book makes you constantly figure out functions to get the programs to perform these operations for you, but later tells you about a whole array of operations you could conduct under the object name “Math.” Math has a ton of operations you could conduct within it, but 

this text is an introduction, not a reference. References are what you look at when you suspect something exists in the language, but need to find out what it is called or how it worked exactly.

[JS] Functions and Codecademy

This chapter focused on functions. This was a relatively simple chapter that I got through pretty quickly. That’s not to say I’m a master of functions, but as far as understanding the concepts goes, I think I got it pretty well. 

I met with a professor at Penn earlier this week to talk about alternate (the product that I’m working on / incentivized me to understand programming better), and he made a good point of how all students learn by analogy. It’s rare for students to learn without connecting the content to something they already understand. 

In this circumstance, it’s really simple to connect functions to all the math classes you’ve taken in high school. One of my professors loved getting us to think out of the box, and in so doing, she had us create functions of our own. For example, we could create some function, x|y, that could equal 2x + y - x^y. In JS, you have to define functions the same way (except, obviously, defining those functions gets a little complicated when you’re writing them in code.) Fortunately, though, once you understand what the functions are representing conceptually, writing them makes a lot more sense. 

A few things I’ve been confused about are the difference between show() and return(), methods by which people write more complicated functions within functions or things of the like from scratch. I’m understanding the code, and with guidance, it’s making significant sense, but it’s tough to fathom writing this stuff from scratch. I’m guessing that’s why most of the programmers I know love open source code and use Quora/Stack Overflow to build their products. 

Another thing I found really useful was http://codecademy.com. Anyone reading this blog has almost undoubtedly already heard of them. Right now, Codecademy only has a few lessons of JS up, but in a very short time, I went through a lot of action items. I think this is an awesome start to get programming for a noob, particularly because it jumps straight into lessons instead of dwelling too much on theory. 

I definitely think learning theory is important, but it’s easy to start learning theory, get bored, and let the entire learning process go. Codecademy gets you straight into producing some programs (well, kinda) and laying the groundwork of some of the basic functions you’d be using in JS. It’s definitely a great start, and I’d probably start with that before even getting into Eloquent Javascript.

A tip I would definitely give to anyone starting to learn how to code is to not dwell too much on a particular exercise. As I move forward, I realize that it’s discouraging when you can’t work your way through an exercise. Letting yourself get stuck is dumb. Try working through it, but let yourself just look at the answer, copy it character for character in your own console, and understand what exactly is happening, then just go on. Getting stuck will just discourage you from continuing the learning process.

Day 2 - 4 of Eloquent Javascript

Full disclosure: Thursday was my birthday, Friday was full of meetings (with developers, so not completely unrelated), and I was in Boston over the weekend. I did, however, spend my entire car ride to and from Boston running through values, variables, and control flows in Javascript. That said, I have neglected Ruby a bit, but I’ll be back on that after this blog post. 

———

Variables, however easy they may seem, are a pain in the ass. I think this happens to be the case with my relationship with most things in programming. They seem so easy on the surface. Then you get close to them and they bite you in the leg. Funny enough, that happened on my birthday with a dog that looked like Lassie. Then I got bit in the leg. That was PLEASANT. 

I learned about numeric values, which was reasonably simple. Then started focusing on strings, which are basically variables with text values. That got a little trickier, especially because I needed to understand escape operators (I think that’s what they’re called), which are essentially backslashes you use in conjunction with other inputs to indicate new lines, tabs, quotation marks, etc. in a string value (e.g. http://cl.ly/9Jco)

Learning about different operators was also really helpful when working with boolean values that indicated truth/fallacy of different statements. They get trickier to remember as you get to == (equals) and === (equals precisely; because ‘undefined,’ 0, and “” are == to each other, but not === to each other), && and || are also tricky to use when you’re creating a program from scratch. 

What got the most tricky for me in this chapter was redefining values by using the same variable name. That is to say, if you define var Debt = 50 and later go on to say that Debt = Debt - 25, you now make Debt = 25, but unless you have a good vision of what’s going on in your program, that can get boggling (not quite in that example, but as the programs get bigger). 

What I noticed more than anything is that programs are MUCH easier to understand than they are to build. I guess that’s true of any work. You can read Dickens but not write like him. As I started getting into exercises in the chapter, particularly where I had to define loops, their beginnings, ends, and constraints on them to produce a very specific output, it was totally logical to me when I went through examples of loops. The second they gave me a situation and I had to write the loop from scratch, it got super confusing. I would be staring at my computer writing totally dumb arguments in the JS Console for a good 20-30 minutes to figure out how to get the output of 2^10 or how to draw a triangle of number signs. 

On the whole, understanding loops, variables, and whatnot is critical to actually getting things working in JS. Particularly cool was actually seeing stuff that I’m used to seeing on the web work on the browser (like creating a prompt screen that asked me for an answer and giving me responses based on my answer), but I know this is just the beginning. There are another 13 chapters of this JS book, and if understanding just the first two chapters is exciting, I can’t wait to see what the next 13 have in store :).

Again, sorry for being MIA (to my 0.5 readers), but I’m going to be more accountable moving forward.

Day 1 of Eloquent Javascript

Haverbeke takes a pretty different approach to teaching programming. He spends the first chapter (of 15) explaining the history of programming and what exactly programs are: 

A program is many things. It is a piece of text typed by a programmer, it is the directing force that makes the computer do what it does, it is data in the computer’s memory, yet it controls the actions performed on this same memory. Analogies that try to compare programs to objects we are familiar with tend to fall short, but a superficially fitting one is that of a machine. The gears of a mechanical watch fit together ingeniously, and if the watchmaker was any good, it will accurately show the time for many years. The elements of a program fit together in a similar way, and if the programmer knows what he is doing, the program will run without crashing.

He goes on to teach how code has evolved from 0s and 1s to operations like what we have in JavaScript (commands calling for specific actions) to even more advanced JS that has grown with its use to include specific operations (i.e. print(sum(range(1, 10))) calls for an output that is equal to the sum of all numbers from 1 to 10. Pretty self explanatory, but that’s not at all what that code would have looked like five or ten years ago. 

I have a good feeling a lot of this book will be significantly more theoretical, but that’s okay, as I should understand that as well. I’ll be honest in saying that I gave this book literally 45 min of attention to this point (was at an event from 8am - 3pm and was busy with some other work until now), but I wanted to make sure I got a blog post out. I’ll probably spend another 2 hours or so on it later in the night, but I’ll include lessons learned from that in tomorrow afternoon’s post. 

Also - I have a pretty long (1800 word) post about how to assess the value of a business guy in an early stage startup (as we don’t have portfolio of weekend hack projects or designs, so it’s harder to judge). If you wouldn’t mind, I’d love it if you could let me know how I should post that, as I don’t think it would be too valuable for me to post all 1800 words at once. It’s broken down into 9 criteria, so I could split it nicely if that’d be best. Tweet me and let me know what you think would be best.

Day 1 [Ruby]: How I finally got started

tl;dr - starting with Zed Shaw’s book on Ruby and Marijn Haverbeke’s Eloquent Javascript. Acknowledged that a programmer has nothing to learn here unless they’re looking for laughs. Learned some basics of Ruby. Got a little bit hooked, and am really excited for day 1 of JS learning tmrw.

—-

The purpose of this blog isn’t to teach anyone anything. Anyone who knows the least bit about code will probably laugh at this blog because everything I’m going to write is totally simple, but it’s all revolutionary to me.

One of the biggest hurdles in getting started (besides getting started in of itself) is the idea of what language to learn. Where should I even start? I let that stop me for a while, thinking, “Well if no one tells me what the best thing to start with is, then I might as well just wait.”

That’s dumb.

I had a folder in my Bookmarks with over 10 different “Getting started with programming” guides before I finally decided to buckle down and start with Learn Ruby the Hard Way, by Zed A. Shaw. I haven’t started the other guide yet, but I think I’m going to alternate days between Ruby and Javascript. This is particularly because what I’m trying to build with alternote is really, really Javascript heavy. I found this apparently great book called Eloquent Javascript. It’s an interactive online book that you can download to your computer, making it super convenient to practice and learn.

With these two as my guides, I began. 

Day 1 of Ruby, I got through the first 13 exercises (of 52) of the book. It took me about 4-5 hours to do this because I was really focusing on the details of why certain syntax was working the way it did. I was also gaining familiarity with Terminal (which, by the way, is AWESOME. I’m a big user of Quicksilver, and I rarely use the mouse for anything, so Terminal was magical to me.)

What’d I learn? I learned what a string was, how to use Terminal to execute Ruby functions, how to do math using Ruby, what the difference between puts and print was, how to read syntax errors, how to add comments to code, define variables, how to call on variables, and how to start using escape sequences. I also started playing around with gets and chomp methods to allow for human input into functions, and I learned (conceptually) what a library was. 

To be honest, playing around with the exercises of Zed Shaw’s book is addictive. I’m excited to play with more Ruby stuff on Thursday, but tomorrow, I’m going to start working with Eloquent Javascript.

Facing fears

tl;dr - I love how tech changes the way people communicate. Always been an idea guy. Decided to execute and make something happen. Worked two months preproduct to earn a technical partner and learn how to respect their work. Realized finding a partner is harder than I anticipated. Been scared of code for years. Finally growing a pair and starting. This is my journey. 

—-

I have always been fascinated by how web technologies were changing the way we communicate, and I always thought the potential to bringing new modes of communication to new spaces was incredible. 

Over the last year, I came up with more ideas for viable projects to contribute to this revolution than I could count. The thing is, I didn’t know how to write code. Because I didn’t know how to build what I needed to for those ideas, I lost the fuel to create something amazing. Instead of learning how to build these solutions, I decided to let my fear of something totally foreign to me stop me.

In May, I finally decided to stop screwing around and make something happen. I spent two months developing a business idea called alternote. In short, it’s a social note taking platform for the classroom, aimed at solving the issue of passive learning environments by making it easy to share thoughts, ask questions and create discussions around course content in real time.

Working around the clock, every single day on this project, there was still a TON to do before writing a single line of code. So I did a lot of that. I designed the product, worked on an outreach strategy, worked on the position, conducted user interviews and customer development, and did everything I could to eventually earn a technical cofounder. I never wanted to be “that business guy” that seemingly brought little to the table, and I wanted to develop a good respect for what a technical partner would have to do. 

About 2-3 weeks ago, I felt really comfortable to start approaching technical folks to start discussing the product concept, learning about how this would actually be built, and feeling out others’ interest levels to see if its something they may want to partner on. I quickly realized that, despite all the work I did to earn a cofounder, not many of them are available. Then I met with Nick, a YC alum building Hackruiter, and he made me realize the perfect cofounder won’t just show up the day I decide I’m ready for one. 

The marginal returns on my preproduct work, though, were becoming limited without a partner, as no product was actually being built. I did, however, have beautiful mockups with the user flow mapped out and a great network of students and professors who knew what I was doing and would be ready to be tapped the second the product was ready.

That said, I have a month before school starts. What am I doing now - besides meeting every smart tech guy I know and continuing to get feedback from every professor and student I can, that is? I’m finally facing this fear of code and learning how to build something. 

I don’t intend on being an amazing hacker, being the technical lead on any project, or anything like that. I intend on learning how web apps are build to gain a better appreciation for the work of a developer. I love being a business guy. I create visions, paint pictures, I talk to people, I pitch hard, and I like exciting people. I know I can do all of that better, however, if I understood what the hell was happening behind the browser. 

This should be fun. 

p.s. my writing isn’t usually this long-winded. I just had trouble figuring out how to convey this.