Full Stack Thoughts

Some 6 months ago, one of my friends mentioned how I should join him on his yearly marathon, which he relentlessly hates, but enjoys the accomplishment. I, coming off the high of successfully training and crushing my sub-2 hour half marathon goal, said I’d think about it. The allure of going back to Vegas after 6 years and finishing the marathon on the strip was too much. After an easy Saturday morning 8-miler, I registered for the Rock 'n' Roll Las Vegas marathon without the refund protection in case I change my mind. I was committed; no turning back now.

Over the past 12 weeks, I’ve been training for this marathon — my first ever! I chose Hanson’s Marathon Method because I like scientific approaches and really just enjoy a challenge! I also have had success with a similar cumulative fatigue training plan that helped me improve my PR by 12 minutes at the 2014 Brooklyn Half. So, despite my friends' concerns regarding a max long run of 16 miles (instead of the traditional 20—23), I bought the book, studied it, and started just over three months ago.

Let me give you a quick overview of the program. I’m doing the advanced program, since I’ve ran longer-than-half-marathon distances over 10 times. The program consists of 6 days of running with two S.O.S. (something of substance) workouts — it can be either speed work, a tempo run, or a strength workout — and a bi-weekly long run. The rest of the 3 days consist of easy runs that are meant to be ran at a pace easy enough to hit your fat-burning zone and gain aerobic benefits while still promoting recovery.

With the AWS Summit event taking place in NYC this Thursday, I want to revisit last year’s event. The biggest announcement (besides reduced pricing) was DynamoDB. It was such a big deal – a startup CTO was “Twitter-quoted” for saying he's going to migrate from Mongo. I was excited and so was one specific Lead Developer at Acadaca.

Dynamo promised consistently fast write/read speeds, automatic replication for high availability, and the same hourly pay-only-for-what-you-use pricing everyone has grown to love. A master-slave Mongo setup of two m1.large EC2 instances would go for about $200/month, while a 200 write units/50 read units Dynamo setup was nearly $100/month. The beauty was that I was going to start at a 20/50 read-write ratio (50 read units because the pricing is the same for the first 50 reads, so might as well use it all), resulting in less than $20/month. So, when the opportunity to use Dynamo presented itself, I jumped on it!

Logging errors and other arbitrary data was the task — the perfect use case. Lots of writes, massive amounts of data, and relatively low reads. I developed the logging API with Mongo the entire time and spent an entire day rewriting the db interface logic. And that's when it hit me — Dynamo is too limited for this application. 

During the rewrite, I found myself making many accommodations for dynamo; generating primary keys on the app side, flattening nested documents, passing time stamps as seconds since the epoch, etc. That was fine with me, but the limited querying was a deal breaker. 

Besides storing data, the logging API was capable of retrieving logs by site/apikey, level, and any other combination of values via a dashboard (perhaps, via a future mobile app as well). Dynamo doesn't support that type of querying for its guaranteed reads speed. It queries in two ways — (1) an exact match with a unique primary key or (2) composite querying consisting of key and a range key (in my case, an apikey and a time stamp). 

The way to get around that is to use their Scan API, which would allow you to query for any field. The catch? It does a full table scan rather than use the pre-defined indexes used in its regular queries. This can get dicey with tables with millions of rows, as would be the case with a log table. 

Digging through the AWS forums, I was able to find some unique solutions. The first, suggested by an AWS rep, was to create a new table each month, so the table doesn't get so big the full table scan hurts. The second, was to schedule Map Reduce jobs via EMR (another level of complexity for something so simple, I thought). Interesting solutions, but in the end I just stuck with Mongo.

It's very difficult to beat automatic primary keys (it's very difficult to generate unique, non-colliding IDs in a clustered environment; I used RFC-compliant UUIDs with node-uuid, but I feel the database layer should handle this ALL the time), nested documents, document sizes up to 16MB for ridiculously verbose logging (Dynamo is capped at 64KB) and multiple indexes for super-fast queries.

