MBAHacks

…master of none—pretty much sums up my foray into web development two years ago. I learned HMTL, CSS, Ruby, Rails, SASS, Git, Photoshop, Illustrator and much more. Predictably, I didn’t become a full-time developer, nor did I build the next $1B business. However, it was an invaluable—if humbling—experience that has helped me in many other ways.

Most recently, as a Product Manager at Mint, I’ve had the pleasure of working with a talented team. Roles at Mint are well defined. We have web-ops, architects, front-end engineers, back-end engineers, QA engineers, experience designers, and visual designers. My experience as a full-stack contributor helped me develop an understanding and appreciation for each of these roles. However, before I was wearing all these hats simultaneously, and doing a poor job I might add. Today, I can count on a group of professionals to execute much better than I ever could.   

So while my web development experience helped me build empathy and understanding into the effort of building a software product soup-to-nuts, ­it also helped me understand the importance of assembling a talented team. It truly does take a village.

Clearly, great teams make great products. With that in mind, I’d like to thank the talented engineers, designers and architects I’ve had the pleasure of working with over the last two years. You make great things possible. I’d especially like to thank Yutaka Hosai (back-end), Kevin Urrutia (front-end) and Ilana Eliran (design) for their help with writegreen.org. As part of an Intuit wide innovation competition, they helped me give writegreen a much needed enhancement.  Without their unique skills and talents, the writegreen app would not be what it is today. Check out their great work: writegreen.org

"Release early, release often" is an agile development philosophy emphasizing the importance of early and frequent releases in creating a strong feedback loop between developers and users. It is in this spirit that I am publicly releasing WriteGreen, my work in progress app. I'd like to spend the bulk of this post describing what I've learned about development, versus describing what WriteGreen is about. If you want to learn more about WriteGreen, you can do so at the WriteGreen.org (the website and app are currently hosted separately for technical reasons).

Each of the headings below describe one aspect or another of my experience learning web development. I could write an entire post on each of them. However, these describe my experience more succinctly.  

Linux

Halfway through my project, I switched from a Windows development environment to a Linux environment. Admittedly, Mac is the more popular environment to develop Rails applications. However, for my own personal reasons, I decided to give Linux a try.  

Linux comes in many flavors. I installed the latest version of Ubuntu, 11.10. In switching, the biggest difference for me was Linux has a more developed ecosystem for Ruby on Rails. RVM, the Ruby Version Manager, is only available for Mac and Linux and is invaluable for developing on multiple versions of Ruby or Rails. I also found the Linux terminal to be vastly superior to the Windows command line. And since most servers run on Linux, I was able to get my app up and running 10x faster on Linux vs. on Windows.       

Getting set up on a Linux was a lengthy process. I had to jump through many hoops, installing additional packages and hacking together solutions to get it to work as my main operating system on my old Dell Inspiron 1525. Still, with a little determination and a lot google searching, I was able to get it up and running to use it both as my personal computer and development environment.  

My setup

Dell Inspiron 1525, Intel Core 2.0Ghz processor with 4GB of RAM and a 500GB hard drive Operating system: Dual boot Ubuntu 11.10 on Windows Vista

My technology stack

Language: Ruby 1.9.2p290 Framework: Rails 3.1.1 Version control: Git Editor: Gedit (after switching from Windows, were I used Notepad++)  Web server: WEBrick, then Thin Hosting: Heroku

Iteration

Iteration is at the heart of software development and design. Programmers and designers alike are constantly making decisions as to what forms their projects will take, just from two different perspectives. I like to think of it as software engineering and visual engineering. As the sole programmer and designer on my project, I was frequently revisiting my work, sometimes tweaking it, and sometimes scrapping it all-together and starting from scratch. This made for a much better finished product.       

I iterated through various levels of complexity while building out my back-end and front-end. I started with the back-end, after all I need something to display. I then went through multiple iterations on both my back-end and UI. My first UI was just text output. I eventually graduated to two basic boxes with some basic CSS styling. Finally, I gave my app a facelift and created the UI it has now. However, it would be false to say I created 3 different UIs. In fact, I have been continously improving the UI over time. These three examples just give a taste of the various high level forms my UI took over time.       

