Team first.

Earlier this week I made a pilgrimage up to the Bay Area to visit some mentors – I came seeking advice from entrepreneurs who’ve done work relevant to our interests at MarkedUp, mostly to learn how to address some “known unknowns” that have been keeping us up at night.

One of the people I had a chance to speak to is an experienced CTO and we started talking about development priorities in early stage companies like ours. Mid-way through our meeting we had the following exchange (paraphrased:)

Me: so I’m trying to figure out my priorities in terms of what I personally spend my time working on – I have to juggle recruiting, product, fund-raising, customer development, project management, and working on the actual codebase all myself until we start expanding our team.

CTO: what have you been working on most recently?

Me: this weekend I learned how to script against a build system we want to use to help automate the complexity out of our deployment process; I prioritized that ahead of working on MVP features and am not sure how I feel about it.

CTO: two startups ago, we were building a service in the telephony space. We had a lot of trouble recruiting engineers who knew anything about low-level telephony protocols – they were hard to find, thus we had trouble expanding our team.

Ultimately what I decided to do was to build an abstraction layer on top of all of the telephony protocols themselves, our goal being to simplify the amount of work a developer on our team had to do to make things happen with our service.

What this allowed us to do was recruit younger, smart people who had no prior experience at all with telephony systems – and they were able to be successful in our development team because they could get the work done without the overhead of having to learn these telephony protocols. And this solved our recruiting problem.

The lesson here is fantastic, and I suspect lost on a lot of engineering team leaders: if you have only one place to spend your (development) time, spend that time on tasks that increase the effectiveness of everybody else on the team.

So this past weekend, I spent my time:

1. Developing a component that takes an easily-fuck-up-able task from our application runtime and makes it more predictable and reliable and
2. Learning a build system that we are going to use to make our build and deployment process standardized, predictable, and less dependent on human factors.

Turns out, working on those things instead of developing a handful of features necessary for our MVP was the right call – even though it’s painful to defer work on the product with impending deadlines looming. It was the right call because it eliminates errors and speeds up the work of every person on the team, including me!

If you enjoyed this post, make sure you subscribe to my RSS feed!

In the course of some of our work on MarkedUp, we discovered an interesting gotcha with MVC4, embedded views, and ASP.NET pre-compilation.

A little back-story:

One of the things we did as part of a major refactoring recently was to pull all of our email templates out of the main MarkedUp MVC4 project and stick them into their own independent assembly – we did this because we anticipated that these templates would have to be shared across multiple web distinct web applications running behind our firewall.

We use ActionMailer to generate our text and HTML emails from Razor templates, and one of the things that broke with MVC4 is the RazorEngine project which was used by ActionMailer.StandAlone to parse Razor templates in non-MVC4 assemblies.

So, what we did in this instance was embed our Razor views directly into the child assembly and wrote our own VirtualPathProvider to serve them from the MVC4 application – a standard practice for handling this sort of thing.

We started running our staging and development versions of our app this way without thinking twice about it.

Eventually, when we wanted to speed up our staging server’s rendering performance on AppHarbor we enabled ASP.NET pre-compilation. And since it was just our staging server with just us on it, no one noticed that our email volume dropped to zero.

Until we started bringing aboard a small number of friends to help us test our service, which is when we noticed the error.

When you turn on ASP.NET Pre-Compilation, the underlying virtual path changes and will change the behavior of your custom VirtualPathProviders.

Hence, our custom VirtualPathProvider was no longer able to find our embedded views. Doh!

If you enjoyed this post, make sure you subscribe to my RSS feed!

Now that I’m running my own company and no longer speak on behalf of Microsoft or anyone else, I feel like I can speak a little bit more freely about some of the things I’ve observed about people at startup companies over the past couple of years.

I worked with close to a hundred companies in some capacity as a Startup Developer Evangelist – some much more closely than others, but nonetheless had a chance to live vicariously a lot of different companies in different markets run by different types of teams with different types of people on them.

Regardless of all of those differences, there’s one thing that a lot of these founders had in common: the less disciplined and experienced founders manage to waste a lot of their time and energy on things that are counter-productive and others that are actively self-destructive.

Here’s seven really unproductive habits that I want to call out in particular.

1. Attend and spend money on countless “startup” events without goals or regard for opportunity cost

My father, an experienced serial entrepreneur, offered up a single rule for me to heed above all others when I started working at Microsoft: “guard your time, jealously.”

