abhi - becoming internet geek...

Remember that Stack Overflow thing we’ve been working on? Some commenters on a recent Hacker News article questioned the pricing of Stack Exchange — essentially, a hosted Stack Overflow:

Seems really pricey for a relatively simple software like this. Someone write an open source alternative? it looks like something that can be thrown together in a weekend.

Ah, yes, the stereotypical programmer response to most projects: it’s trivial! I could write that in a week!*

It’s even easier than that. Open source alternatives to Stack Overflow already exist, so you’ve got a head start. Gentlemen, start your compilers! Er, I mean, interpreters!

No, I don’t take this claim seriously. Not enough to write a response. And fortunately for me, now I don’t need to, because Benjamin Pollack — one of the few people outside our core team who has access to the Stack Overflow source code — already wrote a response. Even if I had written a response, I doubt it would have been half as well written as Benjamin’s.

Developers think cloning a site like StackOverflow is easy for the same reason that open-source software remains such a horrible pain in the ass to use. When you put a developer in front of StackOverflow, they don’t really see StackOverflow. What they actually see is this:

 create table QUESTION (ID identity primary key, TITLE varchar(255), BODY text, UPVOTES integer not null default 0, DOWNVOTES integer not null default 0, USER integer references USER(ID)); create table RESPONSE (ID identity primary key, BODY text, UPVOTES integer not null default 0, DOWNVOTES integer not null default 0, QUESTION integer references QUESTION(ID)) 

If you then tell a developer to replicate StackOverflow, what goes into his head are the above two SQL tables and enough HTML to display them without formatting, and that really is completely doable in a weekend. The smarter ones will realize that they need to implement login and logout, and comments, and that the votes need to be tied to a user, but that’s still totally doable in a weekend; it’s just a couple more tables in a SQL back-end, and the HTML to show their contents. Use a framework like Django, and you even get basic users and comments for free.

But that’s not what StackOverflow is about. Regardless of what your feelings may be on StackOverflow in general, most visitors seem to agree that the user experience is smooth, from start to finish. They feel that they’re interacting with a polished product. Even if I didn’t know better, I would guess that very little of what actually makes StackOverflow a continuing success has to do with the database schema—and having had a chance to read through StackOverflow’s source code, I know how little really does. There is a tremendous amount of spit and polish that goes into making a major website highly usable. A developer, asked how hard something will be to clone, simply does not think about the polish, because the polish is incidental to the implementation.

I have zero doubt that given enough time, open source clones will begin to approximate what we’ve created with Stack Overflow. It’s as inevitable as evolution itself. Well, depending on what time scale you’re willing to look at. With a smart, motivated team of closed-source dinosaurs, it is indeed possible to outrun those teeny tiny open-source mammals. For now, anyway. Let’s say we’re those speedy, clever Velociraptor types of dinosaurs — those are cool, right?

Despite Benjamin’s well reasoned protests, the source code to Stack Overflow is, in fact, actually, kind of … well, trivial. Although there is starting to be quite a lot of it, as we’ve been beating on this stuff for almost a year now. That doesn’t mean our source code is good, by any means; as usual, we make crappy software, with bugs. But every day, our tiny little three person team of speedy-but-doomed Velociraptors starts out with the same goal. Not to write the best Stack Overflow code possible, but to create the best Stack Overflow experience possible. That’s our mission: make Stack Overflow better, in some small way, than it was the day before. We don’t always succeed, but we try very, very hard not to suck — and more importantly, we keep plugging away at it, day after day.

Building a better Stack Overflow experience does involve writing code and building cool features. But more often, it’s anything but:

1. synthesizing cleaner, saner HTML markup
2. optimizing our pages for speed and load time efficiency
3. simplifying or improving our site layout, CSS, and graphics
4. responding to support and feedback emails
5. writing a blog post explaining some aspect of the site engine or philosophy
6. being customers of our own sites, asking our own programming questions and sysadmin questions
7. interacting with the community on our dedicated meta-discussion site to help gauge what we should be working on, and where the rough edges are that need polishing
8. electing community moderators and building moderation tools so the community can police and regulate itself as it scales
9. producing Creative Commons dumps of our user-contributed questions and answers
10. coming up with schemes for responsible advertising so we can all make a living
11. producing the Stack Overflow podcast with Joel
12. helping set up logistics for the Stack Overflow DevDays conferences
13. setting up the next site in the trilogy, and figuring out where we go next

As programmers, as much as we might want to believe that

 lots_of_awesome_code = success; 

There’s nothing particularly magical about the production of source code. In fact, writing code is a tiny proportion of what makes most businesses successful.

Code is meaningless if nobody knows about your product. Code is meaningless if the IRS comes and throws you in jail because you didn’t do your taxes. Code is meaningless if you get sued because you didn’t bother having a software license created by a lawyer.

Writing code is trivial. And fun. And something I continue to love doing. But if you really want your code to be successful, you’ll stop coding long enough to do all that other, even more trivial stuff around the code that’s necessary to make it successful.

* Although, to be fair, I really could write Twitter in a week. It’s so ridiculously simple! Come on!

If you are still using Dell Inspiron 1150 which is having unsupported chipset for Windows 7 you must have faced display drivers issue. When you install Windows 7 beta or Windows 7 RC1 it will take you back to 1990s in terms of screen resolution.

Here is the solution:

1) Download the drivers from this link.

2) Restart the laptop in safe mode

