Hacking .NET and Startups

Live by “Fuck you, pay me;” Die by “Fuck you, pay me”

March 25, 2013 18:57 by Aaronontheweb in Development Teams, Hiring, Startup // Tags: , // Comments (0)

I came across a blog post by Michael Halligan on Hacker News last week entitled “Benefits matter, or why I won’t work for your YCombinator start-up.” As a fledging entrepreneur trying to attract senior engineering talent to my startup, his post bothered me immensely. I spent about a week mulling it over before I decided to write this.

Michael’s attitude in the post is abrasive, needlessly cynical, and mercenary, but well-argued on its pure economic merits. He describes himself on his own blog thusly:

I'm just this guy who used to enjoy tech, now I would rather build bicycles. I still work in the tech industry, for the money, but I no longer call myself a "technologist".

And he ends his blog post with this call to action for other senior technologists like himself:

To all of my colleagues with whom I have been in the trenches, please repeat after me, "Fuck you, pay me."

This paints a picture of someone who’s been burned before by startup flameouts; who’s put in 100 hour weeks without seeing any life-changing financial benefit; who has real financial obligations like children to put through school; and lastly, a little burned out with his career.

It wouldn’t have bothered me so much were it not for the boorish cheerleading from scores of Hacker News commenters, which indicated to me that this attitude may be more widely held than I would have believed (more on that in a second.)

I really appreciate Michael being so honest about it, because I suspect that this is an attitude that neither he nor any of the supportive Hacker News commenters have ever had the balls to actually express in a verbal salary negotiation with a flesh-and-blood human being like me sitting across the table.

What bothers me about Michael’s post and the Hacker News comments is the cynical view of founders and employers; it dehumanizes them to self-interested profiteers who don’t give a shit about the people who work for them. And the attitude I grok from Michael’s post is “developers: don’t give a shit about [your employer / the founders] either – tell them ‘fuck you, pay me.’”

Let me show you why this bothers me. Here is my honest to God list of things I care about with respect to MarkedUp in order of importance:

1. My personal integrity – because startups are not things of life or death themselves, but integrity is one of the few character traits that outlives the man or woman.

2. The financial health of the company – because a failing company isn’t in a position to serve anyone well, whether they be founders, customers, employees, or investors.

3. The well-being of MarkedUp’s employees – because they are present and future of the business, and I’m going to spend more time with them than my own family.

4. The experience of our customers – because our customers trust us with important information they need to run their own businesses, and we are our own customer.

5. My personal well-being – because I have I dreams of my own but I know that getting items 1-4 right on this list leads to the realization of #5.

I’m sure that if Michael or any of the Hacker News commenters read this list they’d scream “bullshit!”

I treat the growth and well-being of my employees as a non-negotiable requirement for my own happiness and satisfaction, but that conflicts with the Hacker News worldview of the VC-land profiteering dipshit douchebag 27 year old founder (I am, in fact, 27.)

I hire people whom I want to invest in – sure, like any startup we have short-term needs that have to be filled. But the long term health of any business that’s being built to last depends on a high trust culture – where employers and employees interdepend on each other.

I’d crawl over glass for the full time people on my team who take work off of my plate and enable the business to grow – I need them. They support me, so I’d better damn well support them when they need it. I’m making sure they get important benefits like healthcare and the best compensation that I can afford – everything within the bounds of what’s economically feasible for an early stage company of our size and funding level.

I’m invested in MarkedUp’s employees – and when we’re not able to support an employee’s needs I feel like I’ve personally failed as a manager and employer.

So this brings me back to “Fuck you, pay me.” I would never hire anyone who doesn’t want to invest in our product, the other people on the team, and in the company as a whole – because I can’t depend on them to be there for me and everyone else when things aren’t going perfectly. They’d be the first to bounce and the first ones to put the screws on me and their teammates in a bind. I’d never be able to make a person with this attitude happy, so I’d never try.

“Fuck you, pay me” is a self-fulfilling prophecy that will doom you to work for exactly the sort of employers this attitude is supposed to save you from – the kind who won’t invest in you and don’t care about you. When you open the conversation with an employer with “fuck you, pay me” you’re telling them that you don’t give a shit about the product or people, so why should they care about your well being again?

You’ll be passed over for every promotion, every project of any import, any conference or occasional perk, and your opinion will not be solicited or valued on anything that doesn’t pertain strictly to your role. Your teammates will resent you for being unavailable and disinterested. Your managers and executives will treat you with all of the mercenary courtesy and cynicism with which you’ve treated them.

A job is a lot more than a salary and benefits – it’s about enabling people to be happy, employers and employees both. Anyone who comes to work with the attitude of “fuck you, pay me” is miserable by default, an assertion you can validate with a single read over the front page of Michael’s blog. There is little I can do as an employer for someone who is innately miserable. And that makes me sad and frustrated.

Throughout the course of your career you will inevitably deal with shithead employers who don’t appreciate you – quit and move on. Don’t make the situation worse by deciding not to appreciate all employers regardless of who they are – you’ll just alienate the ones who actually want to help you even if they can’t match another employment offer you have on the table.

If money and benefits are literally the only thing that matters to an employee, then they’re worse than the self-interested greedy founder stereotype described earlier. At least the greedy self-interested founders had the balls to take some risks.

So look at your employment opportunities this way – there’s a lot more to working somewhere than just the tangibles. That’s why developers, sales people, and marketers regularly take below market salaries to work at startups – because they get the rare chance to shape the work environment into one that will make them happy.