Feedback

It is true that the "Release early, release often" mantra helps create a tight feedback loop between developers and users. In my experience, getting user feedback helped confirm some of my design hunches and uncovered new issues and insights to improve my app. Without such feedback I would have missed great learning opportunities.  

Bugs & Testing

There is atleast one bug that I know of within my application: the lack of form validations. If you submit a empty form or a form that contains an invalid address, the application will crash and throw an error. This is related to my implementation of the tabless models, which makes validation trickier (at least for a noob like me). 

The dream of any software developer is to write bugless code. Nonetheless, the truth is that testing and fixing bugs usually accounts for half of the software development effort. There are steps one can take (like adopting agile development practices, and using BDD and TDD) that will help minimize the quantity and severity of bugs.  My goal as a developer is to maximize the tradeoff between time spent on discovering and fixing bugs and the impact bugs have on the user experience. 

My application is simple enough that it should not have any bugs (hope to accomplish soon).  What I've learned about debugging is the importance of isolating individual components of my app. You can't fix a bug you can't identify, but knowing that a bug is present is not the same as identifying it.    

Debugging tools can also come in handy depending on your philosophy. Some Ruby purists say debugging tools are unnecessary. Others use fully fledged IDEs (Integrated Development Environments), like Rubymine, a popular Ruby IDE. I tried Rubymine but found it to slow and unwieldy on my paticular setup. It ground my system to a halt. I'm guessing that my 4GB of RAM was insufficient for Rubymine, which is known to be a memory hog.          

Cross-browser testing

Cross-browser testing is hugely important as the number of browsers and operating systems grow. In addition to the latest browsers, software needs to be testing in legacy browsers. Ask any developer about the joys of accomodating IE6 and they'll recoil in horror.   

Initially, I was frustrated that my HTML/CSS rendered differently in Firefox vs. Chrome, where I did most of my testing. I then realized that doing a CSS Reset solved most of my problems. A CSS Reset reduces browser inconsistencies in things like default line heights, margins and font sizes of headings, and so on, giving developers more control on how their site renders accross browsers. Still, even with a CSS Reset, it takes a bit of work to get the various browsers to display the same site consistently. I optimized WriteGreen for the latest versions of Chrome and Firefox.     

Learning

While I've learned a lot, I still recognize many weak spots in my understanding of Ruby and Rails. Unless you have a really good understanding of the framework, deviating from Rails conventions can cause some pain. I spent countless hours implementing a tabless model in Rails, thinking it was a superior and simpler way to implement my project, only to find it pushed my understanding of the Rails ActiveRecord, ActiveModel and ActionController modules.    

Furthermore, there is always a way to write cleaner code. To do so, it helps to have a solid understanding of typical programming structures and of the specific methods available in each language. I briefly spent some time learning Ruby before jumping right into Rails and found myself learning more Ruby as I went about developing my application. This meant I had some ugly and unyieldy code, like the following helper method:

def get_content(focus, focus_header)  max = count_variations(focus, focus_header)  counter = 1  text = ''  while counter <= max   text += ' ' + pull_entry(focus, counter, focus_header)   counter += 1  end  return text end

An experienced developer like Anton Litvinenko, co-founder of 300.mg and with whom I consulted, can turn an eight line method like that into a one liner without much thinking about it:

def get_content(focus, focus_header)   (1..count_variations(focus, focus_header)).collect{|counter| pull_entry(focus, counter, focus_header)}.join(' ').squish end

Tools

The developer community is always coming out with new tools, frameworks and extensions to make web development easier. One extension I employed on WriteGreen was SASS or SCSS.  SASS is an extension of CSS3, adding nested rules, variables, mixins, and generally making CSS styling more pleasant. Best of all it translates into valid CSS and is surprisingly easy to pick up.  HAML is another extension along the same lines, but for HTML/ERB. ERB stands for Embedded Ruby blocks. It is a templating system used to put Ruby code within an HTML file. I haven't yet tried HAML, but from what I read it creates more elegant HTML/ERB code. Elegant code = more readable code. That's huge for any developer.  

