I haven't had more than about 10 minutes to process this so I don't have a ton to say, but... Am I the only person who didn't know that most self storage facilities in the us are actually just giant real estate investment trusts? I have had a long-running joke with my brother (we come from a long line of hoarders) about quitting our jobs to open up a self-storage facility.

Aside from shattering all my dreams, I'm disappointed that using a REIT to finance this sort of endeavor had never even crossed my mind. I mean, it makes total sense. The capital structure a REIT provides (readily accessible, dirt-cheap debt) gives them one hell of a competitive advantage over any sort of mom-n-pop organization. Sorry, bro.

Throw an ice cube into the beginning of a class iv+ stretch of river. Now, write an algorithm that predicts (in real time) the magnitude and direction of every movement of said ice cube. Now, apply that algorithm to a bucket of randomly sized ice chunks and apply a transformation to each movement that represents taxes, fees, etc. and accounts for real-world issues like network hops and liquidity.

Or, you know, give up on that and write an equation that outsmarts the other guy's equation.

Of course, I haven't spent enough time on this to know what I'm talking about (I've found that once I reach a level of competence on a topic I wouldn't dare blog about it because I realize how little I actually know about that topic) but it is fun to think about and yep, this is what I've been thinking about lately.

I have noticed my friends and colleagues who have had success are different than those who have not. Here, by success, I mean they are able to develop in the languages and frameworks they like the best while being able to hold down a job or book of business with minimal compromise. The difference is the successful devs are able to set ambitious, achievable, and measurable goals, and see their projects through to the end. That is, they wind up building a usable piece of software that installs and runs with minimal fuss. Whether it be a library, framework, or app, it provides a good percentage of wanted functionality out of the box.

What stops more devs from being successful? There is this fear of missing out or falling behind that is pervasive in our industry. Setting goals and committing to them is scary. What if you fail? What if a new language shows up or a cool new framework? What if you work on the wrong thing and no one cares? What if you get tired and abandon the project before it is ready? I call that fear induced by the what-ifs.

Here is what my successful friends do - They commit to their goals and see them through no matter how many what-ifs they make up along the way. They hold off on the immediate gratification of learning a new language or switching out frameworks. They don't waste a lot of time trying that fancy new editor because they know that sticking to their release schedule is more gratifying in the long run.

Money and popularity are a part of the success equation, no doubt about it. A dev cannot bury their head in the sand and pretend they live in some dev utopia where they get food and shelter just for being awesome. With that said, if you don’t make a significant income from your project, you will most certainly have to work a day job. This takes time and energy away from your project so your project will not be as good and therefore will have a higher probability of failure. That’s why you must try to make money from your project.

Imagine it this way - the fact that your project is making money means that it (or you) are providing some real value and inspiration to your users. This is about the most pure (i.e. bullshit proof) metric that exists. And, in some ways, one of the best tests you could possibly write. In fact, I always have a test called generates_cash_flow_test() in my harness.

Excitement and passion will only take you so far. At some point you have to build something and see it through to the end. Organize a concentrated and prolonged assault on business and do everything you can to gain and maintain momentum. This stuff is not magic - grind it out until you have your success.

I found myself sitting in an airplane seat when this question popped in my head of ouf nowhere. The timing was good - I had plenty of it to entertain the question. I'm not going to lie, I do not like the answer.

An amazing programmer may eschew an ide for vi. They optimize to the hilt and use the latest and greatest tools for the job. I have forever wanted to be that guy. The one who doesn't have tmux and vi cheat sheets taped to his monitor. The one who uses arch linux and a tiling window manager like Awesome. As circumstances go, I cannot be that guy. Instead of worrying about fast runtimes, I tend to worry about cash flow. Instead of doing it right the first time, I tend to push an 85% solution to production as fast as possible to impress a paying customer. I worry about using the latest frameworks because I don't know if I'll be able to hire someone with that skillset when we lose the guy who decided to use it and probably wrote 90% of the code.

Do I want to be an amazing programmer? In theory, yes! I'm an algorithms guy. My first real language was Scheme. In college I wrote x386 assembly on paper and did it without making any mistakes. So, what happened? My priorities have changed, it is as simple as that. I'm excited about erlang, but I'm more excited about optimizing for the 100th, then 1,000th, then 1,000,000th customer. I love thinking about what taking VC money really means. I love cultivating a circle of people who I can call for advice on convertible notes. I spend a lot of time thinking about what certain strategies look like on a cap table and what signals they send to the public.

Do I want to be an amazing programmer? Apparently not. It seems like I want to be an amazing business person instead. I don't yet have a solid definition of what that means but I know I'm headed down that path. Follow your passions, they say, and that's exactly what I intend to do.

I will never let go of my programming roots. I strive for a balance between code (building great products) and business (building frameworks that promote selling those products.) I don't want to be a functional programming mascot thinking about monads all day, nor will I be a businessman who spends the day thinking about how hiring lobbyists could help my product maintain a monopoly in the market. I think being a success requires a little bit of both those sides. So, that is what I'm doing.

I'm working on a blog post about what I think it takes to be a successful dev where "Success" is defined as being able to create a useful project that adds value.

UPDATE: It took until 2015-06-01 to write it - look for the entry titled "The Paralysis of What-ifs"