Awesome, so here’s the deal. Now is a pretty good time to buy real estate. Even Warren Buffet said that if he could get the logistics figured out, he’d buy up a bunch of houses. The only thing stopping him is the inefficiency of dealing with actual homes!

Several friends of mine have asked about buying real estate recently, so I figured I’d put together my thoughts on the issue. I currently own a small condo in the SoMa neighborhood of San Francisco, which I purchased in 2010. I have no qualifications to speak on this topic other than that, but rest assured, I do my homework when making major life decisions. Plenty of others have written about buying vs. renting, but I’ll try to come at it from the SF tech perspective.

Owning the home you live in is on average cheaper than renting. Why? Because the government subsidizes it! Of course, the devil is in the details, and in some cases it doesn’t work this way, but on average owning is guaranteed to be cheaper than renting, thanks to government manipulation in the form of the mortgage interest tax deduction, whereby you can deduct all property taxes and mortgage interest paid from your income on your tax returns. On a 30-year mortgage, a huge percentage of your payments are interest, so you’re effectively paying 25% less on it thanks to the tax break. A landlord also gets to deduct the mortgage interest, but he’s deducting it agains the rental income, not his core income, and thus isn’t getting the same kind of discount you can.

“Sweet,” you say, “so I should buy a home right now!” Not so fast. The biggest impediment to buying is transaction costs: You’re looking at about $10k in closing costs, 3.5% down payment (20% if you don’t go FHA), and 6% commission when you sell it. That’s a lot of cash, and not everybody has the means to come by it. If you do, then awesome, you’re set. Well, not quite. There’s still investment risk in the real estate market, which I’ll get to in a bit.

To get into detail about 3.5% vs 20%…right now lending is tight, so a normal mortgage is going to require a 20% down payment. However, the Federal Housing Administration will insure the mortgage so that the lender is taking effectively zero risk. If you get an FHA-insured mortgage, you only have to put 3.5% down but you pay an extra 0.5% of the purchase price every year plus an up-front premium of around 2%. You can roll that up-front cost into the mortgage itself, but you’re paying it either way.

So, back to transaction costs. Renting generally makes more sense if you’re short-term, due to the high transaction costs. Unless you’re looking forward to being a landlord, you generally don’t want to buy unless you’re going to be there long enough for the savings and appreciation to offset your transaction costs. The #1 variable in rent vs. buy calculations is how long you’re planning on living there. The NY Times has a fantastic rent vs. buy calculator based on this.

Okay, now the investment side. Real estate is an asset. Assuming a flat economy (e.g. Switzerland), you’re looking at about a 5%/yr return on your money if you just walk up, buy a home for cash, and rent it out. Not bad, but not great either. However, if the value of the home goes up, then you get that appreciation in addition to the cash flow. Pretty good, eh? Well, it gets better: you can get some pretty serious leverage involved. Instead of buying a home for cash, you use a mortgage to finance it. The bank gets their ~5% cash flow, you put 20% down, and the rest is financed. Now, you’re 5x leveraged. If the home goes up 20% in value, you doubled your money (down payment). At 3.5% down, it’s even more leverage. Unlike some riskier leveraged bets, your downside is walking away and letting the bank foreclose on the home. You’re out the down payment and probably can’t buy another home any time soon, but you’re not on the hook for the massive loss in value. Of course, it’s still not pretty, but the asymmetry makes leveraged homebuying look pretty good.

Given the Fed’s recent policy of printing money, there’s another way to look at this: even if the real value of your home stays flat, the nominal value can go up entirely due to inflation. Since your mortgage is a fixed number of dollars at a fixed rate, you get to pocket the difference. This is, in fact, one of the big reasons that pushed me to buy my condo. I expect pretty severe inflation some time in the next 30 years, so I’m quite happy to be long a hard asset (the land and structure) while short what amounts to a 30-year bond at 5%. Interest rates can’t go much further down from here, so worst-case all I get is an increase in the real value of my home.

On average, real estate appreciation pretty much matches inflation. In specific regions, however, we can see significant gains or losses. For example, the SF Bay Area has seen something like 17%/yr for the last 20 years according to my realtor friend. Other places? Not so much. In addition to deciding whether to rent or to buy, you’re also making a decision about where to buy, and that can have a big impact. I prefer SF, NYC, or Boston because I expect a significant demographic shift back from suburbia to the cities in our generation, and those three are the most pedestrian-friendly large cities in the U.S.