Obviously, the limits imposed by Amazon are to ensure consistent speeds and replication for Dynamo. It still does look like a really good service – just not as flexible as I’d like. I’m not bitter though; that Dynamo integration day wasn’t entirely lost. I wrote a some db resource abstraction code for Node that would handle different databases on multiple environments – check out the gist on GitHub.

Like all new tech, every thing has its own best use cases. Maybe some time down the road, I'll revisit Dynamo. 

The brain is an amazing thing. In a short period of time, you can go from a concept to 10 derived ideas to 20 different features. Some would call such a fertile mind a gift. I agree, but this sort of thinking can be counterproductive when trying to focus on building one new feature.

  When developing a product feature, there are two sides of the spectrum — the simple way that addresses the current use case or the potentially complex one that ensures future extensibility. In either case, the most important resource is time. The amount of subsequent development time after you ship will almost always be lower in the latter.

  The problem with building a feature worrying about future features is just that — thinking about future plans while building version one. It quickly becomes inefficient to try to cover all the bases to ensure development ease down the road. Remember in college when you had to write that 5-page essay and found yourself going in circles talking about things that didn't back up your point? This is the same thing.

I've been fortunate enough, so early in my career, to have been a part of many tech teams of varying sizes, ages, experiences, and specialties. In the process, I've developed a labeling system to categorize all the good people I have worked or work with. I've been doing this since my retail days in college so, it can be applied in any setting or industry. The gist is to identify the different roles within a team that people — in this case, developers — perform on a team.

Imagine you're a Senior Engineer who writes code for the server, client and kills bugs all day. That's cool. From the outside looking in, you're a full stack engineer. Now what about your fellow co-workers? Do they see you as just a Senior Engineer? Probably not. Each one of your colleagues probably has a different name for the role you have on the team — it's really all about perspective. 

I've realized that good developers (bad developers are just bad developers, period) can be labeled any or a combination of these four labels: the visionary, the captain, the builder, and the facilitator. 

The Visionary

This is the Jack Dorseys of the world — technical people with an affinity for product design and development. This developer can build a prototype without any shortage of features. In fact, he/she is always thinking about new features and ideas. When it comes to scaling an MVP, help is definitely in the cards. 

The Captain

This is your CTO or tech lead (CTO is such a pretentious term in early stage startups); he/she knows exactly how to build your product/service to scale. He/she guides other developers and can be "on the front lines" to help build things as well. 

The Builder

Every team needs plenty of these! The builder is the person that stays glued to a computer screen for hours building new features. Whether it be solving a technical problem or fixing that cross-browser bug, this developer does not shy away from a problem. The majority of your product is built by the developers in this role. 

The Facilitator

This developer is the x-factor on a team. If tech teams had a designated hitter, this is it! This person handles the unsexy tasks in development — setting up a repository, building that CLI utility from source, and/or integrating with that shitty 3rd party SOAP API. This role allows the rest of the team to focus on things they do best — the visionary on product, the captain on architecture, and the builder on creating new features. 

This past weekend, I participated in the Hearst Fashion Hack at the Hearst Tower for a 24 hour blend of fashion and technology. Along with Jeff Uthaichai and Steve Skladany, I built gilt-e-pleasure, an app that enables you to browse products for sale on Gilt and allows you to get it later by being loaned the money when you sign a promissory note agreeing to pay within 7 days or get hit with a $15 late charge! We ended up winning the DocuSign 1st place prize and giving the judges and audience a good laugh!

This was the first hackathon I attended without an idea for a disruptive service beforehand. I have to admit, I felt unprepared; as if I only showed up for the food, beer, and the overall good time characterized by a hackathon. Contrary to my feeling of unpreparedness, this allowed my teammates and I to really think outside the box.

Around 2:30 pm, we began tossing ideas around of things we could build with the sponsor APIs. An hour later and after much deliberation regarding whether to build a Windows 8 app (in my experience, less than 5 teams try developing for Windows 8 thus making it the easiest prize to win), we refined our app to what is now, gilt-e-pleasure. 