Happiness is what matters, and benefits + salary shouldn’t be the only factor at the expense of culture, colleagues, creativity, and self-ownership.

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

Migrating from RavenDB to Cassandra

February 20, 2013 11:30 by Aaronontheweb in RavenDB, Cassandra // Tags: , , // Comments (4)

Today on the MarkedUp Analytics Blog I authored a post entitled “Cassandra, Hive, and Hadoop: How We Picked Our Analytics Stack.”

In it I explain MarkedUp’s evaluation process for choosing a new database, how we selected Cassandra, and some benchmarks from our test. If you want to learn more, go read it.

I’ve written about RavenDB in the past on and I’ve spoken about it at code camp before. I think it’s a great technology for prototyping and it has some really interesting concepts not found in any other database that make Raven really simple and elegant to operate.

So I wanted to copy over a section from our blog post about building MarkedUp on Cassandra which explains why we ultimately needed to move away from RavenDB:

Looking back to what went wrong with RavenDB, we determined that it was fundamentally flawed in the following ways:

  • Raven’s indexing system is very expensive on disk, which makes it difficult to scale vertically – even on SSDs Raven’s indexing system would keep indexes stale by as much as three or four days;
  • Raven’s map/reduce system requires re-aggregation once it’s written by our data collection API, which works great at low volumes but scales at an inverted ratio to data growth – the more people using us, the worse the performance gets for everyone;
  • Raven’s sharding system is really more of a hack at the client level which marries your network topology to your data, which is a really bad design choice – it literally appends the ID of your server to all document identifiers;
  • Raven’s sharding system actually makes read performance on indices orders of magnitude worse (has to hit every server in the cluster on every request to an index) and doesn’t alleviate any issues with writing to indexes – no benefit there;
  • Raven’s map/reduce pipeline was too simplistic, which stopped us from being able to do some more in-depth queries that we wanted; and
  • We had to figure out everything related to RavenDB on our own – we even had to write our own backup software and our own indexing-building tool for RavenDB; there’s very little in the way of a RavenDB ecosystem.

So based on all of this, we decided that our next database system needed to be capable of:

  1. Integrating with Hadoop and the Hadoop ecosystem, so we could get more powerful map/reduce capabilities;
  2. “Linear” hardware scale – make it easy for us to increase our service’s capacity with better / more hardware;
  3. Aggregate-on-write – eliminate the need to constantly iterate over our data set;
  4. Utilizing higher I/O – it’s difficult to get RavenDB to move any of its I/O to memory, hence why it’s so hard on disk;
  5. Fast setup time – need to be able to move quickly;
  6. Great ecosystem support – we don’t want to be the biggest company using whatever database we pick next.

So there you have it. If you want to learn more about our migration to Cassandra, check out our original blog post.

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

10 Reasons Why You’re Failing to Realize Your Potential as a Developer

Since going full-time on my own startup 6 months ago, I’ve spent a lot of my time recruiting, evaluating, and working with a lot of different developers. My startup, MarkedUp, is an analytics provider for Windows 8 apps (and eventually, other platforms.)

Our technology is sophisticated and difficult even for large companies to master, so the bar is pretty high for developers who join our team. We’re selective about who we work with, but even with careful recruiting practices it’s still difficult to find developers talented enough to pull their own weight on a complex product like ours.

So I want to help average developers who want to improve by calling out 10 performance-killing behaviors that stagnate the careers of most developers.

Most developers stagnate both intellectually and productively after 4-5 years in industry; they adopt some tools, pick up some patterns, learn a language or two, and maybe they’re even able to work at a successful company and contribute to some important products. Great!

But what happens when you hand a developer a blank sheet of paper and the opportunity for them to own a product?

Most of the time: chaos and failure.

Many developers fantasize about being able to own a product and make big technical decisions, but the truth of the matter is most of developers can’t handle anything more complicated than building formulaic CRUD Rails websites using the same 30 gems each and every time.

So what are the behaviors that limit the growth of average developers?

You’re too afraid of failure to learn new tools / languages / frameworks.

During my first quarter at Microsoft I gave a talk to the LA .NET User’s Group on ASP.NET MVC3, which was in beta at the time. For the most part the attendees asked me thoughtful questions and showed a legitimate interest in what the ASP.NET team was cooking up in Redmond.

However, there was a trio of attendees who kept asking me a very suspicious set of questions:

“What are the weaknesses of ASP.NET MVC3?”

“Isn’t ASP.NET MVC too unstable for use in the enterprise?”

“But doesn’t ASP.NET WebForms already do a better job?”

I realized shortly after the Q&A was finished, when I had a chance to speak to them privately, that they were attending my talk to actively look for reasons why ASP.NET MVC shouldn’t replace WebForms at their place of work!

These developers were so afraid of trying something new and possibly failing that they actually went out of their way to research just the talking points they needed to not have to learn it!

This is an extreme example, but the point is the same: average developers cling to their favorite tools and stop learning new ones because they worry that leaving their pet languages and tools behind invalidates their years of experience.

Strong developers embrace the challenge and opportunity to learn new ways of doing things.

You won’t push your commits until the feature is “done.” (It’s never done!)

We call this “commit hoarding” at MarkedUp. This happens with developers who don’t have the confidence to tolerate criticism or scrutiny from the rest of the development team try to hide their work until it’s in a “finished” state.

Ultimately these developers hurt the productivity of the rest of the team, because we lose visibility into their daily output and they tend not to ask for help in the course of regular development. They’re responsible both for delays in shipping and for lots of last-minute bugs.