Your time is at a premium, particularly during a pre-funding / pre-launch stage – you can’t afford to waste it on things that don’t provide value in some way. The first thing I’ve skipped since going full-time on MarkedUp? Every event that is non-essential; my evenings and weekends are reserved for production deployments or blowing off steam.

There’s consensus among many people in the startup community that “meetings are pointless” – and that’s often true of internal meetings. So what are events?

They’re external meetings – there’s nothing special about a tech event that makes it magically productive. You have to weigh the costs of going against what you could be doing instead, which most startup founders do not.

Be honest with yourself about the value you want to get out of an event – if you’re going there to work a room and generate leads, then it’s probably worth it. If you’re going to go because you just want to “network” and don’t have any real sense of purpose about it, then don’t bother. Go talk to customers instead.

2. Waste enormous amounts of time on “omnidirectional” networking with no real purpose and promise of value in return

Corollary to time wasting behavior #1 – networking with no real purpose.

Networking when done right takes a lot of time – it’s not as simple as collecting up a truckload of business cards at a conference, carpet bombing those poor saps with LinkedIn requests, and watching your stock rise.

What networking should be about is:

• Seeking out potential business partners, mentors, advisers, co-workers, investors, etc…
• Qualifying the ones who are interesting;
• Establish your credibility (so they can qualify you;) and
• Finding mutual benefit in working together.

The process of building credibility and qualifying takes time – so, why spin up a bunch of threads with people who aren’t the right fit to help you accomplish your goals? Just so you can say “oh, I know X” at one of those stupid events you should be avoiding?

Pick your battles – if you’re going to go through the trouble of networking, do it like you mean it and mean it when you do it. Don’t be that clueless person in the middle of an event handing out business cards to people who don’t need you and you don’t need.

Figure out who you need and pursue those people.

3. Buy crazy expensive booths at startup conferences

Take it from a guy who’s had to work booth duty for a company who can afford the big ultra-delux booth at TechCrunch Disrupt: the booths are worthless.

Unless you’re demoing something tangible that will get people’s attention (MakerBot being a really good example,) you’re better off spending that money on literally anything else.

MarkedUp won a free booth spot at LAUNCH conference due to our performance at Startup Weekend Los Angeles, and we happily signed up. The booth traffic we got was modest – the real value we got out of the event was talking around and working the room.

Every startup should probably try this once – it’s like touching a hot stove or oven: everybody needs to do it one time to know not to do it again.

4. Chase top-down media coverage and press way too early

How many entrepreneurs do you know who’ve stated “getting covered on TechCrunch” as a PR goal?

This is going to sound kitschy but it’s true: the secreting to getting covered by a giant tech blog like TechCrunch is not to try.

Don’t waste time trying to pitch under-developed stories to writers swamped with a glut of press releases from professional PR firms – build something unique and interesting, build interest organically, and the story will start to sell itself.

You’ll still have to put some effort into managing your messaging and top-down marketing at some point, but it’s absolutely the wrong place to start. Your pitch won’t seem like a quixotic / desperate marketing goose-chase to the bloggers if you’ve executed well and have some momentum.

Getting top-down PR for your startup is just like raising money – the conversation starts with a vision and the close comes with traction.

5. Fretting over equity when your company isn’t worth anything

It’s a good thing when an entrepreneur takes the ownership of their company seriously – avoid anyone who doesn’t. However, taking it too far and being miserly with equity during a stage when you’re cash poor and equity rich is both naive and counterproductive.

If you can find a great CTO / biz dev person / designer / product person who believes in your idea enough to be willing to work without pay for months in the name of getting equity, you should be mind-blowingly thrilled.

Congratulations: you’ve just met a really talented person with super high risk tolerance and a tremendous amount of passion for your company’s vision; that’s like wandering the Sahara for days only to stumble upon an oasis with a 5-star resort in the middle of it.

So why screw up a beautiful thing by trying to lowball the person over a few percentage points of ownership interest in your company?

Ditto for early investors and advisors – if you find some competent angels and advisors who are really passionate about your work and are able to put a little bit of money in, err on the side of equitability.

There will come a point where the equity is worth more than the cash, and it will become obvious when that is the case and you’ll be right to preserve the ownership interests of the other stakeholders as much as possible.

6. Dismissing friends and family who commit the crime of “caring about you”