Git is another critical tool I used for development. Git is a distributed version control system built by Linus Torvalds, the same guy that created the Linux kernel. It helps you track and manage the different versions of your code base over time and across collaborators. Even in my application, where I was the sole developer, it still saved me a lot of grief to be able to revert my code base to a previous working stage or to compare to earlier code.     

Community

I've found the development community to be incredibly supportive and helpful. In addition to all the open source tools, frameworks and extension they create, (which make development easier), they also make themselves available to answer questions on platforms like Stackoverflow and Quora. This is not only a relief for a beginning developer, but a necessity. Web development is only getting more complex over time, especially as developers need to implement test driven development, version control, back-end languages, front-end code, and so much more all within one project. Having good tools, frameworks and extensions helps control and manage that complexity.  

Closing thoughts

It’s been a few months since I launched MBAHacks and the response has taken me by surprise. To date, MBAHacks.com has had ~12,000 views.  In addition, many people have subscribed and/or messaged me.  It always nice to hear from people that can relate to my message or give a word of support.  Besides the personal connections, I’ve also learned a ton.  I now have a basic, but solid understanding of the how the Ruby on Rails framework works and can build simple applications using this knowledge.  Stay tuned, I will deploying one soon!  

Let's now move on to the main focus of this post: how our own strengths can become weaknesses.  I will be using my own experience as an example.  

Strengths Become Weaknesses

Stanford GSB Professor Charles O'Reilly first exposed me to this very basic leadership tenet:

"Remarkable strengths that made a person successful can become liabilities in situations where other strengths are more important."  - Morgan McCall, High Flyers

Put differently, the traits that got me to where I am today may hold me back from where I want to be tomorrow.  In previous posts, I wrote about my decision to take the (startup and coding) plunge and about my technology immersion strategy.  In this post, I want to address the softer side of taking on challenging endeavors like launching a startup or learning to code.  

Admittedly, I feel uncomfortable discussing my strengths, even in the context of how they may hold me back.  Still, I think it is a worthwhile exercise.  After all, one of my goals in writing this blog is personal transparency.  I’d like to lower the barriers for anyone to get to know me beyond the superficial level that is possible from casual conversation alone.  

How my strengths can become weaknesses.  

There are a number of personal traits that got me to where I am today.  Determination, independence, resourcefulness and problem solving are chief among them.  These traits helped me overcome many personal and financial hardships during my upbringing.   Still, I am aware that the traits that served me well in the past, if overused, may hold me back in the future, especially as I take on bigger challenges.  Here’s how: 

Determination.  If there is a 95% chance that I will fail at something, then on average I only have to try 20 times before I succeed.  No problem.  I got that! Problem is—I’m sometimes so determined that I don’t allocate my time as efficiently as I could.  Note to self—I shouldn’t always lean on my determination to overcome obstacles, and I shouldn’t try to overcome all obstacles. Sometimes, I can go around them, or even ignore them.  This especially true with a startup, where it’s important to pick your fights.  

My mantra: Don’t let determination get in the way of prioritization.       

Independence.  It sucks to rely on external forces or parties.  They can be unreliable, expensive or difficult to find.   I say to hell with it, it’s easier just to do it myself.  And, usually it is…Except when it isn’t—Sure, it helps to be independent and resourceful early on, but to turn a startup into a company, it takes much more than sheer will and individual ability.  What’s more, since I value independence, I may hesitate to ask for help when I really should.  Note to self—As an entrepreneur, I’ll need to surround myself with people that know much more about X than I do.   That includes mentors, advisors, employees, and yes, even lawyers.  I’ll also need to ask for help more often than not.  

My mantra: It takes a village to raise a child, or…a startup.  Building a solid company is an exercise in co-creation.                   

Resourcefulness & frugality.  Growing up with modest means, I learned to make do. Fortunately, what I didn’t have in resources, I made up in resourcefulness.  Problem is—there is a fine between being resourceful/frugal and being a cheap bastard.  I sometimes cross that line. There are many things that are expensive and well worth the price.  Telling the two apart is not always easy.  Note to self—When in doubt, don’t be frugal.  Since my bias is towards being frugal, I need to counteract it.  

My mantra: While all that glistens is not gold, I’d rather be pinching Benjamins than pennies.   