Strong developers recognize that they are not their code, and thus will put code out in front of the rest of the team more frequently and take criticism and suggestions with dignity and confidence.

You know just enough to be dangerous.

In an age where it’s become a lot easier for developers to work with threads, concurrent programming, distributed databases, and so forth you run into a lot of devs who can talk a good game. They can tell you all about thread pools, a hot new design pattern, or why a headless database is better than a masterful one in some scenarios.

They are able to know what something is and its potential benefits, but they don’t understand it.

I’ll give you a recent example: in C# 5.0 Microsoft recently introduced the async and await keywords, which make it radically easier to create and manage asynchronous callbacks. These keywords have even lead to the rise of some exciting new concurrent programming patterns like the TAP pattern.

However, do you know what this keyword has also lead to? A ton of average developers who suddenly think they can harness the awesome power of multithreading simply by wrapping every I/O call into a Task object in C#. They do this blindly, without any thought as to the costs of context-switching, multi-thread access to shared resources, and more.

And this creates dangerous, unpredictable, and very-difficult-to-test code in the hands of average developers who blindly uses this new toy everywhere.

Good developers not only know what something does, but they seek to understand why it was done this way and under what conditions it should be used.

Analysis paralysis.

Gandalfing the Documentation

Sometimes you’ll hear a member of our development team say “dude, stop Gandalfing the documentation and start coding something,” referring to the scene from The Lord of the Rings depicted above.

Analysis paralysis is a classic problem that affects lots of average developers; it’s often a problem of over-analysis, but in my experience the root cause is usually fear of making a bad decision.

Research is easy – implementations are hard! As a developer, you don’t want to make a mistake when it comes time to do the actual work. So just research the issue until the heat death of the universe and you’ll make a perfect decision for which you won’t ever be criticized!

Average developers worry about looking bad or making a mistake – they want to get it right on the first try.

Strong developers who are in unfamiliar territory don’t care – they’ll write shit code, unit test it, and throw it away in 45 minutes if they don’t think it can get the job done. Strong developers actively limit the amount of time they spend researching, because they recognize that it’s a trap – it feels like work but often isn’t.

You don’t invest in your tools or development process.

Average developers will spend a lot of time learning how some fancy new language feature or API works. They’ll invest a ton of time mastering the minutia of the Windows runtime or some new D3-based charting framework, but at the end of the day that doesn’t change the fact that they’re still average developers who churn out mediocre work at a glacial pace.

If you want to be a talented developer, you have to invest time into improving your skills and knowledge, and the number one factor that separates the men from the boys in most software markets is the ability to turn out production-grade code quickly. You can have both good code and speed – but you have to invest in your process you use for building it first!

Average developers don’t invest in their tools, their process, or their environment.

Think about it – when was the last time you took a step back and thought about the way you test your code or how you look for bugs? Have you tried experimenting with different types of abstractions for the same problems and seen which one produces more maintainable code? Have you tried picking up a new IDE or text editor to see if it can help speed up common tasks? What about investing in build or deployment automation?

Often times, the biggest improvement you can get as a developer isn’t focusing on improving the code you write – it’s optimizing your process for writing it.

Free protip for anyone who follows my blog regularly: the biggest improvement I’ve made in my own development process easily is decreasing my usage of interface-driven design and dependency injection. I do a lot more work using static classes and compositions these days and it results in radically less code to test and maintain.

You’re too embarrassed to ask for help.

When we started digging into the guts of Hive for some of our work at MarkedUp, we got a little stuck on how to tackle some problems we had specific to our use case. So what did we do? We reached out to one of the guys who wrote the O’Reilly book on Hive and asked him over LinkedIn. And he replied back!

We try to be self-sufficient developers to the furthest extent possible, but we also know when it’s more economical to simply ask someone for a favor versus beating our heads against our desks for hours on end.

Average developers get embarrassed and don’t want to reveal their ignorance, so they pretend they know what’s up until they commit some sort of horrible fuck-up in the codebase itself.

There is nothing wrong with saying “I don’t know how to do this.” Strong developers know this, so they go and ask for help when they’re stuck.

You don’t know how to make it easy for other programmers to work with your code.

Like an only child growing up, you never learned how to share your toys with anyone else. The same goes for your code – you developed some bad habits and an over-abstracted style that is impossible for other developers to follow.

An important part of working on any technical team is human parallelism – the ability for multiple people to be able to work simultaneously on the same codebase. But it’s also important for teams to be able to work asynchronously too – I should be able to make changes to your code when you’re away, and vice versa.

Average developers don’t think about their code this way – they simply set out to do a task and write it through to completion with the assumption being that they will always own that piece of code. Strong developers understand technical debt and try to limit it by designing code that is as maintainable and self-explainable as possible.

Writing readable code really requires developers to change their outlook – your code should last longer in the organization that you.

You don’t know how to read someone else’s code (or don’t want to.)

It’s an interesting paradox – average developers can’t handle a blank sheet of paper very well, but they can’t write the last 30 pages of a novel in progress either. Average developers are really hesitant to try to learn an existing codebase and often have to be handled all the way through it until they’re able to produce something.

A drastic example is when an average developer is brought in on a codebase written in a language / framework that they aren’t familiar with and will immediately want to rewrite it without a second thought to business value or time to market. It’s a type of pain avoidance – having to live with the precipitation of some other programmer.

Strong developers accept that the business costs in a rewrite are usually unacceptable and should be avoided, and they’ll diligently try to understand, learn, and modify the existing codebase sitting in front of them.