When I reached out to friends who worked at startups over the past couple of years, I was occasionally dismissed with a sentence along the following lines “I’m sorry, I’m just not available – you just don’t know how hard it is to work at a startup.” I’m certainly not the first person to be told that.

I try to have a sympathetic ear as often as I can, but every time I hear this it thoroughly pisses me off because (1) everyone has to deal with grinds and long nights and (2) stress is no excuse to be dismissive to family or friends (people who care about you.)

I’m no stranger to 12-14 hour days – I worked plenty of them at Microsoft and my first startup before that. And being human, I sometimes did a poor job of getting back to people in my life who wanted to hear my voice. That’s one of my biggest regrets over the past couple of years. But even under a great amount of stress, I don’t surrender to exhaustion and say something stupid and hurtful to one of my friends or family members who wanted to check in on me.

You need the help of a lot of other people to pull off a startup successfully. I screwed this up in a major way with my first startup. However, caving into pressure and pushing your friends and family away takes you from neglecting your relationships to actively doing harm to them.

If you’re going to take on something as arduous and demanding as a startup then have the maturity, class, and discipline to bear it like an adult, rather than a child out of his or her depth.

7. Sacrificing nearly all social, physical, and personal needs in the name of “getting it done”

You can push yourself to a large volume of work over a short period of time – you can cram 80 hours into a work week if you can try. But you can’t do it forever.

You know what a successful entrepreneur needs?

They need to work out and get sleep so they can maintain their stamina and energy level. They need to go out with friends and blow off steam. They need to go out on dates. They need “me” time to collect themselves.

Creating a balanced life takes discipline – I dropped the ball on this epically at Microsoft. I starting changing my behavior before I left Microsoft and it’s made me more effective and productive.

When you feel the pressure around any product launch or fund-raising activity and start sacrificing everything else in the name of “getting the job done” all you’re really doing is panicking with a long fuse. Burying yourself in work indefinitely isn’t a virtue – it’s surrendering away the life you’re trying to improve in the first place.

And ultimately it’s a self-fulfilling prophecy: if you keep burning the candle from both ends too long, you’ll eventually fail.

8. Writing cathartic blog posts when you should be reaching out to customers and closing Github issues

Shit. I need to get back to work.

If you enjoyed this post, make sure you subscribe to my RSS feed!

One of the things we have to do at MarkedUp on a routine basis is test the live HTTP endpoints for our data collection APIs, and some of the data structures we upload are multipart-form POSTs that contain some complex objects (log messages with nested exceptions, etc…)

The tool we decided to use to test our API, particularly as our API changes during this early stage of our company, is the amazing Requests library in Python – which makes the process of cobbling together these complex form-encoded objects and testing them against a live HTTP endpoint bearable. I developed an in-house command line tool using Requests, argparse, and a few other built-in Python libraries to make the process of performing endpoint testing easy and repeatable for myself and the rest of the team.

However, given that we primarily work in a .NET environment and on Windows systems, my teammates sometimes get stuck figuring out how to get Python set up properly.

Since I’ve had to reinstall Python on Windows every time a new release of Windows 8 came out (including the RTM version this week) – I can say with certainty I’ve got the process down to a science.

So, without further adieu – here is how you set up a proper Python development environment on Windows.

Step 1 – Install the Python 2.7.* or 3.* Binaries from python.org

You can download the latest Python bits here from the official Python homepage.

I typically install Python 2.7.* via the Windows x86 Installer and that is what I recommend. I'd avoid the x64 installer - many of the Python libraries and compiled binaries do not play nice with 64 bit architectures. Here's a direct link to the release page for the latest version of Python as of writing this (2.7.3) - it has an X86 installer.

One bit of background for those of you unfamiliar with the Python ecosystem – Python 2.7.* and Python 3.* are totally different animals, and the majority of the Python OSS and package ecosystem still hasn’t caught up to using Python 3 yet.

There were a large number of breaking changes introduced to the Python core language runtime in 3.0 and as such it’s taken the community years to catch up. For all intents and purposes, I usually stick with Python 2.7 in all of my projects that depend on it and have never run into any issues.

Once you’ve successfully run the Python installer, you should see the following icons appear in your start menu or if you’re using Windows 8 like me, on your home screen:

Once you have access to the Python command line and IDLE, you’re ready to move onto step 2.

Step 2 – Add the Python 2.7 Directory to your System Path Environment Variable

