thejo

> Asynchronous, callback-based code is frequently more difficult to write, harder to reason with, more inflexible, and buggier than similar synchronous code.

That is an excellent point that is usually ignored. Thread per request is much easier to understand and work with. Of course, thread per request is simply not a good choice in cases like a server with support for web sockets, but it is good enough in many cases. My experience has mainly been with Java (NIO vs. simple threads and Executors). Paul Tyma has made a more convincing argument than me about this -

http://mailinator.blogspot.com/2008/02/kill-myth-please-nio-...

http://paultyma.blogspot.com/2008/03/writing-java-multithrea...

http://www.theserverside.com/discussions/thread.tss?thread_i...

Many SaaS products, especially enterprise software, have a "login as a different user" feature that engineers use for debugging. It's good that non tech savvy users aren't always aware of the amount of information leakage that happens in situations where privacy is important. It would lead to a mega freak out.

For example, if you receive SMS alerts from your bank about transactions, account balance etc. there are multiple engineers in the chain who have access to the information, but should not -

* At the SMS gateway company to which the bank has outsourced the services

* Your mobile service provider

* People who run the SMSC (if the mobile operator has outsourced that)

Unfortunately, there is no way to secure it end to end in its current form. The same is applicable to a lot of services.

He's always been pretty open about his "just get the job done" approach. That's exactly what PHP is too. Not beautiful, well designed etc., but gets the job done in most cases.

This is a mail he showed at a talk - http://lerdorf.com/fanmail.txt

I'm sure he enjoys it when people get worked up about PHP :)

Getting to Plan B by John Mullins and Randy Komisar is another good book from 2009. It provides a framework to arrive at a business model that works with lots of analogs from successful companies. A nice addition to the customer development genre.

The headline is misleading. He's pretty balanced in his views on Microsoft and Google.

On the first point, you have to remember that the larger a company grows, the more impersonal it becomes. Interviewing in most large companies is usually seen as a chore, the outcome of which does not have a huge impact on the interviewer. This is different in a startup, where hiring someone may significantly impact your own work. Of course, if the interview is conducted as though it is a chore, then it just sucks and you have to start thinking about how badly you need the job.

On questions, you can always ask about -

* the team you'll be joining

* if it's a small company / startup ask about their business and competition. An engineer who shows that he understands how his work fits into the larger picture is far more valuable than one who is happy to just write code.

* learning opportunities - large company or small, dig into what it is you can take away from the job

Of course, there's no point in making it a formality. What would you like to know about something you might be doing for the next few years of your life?

These are very basic, but here goes -

* Most interviewers, especially at big companies, don't take the time to read a resume in detail. Also, it is usually difficult to access websites if all they have is a hard copy of your resume. Make it easy for the interviewer to access your work during the interview. Use a URL shortener and have links ready to - your online resume with links, rich info (images, charts) about your work etc. It helps to be prepared if the interviewer brings along a laptop. Talking someone through your work when they are looking at it is always better than just talking about it.

* Research the company before the interview. It's always a red flag if a candidate doesn't have any questions about the company they are about to work for. The more you can show the interviewer that you've done your homework, the more likely they are to consider you seriously.

* If possible, learn more about your interviewer before the interview. Google and LinkedIn are your friends. It helps to have some context.

All the best!

Any business we consider to be a commodity today and can't live without. It wasn't always so, and somebody worked hard to make it one.

Those were mostly "funny quotes about technology".

Since this is hacker news, what are your favorite quotes about entrepreneurship? Here's mine -

"The critical ingredient is getting off your butt and doing something. It's as simple as that. A lot of people have ideas, but there are few who decide to do something about them now. Not tomorrow. Not next week. But today. The true entrepreneur is a doer, not a dreamer." - Nolan Bushnell

I don't think the IITs have ever been famous for their research programs. They are well known as a magnet for the smartest engineers in India. Those smart engineers then come to the best US universities and contribute to the reseach, start companies etc. The IITs are a very effective filter and not world class research institutions.

Direct link to article: http://online.wsj.com/article/SB1000142405274870422400457448...

Venture Lab at Berkeley - http://cet.berkeley.edu/connect/teams

I'm quite sure the The Lester Center at Berkeley has a program too - http://entrepreneurship.berkeley.edu/main/index.html

Andy Grove has a wonderful notion of something he calls "earned luck". One needs luck to succeed, but you can't sit around waiting for it. I came across it in his biography by Richard Tedlow... a highly recommended read.

It really depends on the market you're trying to address. I would assume that most phones sold in the developed markets in the last two years have browsers with XHTML+CSS support. But, tons of low end phones are still sold the world over. They may support only WAP. We started with WAP on a project and quickly gave up.

The operators / carriers are a big limitation to innovation in the mobile space. It is completely closed in comparison to the internet. In India, where I worked for a startup which is trying to build a platform without getting into bed with the operators, they pretty much got away with what would appear to normal people to be illegal. Your services are blocked for the simple reason that they may be competing with their own. They will do everything possible to screw up the user experience. I'm not sure how it is in the US. While there are opportunities, there are too many gatekeepers at present.