Reading code is harder than writing code, but strong developers invest time into learning how to excel at it.

You can’t code from the end-user’s point of view (you think too small.)

Average developers who manage to make it a lot closer to the “great programmer” end of the bell curve usually trip up here. You may have mastered some of the technical details and you may know how to work with other developers, but you’re still missing the most important piece: being able to see your code from the point of view of the real-world.

As a programmer, you job isn’t really to solve technical problems – you solve technical problems in order to solve business problems.

An average-to-bad developer will chase technical problems down deep rabbit holes without remembering why they were solving the problem in the first place. You’re not upgrading the version of MongoDB you’re using because there’s inherent value in upgrading – you’re upgrading because your team agreed that it was worth taking the risk to upgrade because of potential business upside due to new features / performance / reliability / whatever.

More offensively, average developers struggle and fail to produce anything of business value from scratch. When asked to design a new feature based off of a simple customer story average developers will take a rigid, literal interpretation of the story or spec and ship something that is barely useable by a human.

Average developers don’t anticipate other related use cases; don’t think about the end-user’s experience; and basically have to be managed heavily when working on anything user-facing. This is why so many of them get stuck writing line of business apps instead of products.

Great developers look at their code from the perspective of the end-user. How do I make this easier to solve my user’s problem? What are some other facets outside the literal content of the story that might make this feature even better for an end user?

If you’re a developer and don’t ask yourself these questions, then you’re not a great developer. You’re passable at best.

You aren’t able to judge the business value of any programming task.

Related to the previous issue – many technically strong developers fail to realize their potential due because they aren’t able to take a step back and look at their work from the perspective of the business or organization itself.

Strong developers are able to self-manage and make good business decisions about how they choose to invest their time. They’ll ask questions like:

Is this the most valuable thing I should be working on right now? How much time should I invest into doing this? Given the deliverables I have due in two weeks, is there something I can invest in right now that will make it a lot easier for me to hit that target?

Average developers don’t – they’ll take a spec and blindly implement it until it’s finished, without accounting for how their work relates to the company’s business goals and impacts other members of the team / other business groups.

The highest cost of any engineering team is development time, and average developers waste lots of it on minutia and technical tasks that are ultimately low business value.

Wrap up

If you want to be a better developer, it starts with changing the way you look at your code and how you program.

You have to understand and appreciate the business costs behind each line of code you write. You have to be able to step outside of your text editor or IDE and look at your work from the perspective of a customer or end-user.

You have to accept that your code will outlast you in any organization your work with, so design everything to be inherited by other developers one day.

Most importantly, never be afraid to take on new challenges and ask for help along the way. You won’t improve working alone in the corner on technologies you’re already familiar with. Software development is inherently social – learn how to bring other people into the experience.

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

Be Your Own Measuring Stick

December 3, 2012 15:54 by Aaronontheweb in Startup // Tags: // Comments (1)

Today was one of those days when it was nearly 1pm before I was free to sit down and make my daily to-do list. There was water damage in my apartment, one of our awesome engineering candidates took an amazing job offer with a top video game studio instead of us, and I was way behind on all of the PR / marketing stuff I’m doing because we haven’t hired someone for the position yet. Typical, stressful day in the daily life of an early stage startup CEO.

So I sat down at the counter of a diner near our accelerator and started writing down my daily to-dos in the nearly-full, leather-bound Moleskine notebook I’ve used to keep myself and my thoughts organized for the past couple of years.

I just happened to open my notebook to an entry from 11/12/2011 (about a year ago) entitled “Skills I Want to Acquire.”

At the time I wrote this piece I was 15 months into my career at Microsoft and had just finished off a stressful pre-Thanksgiving crunch period, and I was starting to think about what I would need to learn in order to run a new startup.

I remembered how I felt when I wrote it – desperate to try my hand at starting a company for the second time1, but unprepared by my own standards.

I wrote this list as a roadmap to prepare myself for startup #2:

Skills I Want to Acquire – 11/12/2011

  • How to work with a team of developers
  • How to manage developers operations
  • How to manage a product lifecycle and iteration
  • How to measure customer engagement and how to incorporate those learnings into product design
  • How to build an online revenue channel
  • How to build a production + web and mobile service
  • Natural language processing + machine learning
  • How to build a developer platform / API
  • How to build a team
  • How to quickly prototype ideas and test them in market
  • How to manage a team
  • How to raise capital
  • How to acquire early customers
  • How to do great front-end development
  • How to build a brand

To be clear: these are all things that terrified me.

These are things I didn’t know or think I would be good at, but I knew I needed to learn them in order to realize my goals.

Today I went through this list and made the following notes:

Skills I Want to Acquire – 11/12/2011 updated 12/3/2012

  • How to work with a team of developers – done
  • How to manage developers operations – done
  • How to manage a product lifecycle and iteration - done
  • How to measure customer engagement and how to incorporate those learnings into product design - done
  • How to build an online revenue channel – done
  • How to build a production + web and mobile service – done, at scale
  • Natural language processing + machine learning – not done
  • How to build a developer platform / API – done, at scale
  • How to build a team – done
  • How to quickly prototype ideas and test them in market - done
  • How to manage a team – done; will be a lifelong process
  • How to raise capital – done
  • How to acquire early customers – done
  • How to do great front-end development – in-process
  • How to build a brand – done, but different than I expected.