In order to make it so you can access Python via any command line prompt (and not just the Python-specific one), you’ll need to add the newly-installed Python 2.7 directory to your “Path” system environment variable. This makes it easier to access Python and run scripts in whatever shell you’re using to using (Command Prompt, PowerShell, and my personal favorite: Git Bash.)

So, go to Control Panel –> System Properties –> Environment Variables and select the PATH variable from the list below:

Click Edit

And append the Python path to the end of the string – the default path will be something like C:\Python27.

Also make sure you include the C:\Python27\Scripts in the Path too even if it doesn’t exist yet – this is where your package management tools, unit testing tools, and other command line-accessible Python programs will live.

With that in place, you can now start the Python interpreter on any command prompt by invoking the python command. Let’s get our package manager set up for Python.

Step 3 – Install pip to Manage Your Python Packages

There’s a couple of different options for package management in Python – pip is the one that doesn’t suck.

Pip makes it trivial for us to install Python packages, like Requests. And we’re going to have to install packages pretty often if we’re working with third party tools and libraries, so this is a must-have.

Pip has a detailed set of instructions on how to install it from source – if you don’t have the curl command on your system, just use your Git or even your web browser to download the source file mentioned in their instructions.

Step 4 – Install virtualenv to Create Local Python Environments for Your Projects

Once you have pip installed, you need to grab one last package – virtualenv.

Packages in Python are installed globally by default – which means that when a package dependency changes for one project running in a given Python environment, it changes for all of them. Not good!

virtualenv restores order to the universe by allowing you to create virtual Python environments, so you don’t have to worry about version conflicts between projects.

And now that you have pip up and running on your system, it’s trivial to install virtualenv via the command line:

C:\> pip install virtualenv

And you’re done!

Bonus – Install scaffold-py to Easily Create New Python Projects

Ok, shameless plug, but this is what I actually use for creating new Python tools and scripts for production use at MarkedUp – I wrote a pip package last Summer called scaffold-py which allows you to auto-scaffold new Python projects from the command line, just like Rails or Express projects.

From the readme:

Each project you scaffold will create the following directory structure:

/[projectname]/
/[projectname]/setup.py
/[projectname]/bin
/[projectname]/docs
/[projectname]/[projectname]
/[projectname]/[projectname]/__init__.py
/[projectname]/tests
/[projectname]/tests/__init__.py
/[projectname]/tests/[projectname]_tests.py

Both setup.py and [projectname]_tests.py are set up automatically to reference your project name as a module. The rest is up to you!

To install and use scaffold-py run this command:

C:\> pip install scaffold

C:\> python –m scaffold –p “NewProjectName”

If you enjoyed this post, make sure you subscribe to my RSS feed!

I thought this was an interesting side-effect of Microsoft’s decision to surrender on the trademark dispute around “Metro,” so I figured I would reblog this from the official MarkedUp blog.

original link: The MarkedUp Blog - New Change in the Windows Store TOS: Any App with the Word “Metro” in the Title is Insta-Failed.

And here’s an excerpt for you:

So imagine our amusement today here at MarkedUp HQ when Erik reviewed the Windows Store “Before Your Sell Your App” guidelines and discovered this gem in the section regarding how to name your Win8 applications* (emphasis ours:)

Note  Make sure your app name doesn’t include the word metro. Apps with a name that includes the word metro will fail certification and won’t be listed in the Windows Store.

Looks like our friends at MetroTwit and other popular ported WP7 applications (many of which include the word “Metro” in the title) are going to have to undergo a similar rebranding to “the New Windows UI” or whatever we’re calling Metro now.

This news makes me glad that I only stick to application names that mock the old-school way Microsoft named products!

If you enjoyed this post, make sure you subscribe to my RSS feed!

I’ve spent my last two weeks at Microsoft wondering how I was going to write this blog post.

Microsoft recruited me off of Hacker News two years ago. In the Summer of 2010 I was still brushing off the ashes of my first failed startup when I wrote a blog post about some of the challenges the .NET community faces with respect to adoption among startups, which subsequently got a ton of attention on Hacker News and inside of Microsoft.

Ultimately, this was the start of an amazing two year journey at Microsoft as a Startup Developer Evangelist. I relocated from San Diego to Los Angeles and built a new life, met scores of wonderful people, worked with some of the absolute best startups on the planet, and honed my skills as a technologist and software entrepreneur exponentially further than they were when I attempted my last startup.

I love my job; I love my team; I love the developers / startups / accelerators / investors I’ve worked with; and I learned reams of applicable real-world stuff from people far more experienced than I. However, it’s time for me to do something different.