So here’s the bottom line: if you really want to own a home, go for it. Condos are pretty low-maintenance (the biggest homeowner maintenance I’ve done since moving in almost 2 years ago has been tightening a nut on my bathroom faucet) and on average it’s a pretty good deal. If you lose your job, it can suck to be shelling out several grand a month to the bank instead of slipping out of your lease to live with a friend or your parents. If the real estate market tanks, as it did in 2007, you can end up paying quite a bit more for your mortgage than your neighbor pays in rent. If your HOA discovers severe building defects, you could be on the hook for tens of thousands of dollars in repairs (we’re currently suing our developer to get them to pay these costs). There are plenty of downsides, but in the end, there’s something to be said for the pride of owning your place.

You’ve heard that line, right? It’s what all the cool startups say, even when they’re a couple of guys in some apartment running on the $10k investment from the CEO’s uncle. Since pretty much forever, IPO has been the endgame for the entire startup lifecycle. You start up, raise seed money, raise a Series A, then a Series B, then maybe C, then maybe a few more oddly shapred rounds, then you IPO for beaucoup bucks and everybody gets rich.

Even so, far more startups get acquired than go IPO, and recently we’ve seen a lot of smaller acquisitions as companies like Facebook and Google snap up startups that are barely into the prototype phase as talent acquisitions. Heck, we’re even making jokes about starting companies just to get “acqhired” without even intending to build for the long haul. Even companies that are trying to build for the long term end up selling out because, man, the money is so good. I hope we can learn to appreciate acquisition as a legitimate outcome for startups, but I can’t help but wonder: is there a third way?

IPO, acquisition, or bust. Those are the three outcomes for a startup today. Historically, that’s really been the only way we could do it: proving out ideas took millions of dollars and our ability to pick winners has been terrible, so the returns from the successes have to be massive to turn a profit for the investors. This forces investors at every stage to seek 10x (or more) returns on their investments to cover the duds. If you’re looking for that kind of return, there’s no way you’re going to make it on dividends. You have no choice but to sell it on to the next investor, and so on until the IPO. Finally, at that point, all the speculators can cash in and real investors can step in. But wait, do recently IPOed companies pay dividends? No way! Apple has been around for over 30 years and just finally announced a dividend program this year. So really, those of us buying IPO stocks are yet more speculators, expecting the price to go up even further before the company starts paying dividends. It takes decades before a company actually starts throwing off enough revenue to make its stock cash-flow competitive with bonds.

Think about this for a minute. Most companies bring in revenue. Many could be profitable on that revenue. They aren’t, though, because they must grow further to satisfy the investors, who are pressured by their economics to demand crazy returns. Instead, they keep growing, often collapsing under their own weight before ever paying a dime in dividends.

Why can’t a company start up, get some traction, pass breakeven, and start throwing off cash for its investors? Small business do this all the time, but how about startups?

Historically, the immense capital required to prove out ideas combined with poor metrics for success forced us into this model. What about today? Proving out web applications can cost under $1 million, sometimes even less than $100k. Some crazy percentage of Y Combinator-backed startups are still doing well, far beyond the “1 in 10” number we so often throw around. On top of that, many startups “fail” because they were pushed too hard by their investors, and with a different structure could have done just fine. How many revenue-generating, successful companies have had to pull the plug because they didn’t hit the jackpot?

What if VC funds, instead of returning the principal to their investors, held onto their portfolio and paid out dividends from the portfolio’s profits? Could a sufficiently large angel fund spread risk well enough to get a positive ROI out of small startups that climb quickly to profitability but can’t make it to $1 billion in revenue? Could companies avoid going public completely and focus instead on building a sustainable organization, free from short-term earnings-oriented investors?

I believe that to truly enable the greatest amount of innovation and progress in our industry, we need to develop alternative paths for the immense variety of startups that we have today.

What do Steve Jobs, Bill Gates, Mark Zuckerberg, Elon Musk all have in common? Besides being insanely wealthy, of course. They are visionaries. Where mere mortals might build a company to produce a product that solves a solution, these people have seen the future. Their vision has been so powerful that they have actually created the future. These visionaries sweep up scores of followers to join their cause, and they inspire exceptional levels of commitment.