To my immense pleasure, I had learned how to do most of these very scary, unfamiliar things in just a year! Of course I haven’t mastered them all yet, but I’m at a point where I feel confident that I can do any of these things competently at any time for our company and our team.

Given my day to day responsibilities at MarkedUp, I can’t imagine a world where I don’t know how to do most of the things on this list; it’s remarkable to think just a year ago that all of this stuff was alien and frightening to me.

Seeing this list and thinking about the progress I made from a year ago made instantly lowered my stress level and reminded me just how much progress one can make in a relatively small amount of time. It made me forget about all of the things I tell myself I’m doing wrong every day.

You are the ultimate judge of your own success, and I judge myself as having a really successful year so far.

If you want to do something hard like start your own company, start by sitting down and making a list of the things you need to do in order to get there, start trying to do them, and then review your progress against goal. You might be really surprised with how far you can get in a short period of time!

Now I’m going to get back to work on the next set of things I know I need to learn…

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

Get a Grip

November 20, 2012 20:25 by Aaronontheweb in Startup // Tags: // Comments (0)

My regular source of entrepreneurial catharsis is watching Deadliest Catch.

If you've never seen it, it's a Discovery Channel show that follows four-six actual fishing vessels during two different Alaskan Crab fishing seasons a year (King and Snow.) “Bering Sea fisherman” is considered to be the most dangerous occupation in North America, hence the name.

Many of the crab boat captains are entrepreneurs themselves, being part or full owners of the boats. If the boat stops fishing, they go broke. If the boat breaks down, the fuel / parts / labor / time cost comes out of the crew and captain’s cut.

Deadliest Catch - fishing vessel coming down a 30-40 foot wave The captains are constantly put into situations that your average tech entrepreneur can relate to: dealing with emergencies, constant HR issues, having to make strategic bets on incomplete data, the emotional rollercoaster, you name it. The viewer watches the captains struggle with these decisions in every episode, and it’s as much of the experience and drama as the harsh nature of the Bering Sea itself.

What puts Deadliest Catch in perspective for me is this: people actually get maimed and even die on that show.

Boats get capsized by 60 foot rogue waves; deck-hands go overboard never to be found again during uneven seas; or get crushed by 1,200lb steel crab pots falling from a four-story tall stack. The fishermen’s lives, in addition to their livelihoods, are always at stake and are lost with regularity.

Back in the universe of technology entrepreneurship, the most danger I'm in everyday is getting carpal tunnel or eventually putting on weight due to poor diet and lack of exercise. No matter how hard things get, even if I fail epically, I’m not at risk of dying as a result of anything that can happen at any tech startup.

In one column: death, in another column: average health and with well above-average opportunities.

When I read maudlin stuff like today’s “The last day” short story on Pando Daily (with all due respect to Francisco Dao, a friend), I can’t really take it seriously.

I’ve failed a couple of times already in my short career thus far, including a big public flop in front of a number of my classmates when I was in college – and you know what?

You experience total humiliation and vulnerability when something you created falls apart, and that’s how you’re supposed to feel if you cared about what you did.

But dead startups aren’t things of life or death themselves – you’re not going to die; your stock will only rise as a result of what you did at your startup provided that you didn’t do anything unethical; most of your friends will admire you for having the balls to try something on your own in the first place; and you’re going to have a chance to try again.

It’s hard to ignore the self-critical things we all whisper to ourselves as entrepreneurs; they’re sometimes a healthy and necessary gut-check against reality, but more often than not they’re just self-destruction mistaken for self-motivation.

So don’t be so hard on yourselves and be the first in line to kick your own ass, because your market / customers / employees / investors / co-founders / competitors will all have plenty of chances to do it for you. Accept the occasional beating as an inevitability and recognize that the one thing you can always control is how you choose to react to things you cannot.

And now, I think it’s appropriate to share a little wisdom from Deadwood:

Deadwood: Al's Take on Misfortune

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

5 Key Themes from Microsoft on the Future of Windows and WinRT from the //BUILD Keynote

I posted this originally on The MarkedUp Analytics Blog, going to put an excerpt here and then link you to the original post.

1. “Microsoft can only win by training consumers to expect consistent behavior, availability, and synchronized data across all of their different devices”

WinRT isn’t just about tablets – it’s also about fundamentally changing the way desktop software is consumed and unifying mobile / desktop / tablet and probably console apps all under one consolidated platform.

The unification of these platforms is the future of Microsoft; training consumers to expect consistent behavior and access to data across all of their devices is the only way Microsoft will be able to dethrone Apple and Google in mobile / tablet and protect themselves in desktop / console in the long-run.

Ultimately, Microsoft is really the only company that can execute well on native software, services, and devices. They are playing to their strengths (ecosystem and platform) and are doing it well here.

Click here to read the rest of “5 Key Themes from Microsoft on the Future of Windows and WinRT from the //BUILD Keynote” on the MarkedUp blog.

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

New Features We’ve Added to MarkedUp: Custom Event Reporting and Reliable Crash Logging for Windows 8 and Windows Phone 8 Developers

MarkedUp - Analytics and Insights for Windows 8 DevelopersI haven’t posted much about my startup, MarkedUp, over the past couple of weeks on this blog (although I’ve been quite busy on the MarkedUp blog) so I figured it was time for an update on the company and product itself.

To recap, MarkedUp is an analytics service designed to help Windows 8 and Windows Phone 8 developers manage and monetize their Metro applications in the Windows Store.

MarkedUp is the only analytics platform available for WinRT and Windows 8 developers that supports full compatability with both WinRT and WinJS.

