Coder. Speaker. Writer.

Almost one month ago I left Mint.com to strike it out on my own.  I remember leaving the building after saying goodbye to people that I had helped hire, and built a product with for over 3 years of my life.  The days leading up to my last day were filled with a bit of sadness, and apprehension.  I recalled all my fondest memories of team lunches, the burritos in the park, and the countless milestones and awards Mint had won.  But my last supper with the Minters was probably one of the best and most fulfilling experiences and evenings.  I shared my ideas for new startup with them, as we enjoyed our final feast together.  Despite knowing I was leaving a team of people that I cared about greatly behind, I got into my car and drove away feeling excitement for the next challenge and the next team and product I was going to help build.

Even though I was involved with Mint since the very beginning, which was over 4 years ago, I felt like I joined Mint, blinked, and it was over.  While it was a memorable experience I’ve been making an effort to enjoy more of the process and living every moment of it with my own startup.  As someone who has always been future focused living in the present is a challenge for me.  But I actually really love it!

How do I do it?  For starters, I have a slight advantage, getting in on the ground floor at Mint I witnessed first hand what its like to deal with scary concepts like the unknown,  constant change, the imperfect product, and endless set of problems that arise and need to be solved.  For example, a couple weeks ago I had a conversation with my partner about data quality.  She was really concerned that we wouldn’t have perfect data for our customers.  I listened to her concern and then a thought occurred to me, “Where I have seen this problem before?”  Oh thats right Mint never had perfect data!  And yet Mint user were willing to live with it, because the value we were providing to them as a service that provided a complete picture of their finance outweighed small data anomalies.  Drawing from that experience made me realize that I was in control of the situation, and could help to assuage my partner’s fears.

Every once in a while my old CEO calls me up to ask, “How the new business is going?”  And my usual cheery retort is, “Everything is great!”  How could everything be great, when I don’t have any users, revenue, or a prototype build yet?!?  Because I have a team that I have proudly built, it’s not big, but in my mind its still a team of more than just me.  And because everyday I make small strides, like signing up the first customer who will help me test my prototype and solving at least one product problem a day.  Before I go to bed I review the days activities like enjoying a meal or cup of coffee while conversing with a friend, reading a new book, writing some RoR code, giving a talk to other entrepreneurs, and thats enough for me to feel like I have a purpose, and want to go to bed so I can jump out of it the next day and do more!

When I was a freshman at Duke, coding away in Teer basement, I would often hear disgruntled engineers shout: “Damn, I’ve got 300 syntax errors, I left off the semicolon!  Why does everything have to be so exact?”  Those were the days of coding in C++, a language in which you had to actually compile, but hey it was faster than punchcards!

Nowadays we have dynamic typed languages like Ruby that don’t even require semicolons!  But that doesn’t mean we’re in the clear.  We still have to debug.  RoR has done a good job of building in a lot of debugging tools.

Here is my philosophy and methodology for debugging:

1. Errors and Exceptions are the easiest: Load the web app, if there is an error or exception thrown in the webpage tackle that first.  If I don’t know what the exception means e.g. InvalidAuthenticityToken, I will look it up.  And read about it and usually that will lead me to a solution.
2. I love logs! If the web app seems to load properly, but some functionality is broken I go look at the logs.  You can add log statements based on the level of logging you want to controllers in RoR with the following code: logger.debug “BUGGY” or logger.info “YO”
3. Data Corruption: to the Database! If the data appears to be displayed incorrectly then I go straight to the database.
4. Look & Feel: if something is off with the way the page is rendered then it is most likely something I did wrong in HTML or CSS.  I like using Firebug for CSS issues.
5. Vijayashanker Code If something is off about the functionality, and I have a sense of where it is happening I will go through and read my code.
6. Debugger Last: I’m not really a lazy person, but setting breakpoints and stepping through code can be tedious.  So I save this as a last resort if I can’t use any of the above techniques to find my bug.
7. I hate “debug” statements! I’m a neat freak, I don’t like polluting my code with debug statement, and creating more work for myself in having to go and remove them later.  If I can’t get the debugger to do what I want then I will resort to using debug statements.

As I was debugging today I discovered a few good resources here are a few of them:

• Debugging Rails Applications (walks you through common debugging techniques and also explains logging levels and configurations)
• Logging Tips (Everything you ever wanted to know relating to logging in RoR)
• RoR Google Group (I found solutions and insights into most of the problems I was experiencing today)

I’ve been in the Bay Area for the past 5 years, and prior to that I moved here from India when I was two, so in sum I’ve lived here a little over 9 years (yes I’m counting childhood because I claim to be precocious).  I’m not too savvy when it comes to SF, because lets face it I love the warmth and sunshine of the peninsula, and I don’t plan to leave anytime soon.  Being dubbed as one of the most energetic and extroverted engineers you’ll meet I’ve managed to explore a lot in along the Bay.  Here are some “scenes” to check out for all your newbies:

Startup Scene

For gals who want to learn more about startups and tech: Women 2.0

For gal and guy coders who want a place to work: Hacker Dojo

If you want to be a 408/650 coder try these out: Ruby Meetup, SDForum, Google Tech Users Group

Entrepreneurs who can’t get enough caffeine:  Dana Street Roasting Company & Red Rock (Mountain View), Coupa Cafe (Palo Alto)

Entrepreneur networking: SVASE

Learn about Startups & Emerging Technology: Stanford VLAB

Yoga/Sports Scene