Problem solving.  I’ve been a problem solver all my life.  It’s my default mode.  When faced with a problem my immediate instinct is to move towards solutions and not delve on the problem.  The thing is—being a problem solver has two main disadvantages.  First, when I default to problem solving, I lose valuable learning opportunities, both for me and for my team.  What’s more, I run the danger of creating an environment of dependence, becoming a bottle neck within my teams. Note to self—I don’t need to solve every problem.  I’d rather be a great coach then a great problem solver.  It creates a learning environment and is much more scalable for me.  

My mantra: When they are not leading, the best leaders coach, they don’t manage.  

The second disadvantage of being a problem solver is that, many times, problem solving is not what is called for (at least not right away).  Sometimes people just want to be heard.  My biggest challenges—personal and professional—usually involve a large emotional component.  In both cases, jumping to solutions without addressing the emotional content is like trying to put out a fire without controlling the fuel source.  Things may cool down for a bit, only to heat up again.  Note to self—Look for the emotional content and address that before jumping to solutions.  After all, I am a big believer in getting to the root cause.  The root causes of major problems are rarely technology or resource based, they are usually people based, and thus deeply rooted in basic human emotions.   

My mantra: Cater to people, not to problems, because problems are never isolated from people.   

Wrapping up

There you have it, four strengths of mine that have the potenital to become weaknesses. It should not come as a surprise that our weaknesses can be the flipside of our strenghts.  In my opinion, the greater value lies in self-reflection.  Which of your strengths can become weaknesses, and how would you balance them? 

This week I recieved a letter from a Stanford Alum. My blog resonated with her and she wanted to hear more.  Of course, I responded, offering some questions for her to consider as she weighs her choices.  She gave me permission to publish her email below (name disguised) and my response to her below that.  I hope that some of the questions/considerations below may be helpful to others wondering whether they should learn to code and/or launch their own startup.  

Her message: ================================================

From: Gina Klein  Sent: Monday, October 17, 2011 4:39 PM To: Edward Castano Subject: MBA Hacks...the rest of the story???

Hi Ed,

A fellow Stanford alum here, hoping you might be willing to share more of your experience.  I recently came across your blog MBAhacks, and enjoyed your honest perspective on making your decision to "take the plunge".  If you're willing to write more about what you've done since your 10-week tech immersion, I'd love to read the story.  You mentioned that you're "comfortable with the decision now" to turn down that [six figure] [product] manager job in order to start your own business. What has made it worth it?  

I've been contemplating taking my own plunge into coding and web development.  Like you, I have a science/environmental bent and an MBA, small children, some lingering school debt, and was recently offered a significantly better position at my current employer.  But I have a dying urge to delve further into jQuery/Ruby/etc and the world of tech start-ups.  Probably my biggest hang-up is that I live in rural Oregon, in something of a one-company kind of town, and my husband has zero desire to leave the area.  I like the area too, but it just makes leaving the company feel that much riskier.  (Though perhaps in the long run less risky, since I'd be diversifying my opportunities?) 

In his 2005 commencement speech at Stanford, Steve Jobs talked about only being able to connect the dots looking backward, not forward.  From where I stand, you seem to be one of those people "on the other side" already...  any perspective you're willing to share is appreciated!

Thanks, Gina Klein  Brewster, Oregon MSME '02

My response: ================================================ Hi Gina,

Thanks for your message.  I might seem like one of those enlightened ones on the other side, but it’s never that clear.  Just because I am comfortable with my decision doesn’t mean I don’t have lingering doubts or worries.  However, at the end of the day, I can look back and see all that I’ve learned, and that makes it worthwhile, even if it means that in 9 months, I have to go back to a corporate job.  Which is to say I can only connect the dots behind me.  The future is still full of uncertainty.   

Since my ten week immersion, I’ve worked with and/or advised several startups, including: 300.mg, www.quoteroller.com, www.getcomparisons.com.  Unfortunately, this means I haven’t been on top of my coding lessons or my own startup.  On the flip side, I’ve learned tons about customer development and marketing nascent startups.   I started refocusing on my own startup this week.  Focus has been my biggest challenge.    