Take SpaceX, for example. They have developed the lowest-cost space launch system available today. Wow, what an amazing product, right? But ask Musk how they’re doing. I haven’t met him, but I think he’ll tell you it’s not good enough yet, because it can’t go to Mars. He is thinking so far into the future that the next five years are simply baby steps on the way. His vision for the future of the human race requires colonization of Mars, and having seen that future, he is simply doing with he must to make it reality. From what I’ve learned, the people working at SpaceX buy into that mission. They’re inspired by Musk’s vision, and they’ll go to great lengths to achieve it.

Visionaries don’t struggle to inspire people. They themselves are inspired by a greater purpose, and it’s contagious. Pretenders are the ones who sweat and struggle. They want to be worshipped, so they pretend to create a vision. A real vision, though, comes from somewhere else. I don’t believe visionaries set out to see the future. It hits them and overcomes them so much that they have no other choice but to follow through.

They aren’t necessarily great organizers or facilitators, though. They envision and articulate where to go, but they don’t always do a great job of getting people there. Often a lieutenant is required to organize the day-to-day operations and ensure progress is happening short-term and people feel involved. The lieutenant is deeply imbued with the vision, as well, but he or she must have a detail-oriented, shorter-term focus.

Working closely with a brilliant visionary this weekend, I’ve noticed that they use very different language. Visionaries tend to use words like “must” and “will” and they’re often harsh critics, whereas non-visionaries will use softer language (e.g. “maybe”, “must”, “let’s”, “should”, “sort of”). There’s an aura of purpose that they they convey in their choice of words and tone of voice. When others try to emulate the behavior, the aura doesn’t come across, and it ends up feeling false. Some visionaries are more articulate, but all of them demonstrate a strong sense of purpose.

If you want to feel inspired about what you’re doing every day, find visionaries and follow them.

Challenging software developers about how much time they’re taking to build things is a losing battle, especially when you’re non-technical. It’s often non-obvious what takes lots of time and what doesn’t, so the key to an effective relationship with your developer(s) is communcation.

When you talk about what to build next, is there a dialogue between you two? i.e. do you ask how long things will take, and then prioritize based on the ROI? Giving a developer an arbitrary deadline is fraught with peril, but asking a developer to estimate a project is more reasonable as long as you’re understanding when things take longer than estimated. The fundamental nature of software development is that we’re often doing things that haven’t been done before, and so they’re inherently hard to estimate. Is your co-founder giving you timely heads-ups when something looks like it’s going to take longer? Often it makes sense to give up on a project that turns out to be 10x as difficult and switch to something with a higher payoff once you realize how difficult it is.

The best approach I’ve seen to software development is to focus on de-risking: Constantly ask “What is the highest risk part of this project?” and find ways to cut that risk. Risk in software development is generally tied to uncertainty: things you aren’t sure how to build are high-risk. Things you know how to build and how long they will take are low-risk. Often we de-risk components with “spiking,” where you go and start building a component to better understand what it will take. You come back from a spike, which usually lasts 1-2 days, with a clearer understanding, which reduces risk. When you work from highest-risk parts to lowest-risk parts, the final estimate becomes clearer and clearer as the project progresses.

A couple of weeks ago I teamed up with my friends Ulf and Scott to tackle the TechCrunch Disrupt Hackathon. We built one of the few iOS native applications at the event, and I think it’s pretty sweet. I present to you Karpool: the easiest way to organize carpools with your friends. Launch the app, put in your friends’ phone numbers, and hit “Start”. They’ll be notified via SMS when you’re nearby, and you get a real-time dashboard of who is ready to be picked up.

We went into the hackathon with little intention of pushing our app to the App Store, but we ended up building a pretty useful, complete app that I would totally use…if I owned a car. Anyway, Ulf and I may polish things and get it into the App Store over the next few weeks, so stay tuned at Karpool.us.

I spent the last week visiting my girlfriend back at RPI, and I took the opportunity to spend some time with one of the most awesome groups on campus: the Rensselaer Center for Open Source (RCOS). RPI can be a pretty desolate place for finding interesting people, but RCOS is a veritable treasure trove of awesome software developers. John Britton, Alex Gaynor are probably the most well-known RCOS alumni, but plenty of other awesome hackers have gone on from RCOS into all kinds of different companies.