3) Unrar the drivers in a folder

4) Install the drivers using Device Manager (Shortcut: Windows Key + Break -> Device Manager)

5) Restart

And you are done!

You are back to your old 1024x768 resolution. 

Special thanks to my friend and colleague Kuntal for helping me find this.

If you are still using Dell Inspiron 1150 which is having unsupported chipset for Windows 7 you must have faced display drivers issue. When you install Windows 7 beta or Windows 7 RC1 it will take you back to 1990s in terms of screen resolution.

Here is the solution:

1) Download the drivers from this link.

2) Restart the laptop in safe mode

3) Unrar the drivers in a folder

4) Install the drivers using Device Manager (Shortcut: Windows Key + Break -> Device Manager)

5) Restart

And you are done!

You are back to your old 1024x768 resolution. 

Special thanks to my friend and colleague Kuntal for helping me find this.

“A great lathe operator commands several times the wage of an average lathe operator, but a great writer of software code is worth 10,000 times the price of an average software writer.” –Bill Gates

Why is tech news so fun and addicting? Why do I keep scanning my RSS feeds hourly for the latest?

Great programmers are rock stars. Their heroic abilities and exploits are why we RSS Techcrunch and Siliconangle, continuously scanning articles for the latest hits and misses.  Programer rock-stardom, however, is founded on the well documented variation in software programmer productivity. Programmers, as it turns out, have one of the highest productivity variations of any profession.

“Numerous studies have found 10:1 differences in productivity and quality among individuals and even among teams…. programmers with an average of 7 years’ experience and found that the ratio of initial coding time between the best and worst programmers was about 20 to 1; the ratio of debugging times over 25 to 1; of program size 5 to 1; and of program execution speed about 10 to 1.” -Steve McConnell, development productivity guru and “10X Software Development” blogger

Anyone who has spent much time in a software engineering environment knows “the guy” to go to with the hardest problems, the one who can bang out the solution in an hour, instead of weeks. For me, it was an über-nerd named Roy who was the best talent in our 200-strong engineering group, despite having never spent a day in a college classroom. I once saw him in Blockbuster Video with his family. I was completely  star-struck  and I asked the woman at the register if she had any idea who she was renting videos to. I reacted this way despite sitting two doors down from him at work–he was a legend and I wanted everyone in Blockbuster to know it.

It was a similar reaction to the one in this recent USB Rock Star Commercial.

The same dynamic plays out at companies, and then fun begins! These rock star programmers have the power to create new markets, or topple top brands seemingly overnight. There seem to be two types of visionary programmers.

The first group makes a common thing uncommonly well:

Some of the greatest computer scientists out there excelled in this category. They go to the mattresses in a hiding place in Mountain View, San Francisco, or Atlanta and emerge with an unexpectedly awesome new edition of an already common piece of software. They work in small “best-of-the-best” teams with few breaks. They create value where the market thinks no more can be created. Google Search, Jboss, and Sun’s Fishworks, are examples that readily come to mind.

They upset markets by adding a radical dose of speed, reliability, manageability, or simplicity to known functionality. This first group of rock star programmers have the rare combination of smarts and passion you can’t teach.

The second group of rock star programmers grab the opportunity no one else sees yet:

These programmers revolutionize data or user behavior that was seemingly waiting to be coded appropriately. Napster is a great example of a somewhat simple piece of software that - despite its technical simplicity - was the result of a programmer seeing lots and lots of interesting data waiting to be harnessed into an application. I would also add Twitter into this group. It is an expansive view of where new linkages can be created that drives this group of programmers more than any outstanding ability to write the best code (as evidenced by the frequent sightings of the Fail Whale!)

Don’t always expect reliability, scalability, and general code perfection from this group - they are the visionaries of outstanding and radical applications that turn the everyday and mundane on its head.

How are you taking your productivity and vision to the next level?  Sometimes its hard to tell just how productive you are, but for now it’s a good sign if the young engineers in your group are starstruck when they see you in public.

What are your rock-star coder stories? I’d love to hear them!

There are two reasons joint ventures fail. The joint part and the venture part.

All ventures are risky, because they involve change and the unknown. We set off on a venture in search of something, or to make something happen—inherent in the idea of a venture is failure. It’s natural, then, for fearful people on both sides of a joint venture to back off when it gets scary. When given a choice between a risk and sure thing, many people pick the sure thing. So any venture begins with some question marks.

The joint part, though, is where the real problem arises. Pushing through the dip is the only way for a venture of any kind to succeed. The dip separates projects that begin from projects that finish. It’s easy and hopeful and exciting to start something, but challenging and often painful to finish it. When the project is a joint one, the pressure to push through the dip often dissipates. “Well, we only have a bit at stake here, so work on something else, something where we have to take all the blame.”

Because there isn’t one boss, one deliverable, one person pushing the project relentlessly, it stalls.

Every joint venture involves meetings, and meetings are the pressure relief valve. Meetings give us the ability to stall and to point fingers, to obfuscate and confuse. If a problem arises, if a difficulty needs to be overcome, it’s much easier to bury it at a meeting than it is to deal with it.

In my experience, you’re far better off with a licensing deal than a joint venture. One side buys the right to use an asset that belongs to the other. The initial transaction is more difficult (and apparently risky) at the start, but then the door is open to success. It’s a venture that belongs to one party, someone with a lot at stake and an incentive to make it work.

Only one person in charge at a time.