My problem is two-fold.  I’ve decided to both launch a startup and learn to code.  Where I am now, I would suggest to focus on one or the other, but not both in parallel.  It’s difficult enough to do one.  To do both seems herculean.  I can’t say that I am there yet.  While I am glad that I decided to learn to code, I might ultimately have to choose between coding or startup.  And that’s not a bad thing (read the first two paragraphs of my earlier post: Zero to Binary in 60 Days). 

I don’t know what is the right decision for you, but maybe I can help by asking a few questions:

GOALS:  How does this decision fit into your bigger picture (goals, dreams, family, etc.)?  If it’s something you’ve always wanted to do, and you have your family’s support, then what is stopping you? 

RUNWAY: What sort of runway do you have?   Sounds like your husband also works.  How important is it to have a dual income for you? As risky as it may seem for you, consider that risk is relative. My wife is a stay-at-home mom, so my runway is about 9 months.  We are presently a zero income household. 

RISK: Why is leaving the company risky?  Might you have an opportunity to return? Don’t discount how difficult it is to find good employees.   You are valuable to your company.  Know your own worth, and the decision may seem less risky.  I’ve already been asked once to reconsider my decision not to take the job I turned down.  

How have risks panned out for you in the past?   What’s the worst that can happen? Is the worst case scenario really that bad?   Might your decision be win/win?   You might take the plunge only to find a new appreciation for corporate jobs.  Or, it could go as well as you would hope.   In either case, you’ll learn something.  

OPPORTUNITY COSTS:  Congratulations!  You’ve been offered a better position.  Celebrate! Really.  

Now, how is the position better?  Is it better in ways that are important to you?  If so, then why not try it out for 6-12 months?  If not, then is the position truly significantly better (holistically speaking)?  

MOTIVATIONS:  You describe your desire as a dying urge.   What is the source of that urge?  Digging into your motivations may help with your decision.  

Also, what’s more important to you, the process or the outcome?   For me it’s the process.  What I am learning will make me more successful in the long run, even if it doesn’t pay off immediately. Others might be more set on a particular outcome. 

If outcome is important to you, this is how I think about it.  I think it’s easier to learn to code than to launch a successful startup.  Hence, learning to code is probably a realistic outcome whereas launching a successful startup is a risky proposition.  If your goal is primarily to learn to code, you might win in terms of both process and outcome.

Final thoughts: Unfortunately, you can’t A/B test your life or career decisions.  As you pointed out, you one can only connect the dots looking backwards.  All that you can do is accept that you won’t know how you’ll feel about your decision until after the fact.  (…and acceptance can be quite liberating.)  On the flip side, you probably know what gives you energy, how you feel about your career today and were you want to be in the future.  If all else fails, try tapping into those feelings.  I learned in business school the importance of tapping into my own feelings, as well as the feeling of others. That alone should cover all my student loans. :)       

Some food for thought.   Good luck with your decision!  I’d be curious to hear from you a year from now and see how things are panning out.  

Best,

The 80/20 rule  states that in many events, roughly 80% of the effects come from 20% of the causes.  For instance, in many businesses 80% of the profits come from 20% of the customers. In another example, Microsoft noted that fixing 20% of the most reported bugs eliminated 80% of the crashes and errors. 

I would argue that my path as an MBAHacker also reflects the 80/20 rule.   After 60 days of dabbling I  only know 20% of what I need to know to deploy a comprehensive web application. Still, even at this point, I’m already reaping 80% of the benefits.  I’m still interested in learning the next 80%, but it is very reassuring to see just how far a little learning and curiosity goes.  

Below, I’ll list how I went about immersing myself in technology.   This list is not exhaustive, nor do you need to do all these things to start getting comfortable with technology.  Just start with what you’re most comfortable.  I’ll use some jargon, but don’t worry if it sounds like gibberish to you.  I was on the same boat just a few months ago. 

Here’s what I did to immerse myself:  

I made it a priority.  To clear my mind from clutter, I went on an information diet and practiced selective ignorance (a la Tim Ferris).  I already didn’t watch TV or consume local news.  In addition, I cut out other sources of news.  NYT, TechCrunch…etc.  If figured I would hear about it if something really important happened.  My only source of news was Hacker News.  