Without a full 24 hours to code, we quickly got down to work and divided the work. Steve started designing the UI, Jeff set up the repository and server, Katie (Steve's wife who pitched in big time during our brainstorm session) wrote the promissory note, and I began setting up the project structure. 

As Steve continued to design the interface, Jeff and I divided the API integration work — he took DocuSign and I took Gilt. Gilt's API gives you access to all the content on their site; you hit the active sales endpoint and you get all the sales organized by departments. Also included in each sale is the API endpoint for the details for each product.

This was a problem – there were 78 sales and about 20 products a piece. Steve was crafting a tile-based UI and I knew he might want to add infinite scrolling (contrary to my thoughts), so loading by hitting the API all the time wouldn’t be fast. Instead, I made the roughly 1560 API calls and cached the results for 2 days in a format I could return quickly.

By 10 pm, Steve had wrapped up the first version of the UI, Jeff had the DocuSign integration working, and I was wiring up Steve’s design with data. Overnight, we worked on refining the site design and making it faster. With 2 hours before submission, Jeff bought the gilt-e-pleasure.com domain and updated the DNS records.

Meanwhile, I was working on the biggest hack of our hack! For every Gilt product, I did a keyword search for the ten latest Elle articles on the brand via the Hearst API. For each unique author, I searched on Twitter for the author by name via Twitter’s API (this was a pain to setup without taking the user through Twitter authentication) and found the Klout score for the first 5 relevant Twitter accounts that could potentially be the author.

I created an algorithm that computed the average Klout score and gave more weight to a Klout score for a Twitter screen name that was a concatenation of the first name and last name (for me that would be RafaelGonzaque, GonzaqueRafael, Rafael_Gonzaque, or Gonzaque_Rafael) and the amount of articles the author wrote that mentioned the brand. The gist is that this measure is the average influence effect for that product on social media, so we could refer to it as the buzz factor.

Unfortunately, time ran out and we couldn’t incorporate the buzz factor into the UI to filter products by it. The plan was to allow showing products that had articles written about them by Elle authors with Klout scores above a threshold you defined. I’m going to include it in the UI within the next couple of days, so lookout for it!

So there you have it! From idea to implementation to concept in less than 24 hours. Give it a shot and leave feedback in the comments. We are not saving data on the site, so you can go ahead and sign the document. We promise not to pursue legal action. :)

The first 2 weekends of 2013, I've spent most of my time hacking away on an idea I've had for some time. The gist of it was to compile my foursquare checkins to figure out when I should avoid my favorite coffee shops and lunch spots when they are too busy. 

  Motivation

I noticed my favorite Starbucks had lines almost to the entrance about 85% of the time around 3 pm. To the contrary, at 3:30 pm or even, 5 pm it was almost always a short line — 3 people or less. Now these are just observations and observations without data are just assumptions, so I set out to get some data. 

  Creating Data

I expected to rely on checking how many people are checked in at a particular venue at a particular time. However, the number of actual people at a venue is almost always greater than the amount checked in. Lets face it, not everyone checks in to places — unless you're at a tech event. This fact would no doubt lead to some false ratings. 

So, how did I get this data? From mid-June 2012 to even today, I have been checking in to places with either a "#busy" or "#notbusy" in my comment (those of you who are my friends on foursquare may be familiar with that). It's no surprise this hack's name is #busy (pronounced "hashtag busy"). So there, quantifiable data is now available no matter how perceptive a busy or not busy rating may be. 

Implementation

I utilized the foursquare API, which happens to be excellent and ridiculously fast, to pull venues I've been to and all my checkins. I had over 1000 checkins in a little over 300 venues, so sifting through the data took about 20 secs (only 176 of the checkins had ratings). 

Foursquare returns a ton of data from their API, so it's important to store only the data you need and avoid making constant API calls. If you don't, you'll quickly realize that the network latency and repetitive requests isn't something to take lightly, even though the API responds in ~ 200ms every time.

I sought out to only store what I needed in a normalized structure since I'm using a relational database.  I stored 3 things: the venues a user visited, the time and venue of a busy or not busy rating, and the user information, more importantly the user's access token. 