Since we’re hiring at 2bkco, I figured I’d share some advice with these guys (and gals) about how to best position themselves to land a job at a place like 2bkco. Just doing RCOS is a great start, but you’ve got to do a little more than that if you want to stand out. I put together a 15-minute talk, and I think it went over pretty well. Whether or not they take my advice, RCOSers are bound to do well.

Object-oriented programming (OOP) is practically gospel in some parts of the programming world today. At its most basic, it means attaching functionality to particular pieces of data. For example, if you have a bunch of information about a person, you might want to group that together and attach some person-specific functionality to it, say, the ability to send a letter to the person. Different pieces of data can represent different kinds of things, so it makes sense to couple functionality with “type.” Ruby is a great object-oriented language (my favorite), and embodies OOP quite well in my opinion. Everything in the Ruby universe is an Object, and things are instances of particular Classes (which are themselves Objects). Every object in the Ruby world has a particular set of operations that you can perform on it, and it usually contains some kind of data. Encapsulation, Polymorphism, and other Good Things arise out of the object-oriented paradigm.

On the other end of the spectrum, we have Lisp. In a Lisp, everything is data, including code. At its most basic, Lisp supports very few kinds of data, with lists being the only way to group data. Clojure (my favorite Lisp) supports a few more types, such as maps and sets, but thanks to the Sequences API, they appear fairly homogenous. Instead of coupling data with functionality with an object system, Lisp treats everything the same: many functions can act on just about any chunk of data. This way of thinking completely separates functionality and data, in stark contrast toOOP. In the Lisp way of doing things, you build general-purpose functions that you compose together and then operate on homogenous data with. You lose Encapsulation, but Polymorphism isn’t even a concept since types have mostly disappeared.

In the process of writing Computer.Build, I’ve used both paradigms to varying degrees of success. In the Ruby implementation, I build an abstract syntax tree (AST) up using a block-based internal DSL. I then ask this tree to generate itself into VHDL, and it recursively calls generate() on each node. Different nodes have different types, allowing them to generate different VHDL. In Clojure, on the other hand, you create the AST directly using a list literal, so you’ve got this giant homogenous data structure. Without an object system, how do you generate different code based on what kinds of nodes you encounter in the AST? With a dispatch function, of course! Clojure (and many other Lisps) supports a concept of “multimethods,” which are sets of functions that are dispatched to based on another function. This allows me to write a dispatch function that analyzes a particular node in the AST and decides what kind of type it is (generally by getting the unqualified name of the first element). The result of the dispatch function is then used to choose one of many different VHDL-generating functions to run against the particular node, some of which recurse through this multimethod again.

Since I started in Java, I still tend to think in an OOP style. This means the Ruby implementation of Computer.Build should be considerably easier for me, but it turns out I’m gravitating more toward the Clojure. It’s just so…clean! The syntax is terse, the structure is pure, and the multimethod-based dispatch seems so much clearer than fancy inheritance dances. As indoctrinated with the OOP style as I am, I’m starting to feel like a data-oriented style (a la Lisp) is better for some applications. When you’re trying to represent real-world objects, then yes, a type system that allows you to represent classes of things like people and trees and whatnot makes sense. Once you get into the abstract, esoteric world of software, though, the OO metaphor isn’t quite as simple. Heavy OO users tend to end up with huge, complex hierarchies of types that can be pretty confusing. If you switch to a data-oriented approach, though, you can focus on exactly what you need to get done. I can represent the AST for Computer.Build as a homogenous list, and then act on each node based on some arbitrary analysis of it. I don’t have to worry about what type things are or where they inherit from; I just dispatch and go.

I’m a firm believer that different problems require different tools to solve, and programming style is no different. At work, I’m encountering asynchronous, evented I/O for the first time, and it’s a great tool for some applications. Some problems are going to lend themselves to an OOP style, while others are going to fit a more data-oriented approach. With Computer.Build, I’m leaning toward favoring the data-oriented approach.