I became ultra curious.  What’s this HAML stuff I keep reading about in Hacker News? What’s the big deal with Node.js or Clojure?  One topic led me to another and soon enough I began to understand how it all came together.  This didn’t happen overnight.   It probably wasn’t until the second month that things really started to click.  And I’m still learning.   Hmm…I wonder if I should use Sinatra instead of Rails?

I didn’t try to reinvent the wheel.   I used Quora to answer questions the questions I had, such as: 

Should I learn PHP or Ruby on Rails?

What is the primary use case for Sinatra?

When Quora didn’t have the answer, I did my own google searches.  Even if you don’t go on to learn PHP or Rails, after reading a bunch of these responses, you’ll start to get a good sense for important technology trends and concepts. 

I tried a few tutorials. They are time consuming, but they really helped me understand how the various components came together. Learn Ruby the hard way  is a good one to start off with.  I didn’t like Ruby Koans when I first tried it partly because I didn’t fully get the value of TDD (Test Driven Development) and it seemed a little intimidating.  I get TDD now, so I might revisit it.  I’ll write a separate post on good tutorials to use for each specific technology.  Sign up to be informed.

I announced my intentions.  On August 10th, I announced via Facebook my goal of learning Ruby on Rails in time for the CleanWeb Hackathon a month later.  This motivated me to dedicate the time and energy to do the Rails Tutorial.  While I didn’t reach my goal, I got pretty far.  At the same time, I heard from a bunch of friends that shared value tips and resources with me (a shout out to Tyler Warnock).     

I connected with others.  I signed up for a gazillion Meetup groups and attended the hackathons organized by John Yang-Sammataro.  I found people at the various meetup groups to be very accessible and friendly.  My attendance was an exercise in my “fake it till I make it” mantra in most cases, but I met great hackers.  They appreciated my effort, and helped along the way.  They also introduced me to cool new tools like Rails Wizard, a templating tool for the Rails framework.  

These are some of the meetups I signed up for:

http://www.meetup.com/Hackternoon/

http://www.meetup.com/silicon-valley-ruby/

http://www.meetup.com/rubymeetup/

http://www.meetup.com/silicon-valley-python/

http://www.meetup.com/ruby-100/

I failed a few times.  Not all the events I attended were valuable.  Not all the tutorials I tried or material I read were valuable.  Still, I kept pushing forward.  Eventually I found what worked for me or lucked out and ran into someone that was extremely generous with their time.  In one case, Carl Tanner of the Sillicon Valley Ruby MeetUp, was kind enough to sit with me for 2-3 hours to walk me through generating a basic Rails scaffold.  Thanks Carl!

In addition to the things I tried, these are some other possibilities:

Take an online class.  Codecademy and TryRuby are two good free options.  Codecademy only offers javascript currently, but will likely expand.  TryRuby is an easy way to get started with Ruby without worrying about configuring your computer.  Codeschool offers some relevant courses for a small fee.  Codelesson also offers some courses.  The courses seem a bit pricey.  Unfortunately, I can’t vouch for the quality of any of these paid options.  

Enroll in a community college.  Taking a class is a great way to pace yourself and force discipline.  They are also relatively cheap.  In California, registration is ~$100, plus $17 per unit. This is a bargain relative to Stanford’s $890 per unit in tuition fees.  If you don’t want to deal with the commute, most of these courses are online. 

Buy a book.  A book is like an extended tutorial.   If you find yourself totally lost and intimidated by the tutorials, buy a book and work on a chapter at a time.

Get a friend.  Get a dev. friend to sit with for a few hours every week.  A make sure to ask every single question that comes to mind.    

Hire someone.  Few of us can afford to hire a dedicated technology tutor at $100 per hour. However, creative solutions exist.  Here’s one, find a low-cost developer via oDesk and pay them by the hour.  They’ll be significantly cheaper (but maybe lower quality) relative to getting tutored by a U.S. developer.   Make sure you interview them first so that their accent is not a problem for you.    

Final thoughts.  As I mentioned, this is in no way an exhaustive list.  If you're are a noob hacker, stop everything else, go out and do it.  If you are a developer, what recommendations do you have for people new to programming?  If you are going thru this journey, how are you going about immersing yourself in technology?  I’m excited to hear what you have to share.  