If you are familiar with Facebook's API, Foursquare's API is very similar. The only difference, which is one I agree with, is that a user's access token for your app lives forever, unlike Facebook's 60 minutes. 

The Hack

I quickly spec-ed together a way to display the data. What better way than a map showing all the places you've been and some indication on the marker if it was busy or not?! I crafted the SQL query that would give me all the venues a user had been to with the busy and not busy ratings from all the users within 10 minutes from now.

I added a markers filter that doubles as a legend, so venues can be filtered by ratings. I also made it a requirement to have a profile screen where you can see how many ratings you have contributed with some nice messages of encouragement á la Foursquare (btw suggestions for more of these messages are welcomed).

Technology

The entire hack is built on a typical LAMP stack. 

Server Side

PHP using the Kohana framework

Apache fronts everything

MySQL with InnoDB

Client Side

Bootstrap for front-end structure, base styling, and responsive features

jQuery for client side DOM manipulations

What's Next?

#busy is a work in progress. I'm looking forward to adding new features like, mashing up the busy/not busy ratings with venues near your current location and facilitate rating while checking in right from the web app. 

As a developer, I implement a lot of features that may be unique or emulate functionality on another site. Web design is like every other form of design — sometimes you lead, but most times you follow the aesthetics that are out there. Recently, infinite scroll is the feature I most commonly see.

Infinite scroll has its origins from the lazy-loading mechanism for displaying many images of large sizes on one web page. Instead of loading all images at once, lazy loading would add the direct link to image HTML tags in the DOM when the scroll bar reached a certain threshold.

This allowed you to have the structure of a finite set of images declared without having image downloads slow the rendering of the rest of the page. When the images were scrolled nearly into the viewport, the images would be downloaded.

Along came Web 2.0 with its heavy use of Asynchronous JavaScript and XML (Ajax) requests. Instead of lazy loading, Web 2.0 sites loaded content in chunks. So instead of rendering image structures sans links, they would load a subset of the data and include a load more button, which would fetch the next chunk.

The great thing about Ajax requests is they can be used to request information without reloading the entire page, making Ajax useful to more than just loading chunks of images. Large amounts of data like, activity feeds and long text started to be paged this way.

Over the past 5 years, big data has become a big thing. Users are generating so much data that paging would still result in more than 20 pages. Thus came a mashup of Ajax and lazy loading; why not asynchronously load more content when the user nears the end of the current content list? This is the birth of infinite scroll.

The problem with infinite scroll is that most sites are adopting it over paging or a load more button as the de-facto Ajax loading mechanism for content. This paradigm shift is used as a way to make the product easier to use by removing the load more step and really shines in two uses cases: massive amounts of content and shitty search mechanisms. The former is ideal use case, but that latter can be easily resolved by integrating Elastic Search or Solr into your stack.