For a long time now I’ve had a habit of railing about “incompetence.” People who were “incompetent” made no sense to me. How could you consistently underperform at a task without improving? Last week, I realized I’ve been thinking about it entirely the wrong way. It’s not incompetence per se that upsets me, it’s carelessness. People who don’t care about things are completely inscrutable to me. How do you live if you don’t care? What gets you up in the morning if things don’t matter to you? Passion is what drives me day in and day out. Doesn’t it drive everybody?

I don’t think I’m alone in the software world when I say that. Most of the great developers I know are driven by passion, and when I asked on OnStartups Answers “What drives you?” a lot of people came back with passion. It seems to be a common theme, from Getting Real to education, that people who are passionate are more successful. My confusion of carelessness with incompetence wasn’t completely wrong: people who are passionate improve over time. People who aren’t can be comfortable staying at the same level of ability without significant improvement. Over time the two groups diverge, with the passionate people getting better and better.

I think software engineering runs the risk of losing the passionate people. What I love most about the Ruby community is its consistent theme of passion and experimentation. We have great characters like _why (or hadhim) and fun frameworks like Sinatra, where the web server tells you that “Sinatra has left the stage (applause).” Ruby people are clearly passionate about what they do, and that makes me feel like I’ve found my people. Passion drives me, and passionate people make sense to me. No wonder Ruby has so quickly become my favorite language to code in.

It’s hard to get passionate about something you’re no good at. Every time I’ve gone into a new field and tried to learn it, there’s a period I call bootstrapping. I know so little about the topic that I struggle even to figure out what I should be learning, much less actually learning it. It’s often not very fun, and I’m rarely that passionate about it. Getting over that hump, though, is so worth it. When you’re just starting out, you may not be passionate, but you’re not going to get there without caring.

I’m in the process of re-starting the RPI Entrepreneurship Club over the next several months. Creating an organization is difficult, but I’ve come to understand there are two (and probably more) very different ways of going about it. One kind of leader focuses on building the infrastructure for the organization to function well, while the other focuses primarily on the people. Of course, both are necessary for a strong organization, but the different emphases can have a significant impact on the organization’s growth.

When you start with tools, you get a less intimate organization. When people interact through tools, they have different feelings about the other individuals in their organization. The other people are simply text on the screen, as rendered by the tool. Tools allow administrators to enforce policy and lubricate processes, but they don’t inherently encourage interpersonal interaction. An organization’s people are often its greatest asset, and they need to be brought together as much as possible.

A leader who focuses on people first is taking a risk. When you focus on the people, you face a couple of dangers. First, you can misstep and create a negative culture. Second, you can focus too little on the other concerns, such as tools, and end up with a bunch of people getting nothing done. When played correctly, though, a people focus can create a tight-knit, efficient team that accomplishes great things with ease. Once the people are working together well, the tools fall into place. A strong team with good people is the basis of a strong organization, and I believe that a focus on people from the start creates the best kind of organization.

Leadership is hard, and I’m nowhere near good at it. After seven years of trying, I’ve finally gotten to the point where I don’t screw it all up. I think I have an idea at this point of what the right thing is, and I’m striving this semester to work toward effective teams. I believe that the people are far more important to a team than its tools, and focusing too much on tools early on will hurt the team.

Getting it right is easy. What you do when things go wrong shows real talent.

I was in lab last week with my two lab partners working on a Computer Hardware Design project. They’re two of the top students in my department, seniors, and they even hold down part-time consulting gigs during school. By virtually every measure available, these guys are amazingly good.

Yet they can’t debug. We hit a number of snags during our lab, and they just started freaking out. Was the oscilloscope bad? It must be, let’s run calibration. Try the circuit on another ‘scope. Different results. Curse some more at the equipment. Rip out half the circuit and replace it with a pulse generator (which caused its own family of problems). Blame the “bad” equipment some more. Eventually, we went home with no results.

These guys are used to getting it right the first time, and that cockiness hindered them when things went wrong. They’re fast, sure, when they already know how to do it and nothing goes wrong, but how often does that happen? Frankly, if I were a hiring manager, I would be hard pressed to hire either one. From what I’ve seen, things rarely go according to plan.

How you handle things when they don’t go according to plan is when real talent emerges. Maintaining a calm manner, having patience, and methodically isolating the problem are critical to being a good developer of anything, especially software.