I love Bikram and this is my favorite studio in the Bay Area: Bikram Yoga San Jose

Competitive Skiing/Snowboarding: Snow Drifters

Food Scene

My favorite Italiano – Gambardella’s

My favorite India – The Mynt

My favorite Mexican – Fiesta Del Mar Too

My favorite Sushi – Joy

Cafe Scene

My favorite espresso bar – Caffe del Doge

All around cafe –  Cafe Barrone

All around cafe – Los Gatos Roasting Company

Chocolate Scene

Chocolate tours and tasting - Charles Chocolates

Wine Scene

Wine & Jazz Bar – A Perfect Finish

Cozy Wine Bar – Wine Room

Beach Scene

Santa Cruz is fun, but Capitola is nicer.

Meeting Nice People Scene

Spanish Meetup

Coupa Cafe

Rose & Crown (Tuesday is trivia night)

Adventure Scene

If you want to fly: Trapezing

If you want to jump: Trampoline Dodgeball

Relaxation Scene

Watercourse Way

Day Spa

Music Scene

Music in the Park (summertime only)

Today I attend the Girls in Tech: Catalyst Conference at the Common Wealth Club in San Francisco.  It was a great meeting ground for all girls in tech.  I was introduced to VCs, CEOs, and of course fellow femgineers!  My panel was: “Curious About Coding & Developing: Developing Creativity & Building a Business.”  Here is what I learned from the Q&A period and hallway conversations I had with other girls:

1. Women want to code!
2. Entrepreneurs want to understand where they can meet developers and how to interact and motivate them to join their startups (this is gender neutral).
3. There is a growing gap between entrepreneurs and engineers (once again gender neutral).

Because the panel was brief some questions on each of these points went unaddressed.  I’m going to attempt to address some of them now.

1. Just do it!  Seriously, if women in their 20s can run companies, 30s can run marathons, 40s can give birth then they can certainly code!  Any new skill is daunting (believe me I’ve tried snowboarding on blues…)  But the key to learning a new skill is patience, practice, and perseverance.  Start by figuring out what you ultimately want to do e.g. designing websites (CSS, HTML, Illustrator/PhotoShop), creating software programs or web applications (Java, Ruby), or pulling data for business reports (mySQL).  Next evaluate what kind of learner you are: self or group?  If you are good at self-study then go do some tutorials.  Don’t do it all in one shot, pace yourself!  And if you like learning in groups then go attend a workshop or a class.  You can enhance your learning with podcasts on the subject (there are a ton on iTunes), and reading books on the topic.

2. Its no secret developers are a nose-to-the-grindstone bunch.  Good developers are especially hard to meet in the wild  Here are a few secret hide-outs: Hacker Dojo (Mountain View), Meetups (Ruby, Java, iPhone, Android) along the peninsula hosted monthly, and of course un-conferences like CodeCamp, She’s Geeky, and Chirp.

I hate to stereotype but I think there are two key motivating factors: building cool stuff, and solving tough problems.  By building cool stuff I mean developers who like to work in a fast paced environment, like a startup, and be a part of a product’s evolution.  By solving tough problems I mean developers who like to work in a stable environment and think about tough engineering problems like scaling a database or improving the performance of a site to load photos really fast.  Figure out which you want for your company or team.  Then motivate them, first and foremost with projects, and second with the autonomy to build or work on those projects and drive the direction of them.

3. This is mostly a communication issue.  I’ve noticed a growing trend in entrepreneurs understanding jargon, and even what technologies work best for front vs. back-end development.  But I have yet to see a movement in the developer community  to create a more articulate bunch of coders that can clearly explain tradeoffs in laymen’s terms e.g. more servers == more $$ or more code clean up == more developer time.  I think such initiatives needs to start at the university level, perhaps by incorporating a public speaking component to the curriculum.  And in companies managers should force their developers to explain projects and give presentations that are across departments.  I don’t think agile does a good job of emphasizing the need to be articulate, but I think it would help with the entire product development process.

Marketing is essentially telling a story and conveying a message to customers and users about a product or a company.  But how do you tell a compelling enough story when there are 50,000+ products out there each competing for a slice of the market?  Perhaps it would be easier to get a slice of the pie if you’re marketing strategy was baked into your product.  The strategies for doing so are highlighted in my latest read: BakedIn. The authors discuss 28 rules that infuse every aspect of your product and business with a story.

While I’ve been called a marketing genius on stage by Aaron Forth, VP of Product at Mint.com, I hardly warrant such a title.  It takes a lot more than just a simple name to create a successful product and brand like Mint.

Here’s are a few highlights of what it does take:

Cultural Trends – understand where the consumer culture that your product is using is headed.

Design – think about ways to design each element and use them as touch points to interact with your customer and evoke an emotional response.

Find out what business you’re in – list all the service and the emotional benefits you create for customers.

Know the entire business category – use a competitors products to see what advantages and disadvantages it possesses.

Get your hive on & Knock down the walls – siloed organizations do not lead to innovation (another reason why great firms fail).  You need to foster a collaborative culture within your organization across departments, and make sure that information is flowing between the departments, instead of it being hogged or withheld by a few.  If need be jump across silos, but be aware that it might cost you your job.

Absolute – strive to be the superlative in a field (fastest, smallest, quickest)

Design to your weakness – confront the big hairy monster that is standing in the way of your organization’s success and find ways to design around it.

Good short read for anyone who wants to infuse life into a flailing product, create a new product, and most importantly tell a compelling and gripping story to keep customers engaged.