If you have a product that on any given content list has data sets that can be paged in less than 10 pages, there is no need to implement infinite scroll. Infinite scroll implies that you have so much data, a user can spend 10 mins going through content. As a result of how widely used this UI feature is, users now have a certain threshold of how much scrolling they do (think Facebook's never-ending news feed). Users are not going to stick around to reach the bottom — they will resort to search sooner because of infinite scroll.

Paging gives users a visibly finite amount of data they can consume. The user evaluates a small amount of content at a time; as opposed to infinite scroll, where you have no clue when it will end. Essentially, the user makes a decision to continue going through content, which leads to longer user engagement sessions in discovery sections of your product.

While having a conversation with a group of friends at a Social Santa event, I pulled my phone out to add a couple of recommended restaurants to one of my Foursquare lists. A quick glance at the Mail app revealed a count of 14 unread emails, which is fairly odd for 9:30 pm. After following the thread, it turned out to be a colleague asking another colleague to do something and was apologetic for the late request. The requested colleague simply responded by saying “I’m always on!”. That comment put the biggest smile on my face right in the middle of a group conversation.

You see I’ve been singing the job-versus-career praises for a while now. By that I mean, when you look at your occupation as a job, it has a start time and end time. Contrarily, when you view it as a career, there is no such thing – you’re on 24/7.

Every time I tell that to a group of people, someone always says “you can’t possibly expect anyone to work 24 hours, 7 days a week”, “I need me time”, and “if I answer emails during after-hours, it’ll become an expectation”. My answer to that is “not exactly”, “OK”, and “just answer when you can – after-hours are after-hours, after all”, respectively. I call that 24/7’s dilemma, but it's something that should be a non-issue and here's why. 

When your career becomes a part of your life, you cease counting hours and worrying about unimportant things — you just do. Think about this: do athletes complain about all the training that comes with being an athlete? Do performers make a big deal of all the rehearsing before gigs? Do CEOs ever sound like they rather be elsewhere during an earnings call?

Notice that I picked very specific industries — sports, arts, and business — to show that although they are distinct in nature, you can make it and succeed at the highest levels by devoting yourself completely. The aforementioned careers all belong to people who commit 100% of their lives to what they do.

Now, let me clear up a misconception. Being committed to something 100% doesn't mean you're always doing that one thing. It means that your lifestyle is defined by that commitment. Essentially, job responsibilities never feel like job responsibilities. Personally, I really enjoy working with someone that works as hard, if not harder, than myself. No complaining nor clock watching, just getting stuff done, period. 

Here are some tips to follow, so you can get to this point. 

Marry Your Career

If you love your career, why not marry it? No altar is necessary; you just need to make the decision to commit yourself. Be sure you are true to yourself and have a "this-is-what-I-do" mentality!

A pet peeve of mine is hearing people complaining about work and wishing they were home on a Monday. Really?! I can only understand that on Thursday or if you work 2 jobs. Marry your career and you'll be a Monday person. 

If Your Occupation is a Job, Get a Career.

Some people differentiate a career from a job by the benefits and the individual growth factor. However, I'm a deep believer that it's more about perspective. What do you consider your current occupation — a job or career? 

I get that some people are caught between jobs or are doing something they don't like to make ends meet. That's totally cool, just make sure you're making moves to get into doing something you love!

Have a Career? Make It Your Lifestyle.

Some of the things you do in your spare time revolve around your career, such as, events, trips, parties, etc. Those events are fun not only because they’re social and don’t occur within the confines of your office, but because you are no longer categorizing it as a job event. Now, let’s say you could make every function of your career transcend the notion of viewing it as a job responsibility. Instead, view it in the “this-is-what-I-do” lenses. That would make for the kind of work day where time flies and spontaneous email checks come naturally.

Putting It All Together

Over the past three weeks Instagram articles have been taking up a lot of real estate on many tech sites. Recently, Instagram has made moves that directly affects its users, in what appears to be strategic actions dictated by its public parent company, Facebook. 

First, it dropped support for Twitter cards, then came the changes to its terms of service (ToS) that would allow Instagram to do whatever it wants with your photos and all the data attached to it – including your name, location, and comments. After all the outcry, it revised the advertising section of the ToS.

I am not surprised at all by the changes and you shouldn't be either. As users of an inter-connected web with many services where we share parts of our lives, we have developed a high level of tolerance for privacy invasion. Would you leave your email and full name on a piece of paper on a train? Would you leave photos of your awesome party or newborn baby on a park bench? Probably not, but that's what we do on a daily basis when using social platforms. We agree to share our locations, thoughts, feelings, and photos with the world without ever fully reading the ToS or privacy policy.

You may argue that Facebook’s privacy settings are really good compared to other social platforms. I will agree with you but, what about the app developers you have given access to your Facebook account? How many people actually scrutinize the permissions the developer is asking for? Authorized developers have 24/7 access to all the data you have allowed access to.

One thing is constant among the social platforms: the cost is free (unless you’re using App.net). These services allow you to connect with your friends, family, and the world, all while costing you nothing. Every company must make money to stay in business and your favorite social platforms are no exception. The advertising model has proven to be big business for web companies – Google and Facebook both track users' visited sites and try to feed you relevant ads by leveraging their search and social data, respectfully. 

Instagram changed its ToS for the same reason. Instagram's product is a social network centered around images. If they were to start monetizing with banner ads, it would ruin the user experience. Sponsored images might work, but it's obvious they are thinking about ways of monetizing the service so we can continue to use it for free. 

Think about it. Twitter cards support is dropped, so now you have to visit the Instagram site to see the image. Hooray! More page views and visitors – we know how much advertisers love those kinds of metrics. But it also gives Instagram an opportunity to raise its exposure to more users, since visitors will be forced to visit their site to see the images – just take a look at the new sign-up wall. Now, you have to sign-in/sign-up to view comments or likes for an image.

More users and visits means more revenue for a free service that you, as a user, value. I think it’s great that Instagram listened to its users and cleared up any misunderstandings by updating the ToS. Here’s an excerpt from Kevin Systrom’s post on Instagram’s blog:

Going forward, rather than obtain permission from you to introduce possible advertising products we have not yet developed, we are going to take the time to complete our plans, and then come back to our users and explain how we would like for our advertising business to work.

To many people, this week is all about business as usual, holiday parties, and Santa Con. Those things are true, but it also marks the ending of an exciting venture — The Daily. I was one of the first developers at The Daily; developing new features for our in-house tools and CMS, and supporting the staff from two months before launch to a year after.

I am not going to write a post-mortem of what went wrong, nor will I write about what they did correctly because Brian Alvey nailed that on his guest post on TechCrunch. What I will write about are the things The Daily did, which have become expectations for apps from publishers venturing into the tablet space. 

Interactive Content

The Daily launched at a time when the value of an iPad was questionable — is this really going to replace a computer or is it just a larger iPod? Two years later, that question is a lot more deterministic. The plethora of things that could be done on an iPad changed that. Specifically, reading your favorite newspaper or magazine in a digital, shareable format. 

As it turns out, a digital port of a print version is really bland. The Daily’s content, while heavily criticized for being blatantly conservative, never lacked interactivity. Few were the articles that were only text. The articles were always supplemented with images, video, 360 degree images, polls, animated charts, and other animated elements. It was like a newspaper/magazine that came alive in front of you on a daily basis.

Community

Besides the immersive content, there was a sense of community among The Daily's readers. Articles were heavily commented on by readers, particularly the ones from News and Opinion. The reporters, section editors, and even the editor-in-chief himself, Jesse Angelo — appropriately using the username “TheEditor“ — would engage with readers. Where besides, online publishers, such as PandoDaily and Business Insider, would you see that? I've been reading Business Week on my iPad for over a year and still can't comment on a story from the app.

The community extent was taken even further with the launch of the Facebook app. Launched at F8 and making use of the really open Open Graph, it allowed for a deep social experience where users could discover new things via the Ticker and consume content together.  A sense of community really gives value to a service among users and The Daily did just that.

Pricing

One complaint that I rarely heard about The Daily was the price. Their pricing model was a 2- week free trial and two subscription price points thereafter: 99 cents a week or $39.99 for a year (I believe there was a 26-week subscription, as well). Compared to your local newspaper and the burden of having to deal with dirty print paper, The Daily cost nearly 80% less a week. 

99 cents is low enough where the cost of entry, for most people, is insignificant. The New York Times is running a promotion that allows people to try any of its digital offerings for 99 cents for the first four weeks and Wired charges $1.99 monthly for its iPad app. It's easy to see price point trend. Just take a look at the prices of news app in the App Store; they are all either free, free with a print subscription, or some price that hovers around the 99 cents per week price point.

The only tablet offering that can get away with charging users upwards of that point is The New York Times. They are only the exception because their digital subscription is bundled with access to their website, which also includes access to all their historical articles. Over 150 years of news coverage at your fingertips is very powerful and valuable. Just think about Lexis Nexis, its database of information, and its cost.

Interactive content, community, and adequate pricing were all things The Daily had. The tablet offerings that sprung up since its launch in February 2011 and ones to come, will need to have these as well to keep users coming back. In the end, content is always king, but it won’t resonate with all users. So, the delivery and consumption of that content must be beautiful.

A Final Word

Earlier this week, I attended my first Brooklyn Tech Meetup. I’ve lived in Brooklyn for the past 5 years and have been to two Queens Tech Meetup — shameful, I know. I attended this BKTM for 2 reasons: my friends from Aggregift were presenting and Charlie O’Donnell. In case you didn’t know, Charlie O’Donnell is a VC at Brooklyn Bridge Ventures that invests only in New York startups.

His talk from the event was intriguing, informative, and even, a little “Dr. Phil-esque”. Here are the main things I took away from his talk:

1. Save Your Pitch for the Right Occasion

So, you’ve attended an event featuring a panel of VCs. As soon as the panel is done speaking and the Q&A forum has concluded, you rush your ideal VC. Even surrounded by a throng of other eager founders and entrepreneurs, you are laser–sharp; you introduce yourself, your company, and give your 2-minute pitch. Problem is, that VC is probably thinking about what to get to eat, someone is waiting for him/her, or is just plain tired. Introduce yourself and company and save your pitch for when you have most of the VC's attention.

2. Be Persistent

We all know VCs get a ton of emails, phone calls, and intros on a daily basis. As Charlie puts it, "I'm giving away money with my email next to it". If you send a VC an email and you haven't heard back from him/her in a while, it's perfectly fine to forward the original message again, saying something like, "hey I'm not sure if you saw this yet? ...". Charlie says its actually the opposite that would worry him - lack of persistence.

3. Do You Have an All-Star Founding Team?

This was a major topic during his talk. In an era where everyone is Google-able and LinkedIn-able (that might be the first time LinkedIn was used as a verb), VCs can do a quick team assessment and determine if this is the kind of team he/she would put together. Recruiting is difficult and is made easier by hiring people around you, but just make sure you have a qualified, solid team.

4. Go Big

This was both a tip for your startup and life. Let's first go over the startup tip.

Is the scope of your startup crippling the potential size of your target users? Why limit yourself to a small user base if you can aim for a huge one. For instance, if your startup targets singers, why not target all people in the music industry - musicians, song writers, and producers, as well. This reminds me of Paul Graham's recent post on startup ideas that spoke to this concept. As Charlie puts it, he feels better knowing you're a player in a big industry than knowing you've dominated a small one. Even if you're focusing on a niche user base at first, make sure you make it known you're going to be expanding during your pitch.

Now for the life advice.

Not everyone is meant to be a founder. On that note, strive for being at the top of your field in your industry in your location. If you're a UI/UX designer, attend events, meet new people, and expose your work to the world. More often than not, the person that does the great work at a company is behind the scenes - let people meet you.

I've been meaning to start a blog for months now. I planned on building the entire site and blog together then launch it all at once. I was counting on an uneventful weekend for a mini hackathon in my apartment and get it all done. That never happened. Instead, I am overcoming builder's pride (that's what I call the phenomenon of feeling like you must build everything, even if re-inventing the wheel, just because you can - more on this in a future post), and starting my blog here on Tumblr. Here goes nothing.

I'm a developer, born and raised in New York City. I went to school here and have lived here all my life! I love NYC and being exposed to other US cities has further strengthened that - except for Boston (I'm a huge Red Sox fan - there will be a future post on the origin of this as well). I have honed my developer chops at the LIRR, The Daily, and now, Acadaca, regularly partake in hackathons, enjoy running, and spend my day-dreaming time thinking of ingenious names for hacks and side projects.

So there is my background, now on to the goods. What can you expect from this blog? To answer that question, I first need to explain this blog's title - Full Stack Thoughts.

If you're a member of the Technology industry, you might have heard the term Full Stack Engineer before. This job title implies the aforementioned engineer works on all facets of the web stack - server configuration, server-side code, and the entire front-end code (Javascript, HTML, and CSS).

How does that translate into explaining this blog? Well, I'm not going to limit the scope to just tech posts that developers would find interesting. Instead, I plan on writing about brain-storming product features, designing the user experience, writing manageable code, and my experiences in creating a startup all from a technical founder's perspective. Among exploring all the facets of creating a service, I will also touch on sports, some policies, and life.