I started MBAHacks to document my journey of learning how to build web applications. 

January 2011 was the beginning of the winter quarter at Stanford.  That was the quarter I decided to take CS106A, Stanford’s Intro to Programming class based on Java.  The class was challenging for the sheer volume of time I had to put into it.  Nonetheless, 10 weeks later I knew how to program in Java, although I was still a noob.     

Prior to January of 2011 these were the most technical things I had done:

 Programming my Ti-83 calculator using BASIC in high school

 Building my excel hack which earned me some respect from other hackers at SVI Hackspace at Stanford. (you’d have to see it to understand why it’s an excel hack)

Disassembling and rebuilding my laptop (pictured above)

Replacing the LCD screen of my brother’s IBM Thinkpad

After graduating from business school, I decided to continue learning how to program and immerse myself in all things related to building web apps.   Why, you might ask?  Well, I also thought long and hard about that question. Here is what I learned about my motivations:

For the love of learning.  I enjoy learning new things.  Even more, I like understanding how things work.  A little bit of tech knowledge goes a long way.  For instance, I was able to customize this Posterous blog using the HTML and CSS that I know.

To bootstrap.  I should note I’ll never be the main developer for my company and don’t ever expect to be a 10x programmer.   However, it’s ridiculously difficult to find and recruit talented developers in this frothy environment.  Maybe I can learn enough to build my own prototype and use that to recruit a team.  Once my team is in place, they can throw away my old code and start from scratch.

For R-E-S-P-E-C-T.  One of the most valuable things I learned at business school is that in order to be influential, you need to be influencible.  Well, learning how to program shows respect for the work of developers.   In exchange, this might just earn me some respect from developers.   Learning any language (spoken or computer) serves as a signal to others that I give a damn.   I care enough to put in the immense effort required to learn the language.  When my wife and I were traveling around the world, the first thing we did before we got to a new country was learn two words in the local language, “hello”, and “thank you”.   These two simple words transformed us from “tourist” to “guests”.  You’ll be surprised at just how few tourists bother to even learn how to say “hello” in the language of their host country.  In this sense, immersing myself in technology is a gesture of humility to my future teammates.  I don’t just expect you to speak my language; I’m willing to learn your language, too.  This brings me to the next benefit…

For the obvious.  Speaking the same language as another person dramatically helps with…hold your breath…communication!  :)   This applies equally well to technology as to spoken language.  Today, I can have a conversation with a developer that goes beyond simple concepts.   I can now discuss the tradeoffs of straight HMTL/CSS vs. HAML/SASS  or ask whether our web app should be built using Ruby on Rails or Node.js. 

For hiring purposes.  Whether I find a technical co-founder or hire a CTO, I now know what to look for in a good developer.  Should I ever need to hire a team of developers, or outsource a project, I have a much better idea of what to look for and how to work with them.

For the challenge.  I love a good challenge and building a web application from scratch is tough as nails.  I’ve done more difficult things in my life, so why not this? 

Because I can.  Through the course of my journey I’ve learned of other business people that have successfully learned how to program.  Proof that it is possible!  Here are a few examples.  Do you know of others?

Technical co-founders are overrated (great post, provocative title) Learning to program: Everlater’s story Can’t find a technical co-founder?  Do it yourself.

Conclusion.  Is learning how to program the best use of my time?  It doesn’t matter.  I’ve learned over the course of my lifetime that I can spend my time analyzing such questions or I can go out and make it happen.  For years, the main essay question for admission to the Stanford Graduate School of Business has been “What matters most to you and why?”  In my essay, I wrote about perseverance and determination.  While I can rationalize why I am learning to program, at the end of the day it comes down to a gut feeling that this is what I need to do.  I am determined to learn how to build a web app.   Nothing can stop me.  …I hope never have to eat my own words. :)     In short, MBAHacks was conceived as a way to chronicle my technology journey and share what I learn with others. 

I started this blog with a dual purpose.  First, I wanted to share my journey of becoming a hacker and inspire others to become hackers.  Secondly, I wanted to share some of the things I"ve learned about business with hackers and entrepreneurs.  This being my first post, I'll share my story of taking the start-up plunge.  My follow-up post describes Why I created MBAHacks.com, or Why I am learning to program as a business guy.   