So what have we been up to since we launched MarkedUp back in late September?

Other than bug fixing, collecting user feedback, and acquiring users – we went to some lengths to add a couple of important new features to MarkedUp, both of which we released this week.

New Feature: Tracking and Measuring Custom Session Events

By far the most frequently requested feature among our early beta testers, this is the one that we’re most excited about: MarkedUp’s ability to track custom events and actions unique to your application.

how to use MarkedUp to track custom session events for your Windows 8 applications 

Custom session events are something you’d want to use whenever you need to track a metric specific to your app.

Let’s suppose you’ve shipped a video game – don’t you want to know how many games or levels a user plays each time they start the application?

Or maybe you created a content-reading application like my Lolcats Professional Pro Plus application for Windows Phone 7 – don’t you want to know how many pieces of content a user consumes on average?

Custom events can be used to track both of these – simply call MarkedUp’s SessionEvent method wherever something you want to track in your Windows 8 application occurs!

New Feature: Capturing Crash Logs and Unhandled Exceptions

The Windows Store gives you the ability to look through crash dumps, all in one inconvenient, giant dump file that you have to parse yourself.

We are a little dissatisfied with that approach to crash logging and analysis, and so are many of MarkedUp’s beta users. Thus, MarkedUp now has the capability to log crashes and analyze them via our convenient reporting interface.

how to use MarkedUp to log and analyze crashes for WinJS and WinRT applications

Logging crashes using MarkedUp is really easy to set up, and we describe how to use MarkedUp to log crashes and unhanlded exceptions in WinRT and WinJS here.

How to Get MarkedUp Analytics for Windows 8 for Free

Right now MarkedUp is completely free while in beta, but we’re restricting access to the platform through the use of registration codes.

However, I think it’s about time I gave everyone who reads my blog some love.

If you want to register for MarkedUp Analytics for Windows 8 for free, click here and use the following registration code: AARONONTHEWEB

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

Thoughts on Recruiting Developers at Early Stage Startups: Determining Who’s Right for Your Company

I posted a little while ago about the job market for technical talent at early stage companies, and I promised a follow-up post on what you should look for in a developer when your company is at a critical, early stage. This is that follow-up ;)

Our company, MarkedUp, is still in the process of building out its early engineering team; however, we’ve had some success in finding the right type of people we want to work with – a process that wasn’t quick or easy, but will pay off massively in the long run.

When it comes to hiring developers for your early stage startup, here are the questions you need to think about:

1. What are you optimizing for?

At this stage in the evolution of MarkedUp, we optimize for changeability and reliability – the ability to change things on the fly quickly and do it in a way that doesn’t interrupt the service of our customers.

This means that we have to recruit people who are architecturally sound with .NET, are able to learn new technologies quickly, and are good at socializing / articulating problems and design considerations to the team.

When we evaluate a developer for who’s considering joining our team, we look to make sure that they have experience with multiple technology stacks, have a well-written technical blog or are at least conversant in their respective technology areas, are versed in design patterns and can explain their architectural thought process on-demand, and have well-defined goals with regard to how they want to grow and develop.

For your company, you might need to optimize your engineering team differently – if you’re building a big consumer app, you might need to optimize for developers who have a good balance of front-end and back-end skills initially.

Make a deliberate choice about what your engineering priorities are and let that set the top of the spec for your recruiting.

2. Do you need soldiers or chiefs?

One mistake a lot of startups make is the seniority issue: hiring people who are too senior or not senior enough.

People who are too senior might demand a lot more equity / money / power / titles early on in the life of your company, which creates problems if you ever need to bring in even more senior people over them if you don’t manage it correctly. Additionally, senior developers bring a career’s worth of habits and experience into your company – which isn’t always necessarily good.

Conversely, evaluating a fresh-out-of-college CS grad to CTO isn’t a great decision either sometimes – they might not even know just how horribly they’re screwing up your company’s technology until years after the fact.

On top of the issue of experience, you also have to consider the person’s ambitions – do they want to be an executive in the company one day and have people reporting to them? Are they even capable of doing that one day?

Again, make a decision: do you need people with experience and authority who will lead the engineering team or do you need people who just want to do the right thing and make a difference, but don’t yet want to be involved in management? Recruit accordingly.

3. Can your company afford to train developers on your technology stack?

Do you need people who’ve been working on a single technology for 5+ years, or just people who are smart and want to learn?

If you’re a really early stage company, then you don’t have the luxury of time or money to invest much into a new employee who is totally unfamiliar with your chosen technology stack.

If you have the time and money to invest into training good employees, do it.

Investing into training will widen the pool of acceptable applicants dramatically because you can tailor your recruiting process to target a smaller number of things. Be realistic about your resources and the availability of your existing engineers to train the new folks, and then decide accordingly.

4. What’s important for your engineering culture?

You know what makes a huge difference in MarkedUp’s culture? Being passionate about development – we like people who have pet projects in their spare time; take the time to learn new languages and platforms; and love to talk about what they’ve done and what they’re doing.

We build products for developers – passion for development makes us more relatable to our average customer, who is typically someone building a Windows 8 application in their spare time because they love doing it.

Your company may be different – you may want to recruit people who are really into music if you’re building a media-oriented company, or people who are very algorithm / math-oriented if you’re doing a lot of work in a field like NLP or predictive modeling. Maybe you want to run a really structured environment and want people who are going to be in the office every day.

Company culture is ultimately something that will take a life of its own, organically, but during the formational stages you have a massive amount of influence over it as a founder. Pick people who fit your vision for what the culture should be and be conscientious about it.