Today, August 10th 2012 is my final day with Microsoft. It’s been a life-changing experience and I have few regrets about what I’ve been able to accomplish with my time here.

It’s not easy to leave something when you (1) kick ass at it and (2) love doing it, and few people ever make that leap. But I’m going to, because I don’t give a single iota of shit over the risk of failing at something new. I’m much more afraid of getting comfortable and never trying anything dangerous at all. You only live once.

What’s Next?

Starting on Monday I am assuming my new role as the Founder of MarkedUp, a new startup company which will provide Windows 8 and WinRT developers with analytics and insights on how they can make their applications better.

I couldn’t be more excited to pursue something new and to have a chance to do something I’ve wanted to do since I graduated: build a company that ships products made by developers for developers.

I love the .NET ecosystem and our team at MarkedUp is committed to delivering tools and services these developers will absolutely love. We have the right tools, the right people (more on that), and the right expertise to deliver a kick-ass experience which will help WinRT developers build better apps faster.

If you’re building a Windows 8 or Windows Phone 8 application then you should sign up for beta updates from MarkedUp and follow MarkedUp on Twitter.

We’re based in Santa Monica and we will be hiring additional developers soon. If you’re interested in hearing more about what we’re working on email us at team@markedup.com.

Parting Thoughts

The past two weeks have been humbling for me. I spoke individually to all of my co-workers and the startups I worked with closely about my future plans for MarkedUp, and the outpouring of support and genuine excitement for us has been beyond my wildest expectations. I couldn’t be more fortunate to have met and worked with such terrific people.

While I’m sad to no longer be on the same team as my amazing co-workers and manager, I am absolutely thrilled to be pursuing my own startup and betting on the success of Windows 8 independently.

I’m going to work my ass off to build a company developers love and stands the test of time.

Money, exits, and glory do not mean jack shit to me if they aren’t the byproduct of delivering exceptional value to customers and building a team that is absolutely in love with its own work. This is what I am now setting out to do – wish us luck!

If you enjoyed this post, make sure you subscribe to my RSS feed!

I have an internal reporting interface for one of my Windows Phone 7 applications that shows me more or less how much of the app is getting used every day, and I developed the reports using the eternally awesome jqPlot charting plugin for jQuery.