Ten weeks ago, despite ~$80k in student debt and a family to support, I turned down a job offer as a Product Manager, at a six figure salary, within a company I love and respect, to launch my own start-up.  I’m comfortable with my decision now, but at the time I felt really torn.  How would I support my family, pay for health insurance, rent, food, student loans, etc.?   A wall of problems and obstacles hit every time I considered the decision before me.   Fortunately, I’ve been pushing myself to reframe these challenges and to adopt a growth mindset (see Mindset by Carol Dweck).  By adopting a growth mindset, I was able to see the decision before me more clearly.   Turning down a great job to do my own start-up wasn’t going to lead to a binary outcome.  In fact, even if the financial outcome is binary, there are many other benefits to launching a startup.  Here are a few that are descriptive of my experience:

Learning via immersion: 

In only 10 weeks, I’ve learned tons about what it takes to build a company.   

Technology, soups to nuts.  10 weeks ago, the words “javascript”, “jquery”, “CSS”, “Ruby on Rails”, “Git”, “CDN” were almost meaningless to me.  Today I can see their purpose and understand how they fit together.  For the end user, a web app seems like a pretty simple interaction.  You click on this button and it takes you to that screen.  To get that interaction, developers have to coordinate across an alphabet soup of technologies, frameworks, standards, tools, libraries and services.  For all the gripe that MBAs get from hackers, there is truth to the idea that understanding the technology well makes you a better person to work with.  After all, no developer wants to hear, “That shouldn’t take you too long, right?”, from someone that’s never looked at the source code of a webpage.  Nuff said.  

Note: If you’re a developer taking the startup plunge, you *might* have the opposite experience.  Maybe you don’t quite understand how product, marketing, sales, operations, finance and HR come together to building a great company or what jargon like “internal rate of return”, “cap table”, and “convertible notes” actually mean in plain English.  I plan to address some of these topics in future posts.  

Tools.   Having been out of the workforce for three years, I never had a need for serious cloud collaboration tools like Basecamp, Pivotal Tracker or MavenLink. Besides DropBox and the like for personal use, Google docs is the most sophisticated cloud tool typically used in business school.   Over the last ten weeks, I got re-introduced to the latest and greatest cloud based tools for businesses of all sizes.   These will come in handy whatever I do.  

Relationships.  I’ve met talented designers, developers, freelancers and a bunch of other wonderful people.  I’ve worked with developers in Estonia (Mark & Anton), a designer in the UK (Akhil), and a virtual assistant in Pakistan (Maria).  Where ever I could, I’ve tried to help the people I’ve met along the way, connecting them to opportunities or people.   I don’t know if any of these relationships will ever yield any direct benefits for me, but I do know that I’ve enjoyed meeting them and appreciated help from others (a shout out to Carl Tanner, Johnson Nakano, Dan Bikle, John Yang-Sammataro, Joel Resnicow, Justin Nassiri, Gulin Yilmaz, Randy Lubin, Evan Rosenfeld, and Amit Aharoni).  *Edit* And how could I forget the amazing Mike Dorsey.  He was my biggest inspiration to become an MBAHacker.   

Lean thinking & scrappiness.  I could never imagine a large enterprise using Amazon Mechanical Turk to help them choose the name for a new product, or throwing up an Unbounce landing page and combining it with Google Adwords to test a concept in a matter of days, not weeks.  Heads would roll!  Did I mention I have an assistant in Pakistan?  

Personal. I get a lot of personal satisfaction from working on new ideas, meeting interesting people, and pushing the envelope.  Personal satisfaction can’t be measured in dollars. 

Besides these great benefits, it also helped to put my decision in perspective.  Relative to the other 6.7B people in the world, my downside (returning to a solid corporate job), seems pretty low.  If you feel the startup itch, and are afraid of what’s on the other side, it might help to consider these three things.  1) There is never a “good time” to take the plunge.  Thus, now is (probably) the best time.  2) You won’t know what you’re missing  until you try it.  3) What’s the worst that could happen?