5. What’s your level of urgency?

Trick question. The answer is “super urgent” in every early stage company. Unless you’re profitable / growing, every day is a race against the clock and the bank account.

You can’t afford to keep people around who don’t get that and won’t work hard to make sure the hard problems are solved on-time.

A lot of developers, particularly ones who’ve been in industry for a while, approach startups with the expectation that they can still work from 9-5, get the same benefits they got at MegaCorp for some relatively low level of output, but get a giant chunk of equity and work on cool, consumer-facing startup products without any bureaucracy or managerial overhead. Avoid these developers.

Hire people who want to race the clock, because they believe in your company’s vision and want to work with other competent people who can move quickly. They’re out there.

Parting Thoughts

If you do a good job coming up with clear, thoughtful answers to these questions then good fits and bad will be obvious.

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

What It Takes to Actually Ship a Piece of Commercial Software

Last week our startup, MarkedUp, hit the first important milestone for an early stage technology: we shipped the first version of our analytics product and put it into the hands of actual end-users.

For those of you who don’t read my blog regularly (pretty much everybody, I suspect,) MarkedUp provides in-app analytics for desktop application developers. We’re focusing our company’s initial efforts on supporting Windows 8 and WinRT developers specifically.

Now, we still haven’t completely opened the doors to everybody – we’re capping registration for MarkedUp through the use of invite codes while we gather important UX feedback and reports on bugs we may have missed.

Nonetheless, we hit that important milestone and have live users! Yay!

However, here are some interesting facts about the timeline leading up to our ship date:

  • We were feature complete, with high test coverage and few known issues, a full two weeks before we were able to ship;
  • We didn’t have a design for the marketing parts of our site, like the homepage, until 48 hours before our launch;
  • We actually cut features from the product the night before our launch;
  • We started the process of gathering user feedback when we were about 50% finished with the first version of the product – by then we had demoable charts and tables (features of our analytics product) we could show to target users.

We weren’t able to ship for two weeks, two weeks (!) after we were feature complete – and we cut features the night before we shipped? Are we a bunch of crazy incompetent bastards? No!

Shipping Software: More Than Just Code

This wasn’t my first time participating in the ship process for a piece of software, but this was my first time running it.

I suspect my opinion on this will change the more often I do it. In my estimation, the time it takes to design, plan, and code the core product and its features constitutes only 40% of the actual work required to deliver a software product to market.

So, what were the things we spent our time doing leading up to launch?

Great question, I’ll break it down by category:

  • Feature development and functional testing – 40% of time;
  • Pre-launch UX testing and refinement – 20% of time;
  • Creating a demo application – 5% of time;
  • “Marketing engineering” – time spent coding features responsible for driving users towards conversion goals – 10% of time;
  • Graphical design / branding (largely outsourced) – 5% of time;
  • Writing documentation, tutorials, and setting up support infrastructure – 10% of time;
  • Writing and proof-reading marketing copy – 5% of time;
  • Planning and executing roll-out marketing – 2.5% of time;
  • Planning and executing roll-out software release – 2.5% of time.

One thing to bear in mind about these numbers – this was for a soft beta launch, not a top-down, TechCrunch-style launch. The amount of time spent on things like roll-out marketing is astronomically higher for a massive top-down launch.

What’s the trend here? Most of the the time we spent working on the product was spent on usability issues.

Like Jeff Atwood says, your app is merely a collection of details. There’s really two classes of details that matter:

  • Details that affect how the user engages with your product and
  • Details that affect how the user understands your product.

Marketing engineering, demo apps, copy writing, and graphical design are all investments we made into helping make our product easier to understand.

Documentation, support, and UX are all investments we made into helping make our product easier to use.

The bottom line here is that the auxiliary stuff needed to support your product, like documentation and support infrastructure, take a lot of time to do well. They’re as much a part of your user’s experience as the software is itself.

Shipping the Right Features at the Right Time

So we cut features right before we shipped, literally 24 hours before I pushed to production – why?

The answer is simple: we have specific goals for what we want to learn about our users with this version of our product. Any feature that we considered to be too unpolished, too complex, or too distracting was cut – even if we had a reasonably good implementation of it ready to deploy.

Every software release should be purposeful and careful – if you overwhelm your users with too many features and options during the first release, your user feedback gets diluted across that feature set and you never get a chance to learn what you are fundamentally doing right or wrong!

If you ship a bunch of poorly implemented features, you might churn through all of your early users way faster than expected and have to subsequently work harder to acquire enough users for the next iteration. If you ship a bunch of “distracting” features, you detract from the feedback that really matters to your business.

Ship software with the intent to learn and test very specific things in that release. Don’t ship for shipping’s sake.

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

Thoughts on Recruiting Developers at Early Stage Startups: Understanding the Job Market

September 23, 2012 12:03 by Aaronontheweb in Hiring, Startup // Tags: , , // Comments (0)

Shortly after leaving Microsoft to work on MarkedUp full time, my founding team and I joined an early stage accelerator here in Santa Monica. We’ve gotten a tremendous amount of value from it so far, and the directors of the accelerator have done a great job helping me prioritize and do all of the things I need to do in order to launch MarkedUp properly.

One of the things they’ve had us do is gradually step up our recruiting efforts, and for the little we’ve invested into the recruiting process so far the results look pretty good.