I generate three line plots on my main reporting page by dispatching three AJAX queries on-page, all of which are just a {Start:#date, End:#date} set of arguments. The ASP.NET MVC controller action method that receives the query then builds a time-series for me spanning that range and returns the result set over JSON, which is used to finally render the charts. Basic stuff.

My charts render beautifully in Chrome and Safari, whereas they never displayed at all in IE. I figured it was just an issue with the jqPlot plugin, despite the fact that it boasts great backwards compatibility with IE.

But then I used jqPlot in another project last week and had no issue viewing the charts in IE, so I figured something else must be up with IE and my site.

The first thing I did was analyze the responses I got back from my controller methods that were supposed to be generating the time-series, and I noticed this on IE via Fiddler:

500 Internal Server Error

The parameters dictionary contains a null entry for parameter 'start' of non-nullable type 'System.DateTime' for method 'System.Web.Mvc.JsonResult PictureViews(System.DateTime, System.DateTime)' in 'LolcatsAPI.ManagementSite.Controllers.StatsController'. An optional parameter must be a reference type, a nullable type, or be declared as an optional parameter.

So the ASP.NET MVC ModelBinder doesn’t like what I’m sending to it, but only in IE? I wonder what’s up…. Time to check in with my old friend Fiddler again, but this time I was going to see what the outbound requests looked like in both browsers.

And that’s when I saw the problem (looking at the raw outbound arguments)…

Chrome

start=Mon%2C+18+Jun+2012+07%3A00%3A00+GMT&end=Thu%2C+19+Jul+2012+07%3A00%3A00+GMT

Internet Explorer 9.0

start=Mon%2C+18+Jun+2012+07%3A00%3A00+UTC&end=Thu%2C+19+Jul+2012+07%3A00%3A00+UTC

…. Internet Explorer was setting my time zone as “UTC,” which .NET’s native DateTime object does not recognize as a parsable time zone, hence why the controller was failing.

As it turns out, JavaScript’s Date.toUTCString() method behaves differently in WebKit vs. IE – the former returning a “GMT” time zone and the other a “UTC” time zone, the latter of which can’t be parsed back into a .NET DateTime. Front-end development is merciless!

If you enjoyed this post, make sure you subscribe to my RSS feed!

And patience. This is intended for people who recognize that a need to change themselves, their environment, or whatever and are having trouble getting started.

Until last month, all of the books in my Kindle collection were exclusively technical.

Whenever I travel for work and spend two hours uncomfortably seated between obese strangers and screaming children, I fire up the iPad and delve into a world of exciting subjects like Spatial Data Analysis in SQL Server 2008, the Ruby programming language, ASP.NET MVC3, iOS development, NoSQL Databases, and so on. Behold the “traveling with Aaron Stannard experience” in its full glory.

Before a business trip to Boulder I loaded up The Flinch in my Kindle collection because it was (1) free and (2) I had read someone somewhere say that this was a life-changing book. Whatever. I set about my business, had a good day of work in Boulder, and on the return trip home I fired up the iPad and started reading.

The Flinch delivered on its second-hand promise of being life-changing… The basic premise of the book is this: all people are born with a very small number of built-in reflexes. Loud noises make us tremble, high pitched cries make us look for children and people who are in distress, and “the flinch” is there to protect us when are in immediate danger.

The flinch isn’t just the physical cover-up-with-your-hands reflex you had when Tommy Tommerson tried to drill you in the crotch with a kickball line-drive in 3rd grade – it’s also an inertial force that stops you from taking potential risks and making changes. Do I really need to explain what’s wrong with feeling resistant to taking risks and making changes? Fine.

As I hinted in my last post about our first post-collegiate years and as Paul Graham spelled out explicitly in his  “Top of my Todo List” essay – our biggest life regrets are errors of omission. Drifting apart from great friends, finding out years later that the hot girl from English class thought you were cute but you were too much of a pussy to make an advance, not taking the job at the early stage startup that made it huge, not staying close to a family member who passed away suddenly, and the list goes on.

The reason you let this stuff happen is because of the flinch – the flinch speaks to you in your own voice, rationalizing reasons why you shouldn’t pick up the phone and have an awkward conversation with your sick relative or why dating is a waste of time. It makes you feel comfortable sticking with the status quo and tells you “you’re fine, you don’t need to change.”

In the ancient days, when changing your routine might mean getting eaten alive by a Sabre-Toothed Tiger because you decided to go hunting in an unfamiliar part of the woods, the flinch was a good self-preservation instinct.

Today, what’s the biggest danger you can possibly run into? Being the one out-of-shape fat person struggling with the Stairmaster at 24 Hour Fitness? Dear God, anything but that!

The flinch gets in your way more often than it helps. It stops you from making the sorts of changes you need to realize your goals. It drives unwarranted compromise and needless caution.

So how do you overcome it? Like anything else worth doing, you practice.

More abstractly: overcoming your aversion to risk takes practice and effort – the very real physical and psychological reflex that your body and mind impose on you when presented with a risky choice must be unlearned by way of repetitive exercise.

I’m great at taking risks with some things and not so with others. I’m not as averse to risk in some areas because I’ve developed a competency for risk-taking through repetitive effort; in areas where I suck at taking risks it’s because I’ve spent years rationalizing away my need to practice and improve.

After I returned home from Boulder I set about making some long overdue changes. I started exercising again. I reconnected with some old friends. I started teaching myself things I’ve needed to learn for years but had told myself “no Aaron, you suck at X.” Fear of taking even minor risks, like the self-awareness you feel the first time you work out in twelve months, is an everyday thing that can (and must) be overcome.

The most impactful thing I’ve tried is a recommendation taken directly from the text of The Flinch itself – I’ve started taking cold showers. It’s initially uncomfortable and you’ll feel the flinch kick in as soon as you turn the dial on the shower, but it’s a start to programmatically overcome the fear. I thought it sounded stupid (if you find yourself saying this a lot, you might just be afraid of whatever it is you’re describing) but I tried it anyway and have stuck with it.

It’s a struggle to push aside something as deeply programmed as the flinch, because it’s our natural default. But we do it because the things we want require us to sack up and overcome it.

If you enjoyed this post, make sure you subscribe to my RSS feed!

This is intended for recent graduates who are finding themselves lost in the shuffle as they adjust to the real world, but has advice that is applicable to everyone. Your mileage may vary.

I graduated from Vanderbilt University with a B.S. in Computer Science in May of 2008. I was a Cum Laude student and a member of Sigma Nu (a fraternity.) I rebuilt the student embodiment of IEEE & ACM back up from scratch into a meaningful, attractive organization inside Vanderbilt’s engineering school, and did it alongside some really wonderful and amazing people. I helped rebuild Sigma Nu, lived in the house for a time, and met fantastic people who will be some of my lifelong friends.

The four years I spent in school were life-changing for me and completely reshaped me into a much more confident, balanced person than I was going in. I have few regrets.

The four years after I graduated have been disorienting – I’m not in a structured social environment anymore where everyone is new and eager to make friends. I have conference calls at nine in the morning. I need to renew my auto insurance. I have three weddings that I have to go to this Summer and I’m 90% sure I won’t fit into my old pair of dress pants.

I’m fortunate that I live in a country where I don’t have to worry about clean water or getting my head cut off, but that first world self-assurance doesn’t make the transition to adult life any less jarring.

The most bothersome part about being an adult is a moment that occurs 1-3 years after you don the cap and gown.

Here, I’ll set it up: you got your first job or two and have busted your ass nonstop trying to build a life, income, and home for yourself. You haven’t gotten blackout drunk with your friends “because it’s Tuesday night” since graduation. You haven’t done any travel beyond seeing family and maybe a small trip here and there. You’ve grown apart from many of your college friends as you all went your separate ways, both geographically and professionally. You’ve settled into some routines that give you some sense of control over things, but you still aren’t really cooking for yourself or exercising enough (as your mother will tell you.)

With that picture in mind, here’s the moment that brings it all home: during the course of a regular day, maybe when you’re at work or just coming home, you rediscover a piece of your personal history directly from the time when you were at college – and you start thinking about what’s elapsed between then and now. And a wave of private humiliation starts to well up inside you… my life is a lot smaller than what it used to be, isn’t it? Not going out there and changing the world yet exactly are am I? And my, what a boring person I’ve become!

It’s the moment where you realize that you’ve unknowingly started to cast a boring mold for your future – and you start to mourn all of the ambition and optimistic hopes you held when you were in college. You start to doubt the path you’re on and wonder, sometimes out loud, if you completely wasted the years of your life after college. You worry about sounding like an entitled, whiny bitch if you complain about it to anybody save your absolute closest friends, and thus deal with your torment in private.

Relax. Everyone goes through this – you’re not alone, and it’s scary for everyone too. It doesn’t mean you’ve screwed up or made poor choices, and there’s no point in worrying about that anyway since you only live once. Heed the moment for what it really is: your sub-conscious telling you “initiate adulthood, phase 2!”

Adjusting to adulthood isn’t easy – if it were there wouldn’t be any coming of age movies and Workaholics wouldn’t be hilarious.

College doesn’t prepare you for the ambiguity of real life – it gives you some of the tools and weapons to figure that out yourself in an economy where people are valued based on knowledge (rather than the ability to wield a shovel.) It takes a few years to figure out “where the bathroom is,” if you pardon the metaphor, before you can really go on to do the stuff that you were born to do.

The moment is a call to arms, crafted just for you. It means you’ve figured out what it takes to survive outside of the corner room in your parent’s house; you’ve got some money and some workplace experience; and you’ve a certainty that things are not where you want them to be. And you have no obligations to anyone or anything, save some manageable debt and a lease that expires in 7 months.

The moment means the time to make your life the way you imagined has come – don’t screw it up. Quit your job and start a company; go traveling; marry that girl you’ve been dating steadily for three years; take up surfing; whatever your dreams are, do what it takes to realize them.

This won’t be the last time you have a major moment of “oh shit what am I doing?” either – take them for what they are: indicators that you’re ready to advance and change. Go do what it takes to be interesting and optimistic again now that you’ve conquered the banalities of adulthood.

If you enjoyed this post, make sure you subscribe to my RSS feed!

This past weekend at SoCal Code Camp I presented a session along with my friend Nuri Halperin entitled “Battle of the NoSQL Databases: RavenDB vs. MongoDB.”

I represented the RavenDB team, having used it in production now for a couple of months (and ditched Mongo to do it.) I’ll blog more about the specifics of RavenDB and what it’s awesome at some point in the future, but nevertheless I wanted to post my slides here so you could see the bullet-by-bullet comparison between the databases.

We didn’t cover everything, but we did try to capture all of the high-level details:

If you enjoyed this post, make sure you subscribe to my RSS feed!