Most startups at this early stage are founded by 1-2 people who have unique insights and connections into a market, have done some work to validate a new business concept in said market, and are now trying to form a team to help them execute and eventually scale it. Usually the first hire a startup has to make is a founding engineer who can help them build a customer-ready version of the product.

MarkedUp is a little different. Our engineering team is the entire team, at the moment – I’m also our “business guy” in addition to being the technical lead and Erik, a founding member of our team, is 100% committed to technical endeavors. However, we still have to recruit developers! MarkedUp is solving a big, complex problem1 – analytics and data visualization are problem domains with large technical surface areas, so even early on in the lifecycle of our company we have to expand the engineering team.

I’ve been asked a couple of times recently by founders in the first category of startup “how do you find and recruit developers?”

The short answer is “I’m still figuring this out, being new to running a startup myself, but here are some ideas.”

So in that vein, I thought I would share with a wider range of people how I try to recruit developers for MarkedUp and what I think is most important.

Take everything I say with a grain of salt – I’m new to running my own company and am figuring out much of this as I go.

Things You Should Know about the Market for Software Developers

Before you start recruiting, you should wrap your head around the market for software developers. Having this information will decrease the likelihood of you making an ass out of yourself when you start recruiting in earnest.

1. It’s an employee’s market – there’s far more demand for developers than there is supply.

The demand for developers has always been high since the PC revolution and the past few years have been particularly high. So what’s the practical implication for your startup?

The answer is that any competent developer in the US can get a six figure salary, with amazing benefits, from a variety of well-funded, stable employers. Before you even start recruiting you’ve already lost the battle of benefits and compensation.

So when you’re recruiting, don’t even bother leading with the promise of wealth, big exits, or any of that sort of puffed-up-chest nonsense. The reality is that most startups fail and if any developer evaluates the prospect of working for you versus their six-figure employer, you will assuredly lose on opportunity cost every time.

2. All of the competent software developers you want to hire already work for someone else. Not only do you have to convince them to join you – you also have to convince them to leave a paying gig. 

Let that sink in for a moment. How hard is it to leave a job? If you give a shit about what you do, then the answer is “pretty hard.”

Convincing someone to leave a gig, even if you have a great opportunity that is more interesting, is a challenge unto itself unless that candidate is utterly miserable with the state of things at their current job.

So, be prepared for a long, dragged-out process for each technical hire – you will have to deal with counter-offers, ludicrously good counter-offers even. Don’t hardball your candidates with “join us now before we raise money and offer you less equity” – keep them sold on the things that money can’t buy: working on projects that they find meaningful, working with people they like, learning new things, and so on.

3. The best source of “available” developers are recent graduates.

If you followed point #2 above, then what I’m about to say next should resonate: the best source of developers who are openly looking for work is recent college graduates.

Many of them get passed over by big software development shops like Microsoft / Google / et al because they don’t have enough time behind the wheel; this is exactly what happened to me when I was graduating from Vanderbilt with good grades, a successful freelancing track record, apps in market, and good recommendations.

On top of being available, recent grads have the absolute best risk profile for working at a startup. They have no obligations, no mortgages, no expectations of six figure salaries out of the gate – they just want to work on something cool and take home enough money to start building a life for themselves.

There is a downside to hiring recent grads, however: having no experience means what it means! You’ll have to invest a lot of time into training them all of the things they didn’t learn in school, which in some cases includes the ability to code.

Truth be told, I only recommend going the route of hiring recent grads if you already have a CTO or another veteran onboard who’s willing to train and coach them.

It’ll take a while before you can get an acceptable level of output out of a recent grad, but as long as you continuously invest in making your new hires better they will (1) stick around because they’re learning and improving and (2) will deliver output at startup speed.

4. It is phenomenally easy to start a company and raise money in 2012 compared to earlier years, and the most senior technologists who fit the risk profile for startups are able to start their own companies. 

One important facet that’s overlooked about the technology market for software talent, especially among startups, is just how easy it is for top-tier technologists to start and launch their own companies.

All of your prospective founding CTOs who are interested in startups and have an idea they’re really committed to could probably raise money and build a v1 product themselves; so how does this affect your ability to recruit?

It dilutes the market for talent – spreads the small slice of the Venn diagram of all developers who are willing to work for free on a high-risk idea across a much larger number of smaller companies. So what’s a startup founder like you to do?

Invest some effort into helping any talented developer who’s trying to build their own company be successful, because even if that developer is unavailable to help ease your pain now they’re someone you want to build a good working relationship with and maybe work together later.

I never try to steal someone away from a project they’re deeply, personally, and fully committed to, nor do I ever suggest something stupid like merging two totally irrelevant ideas together into one company just so we have more developers on the team. Recognize that recruiting is a long-running process – it takes a long time to find the right people.

It’s in your best interest to be someone developers trust, not a self-interested jack ass who constantly tries to poach them away from their passion projects.

“Pay it forward” is my advice here, and for your short term needs – don’t even bother with people who are trying to get their own projects started. If they decide to can their project, they’ll come and approach you if you’re someone they trust and would want to work with eventually.


I’m going to write a second post on our philosophy when it comes to actually recruiting developers and what we think is important.

1MarkedUp provides in-app analytics for Windows 8 and WinRT developers. You can sign up for a beta at http://markedup.com/beta

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



My name is Aaron, I'm an entrepreneur and a .NET developer who develops web, cloud, and mobile applications.

I left Microsoft recently to start my own company, MarkedUp - we provide analytics for desktop developers, focusing initially on Windows 8 developers.

You can find me on Twitter or on Github!

Recent Comments

Comment RSS

Sign in