Monday, March 17, 2008

A few ideas about Negotiation

A good friend of mine asked me for some negotiating tips. This is what I told her. Use, agree, or disagree with them at your own risk.

1) Never put numbers in email. Email lives forever. Numbers are only discussed on phone or in person. Only written down when you're signing the contract.

2) There's an old saying "Whoever puts the number on the table first - loses". In general, this is good fallback advice.

I modify this according to several factors:
a) The less you can predict the outcome, the more likely I let the adversary say the first number. (i.e. revenue-less company valuations are often voodoo - its quite possible your buyer will give a higher number than you ever imagined).
b) The more I need a deal, the quicker I am to say this first number. This sets a tone.
c) Conversely, the less I need a deal - I'm willing to let them show me just how bad they want it. The danger is if they give an extreme lowball, I need to be able to walk.

3) No matter what they offer, ask for more. How forcefully depends on how good the deal already is. If they offer you 10% when you were expecting 3, meekly ask for 12% and back down fast if needed. If they offer 1%, strongly go for 4% and settle for 2.5.

4) Don't answer the phone if they call to discuss the negotiation. You are probably thinking about the chicken mcnuggets you just ate and they have been thinking the last 20mins how the phone negotiation will go. In short - they are prepared, you aren't. Let them goto voicemail. Wait an hour.. spend 10 minutes focusing on the possibilities of the negotiation and call them back. Their mind will be elsewhere now. You'll be ready.

5) Seriously - don't ignore #4. Fifteen seconds is just not enough time to swap your mind into the right context. Besides, information they leave in the voicemail could be advantageous.

6) (Unless you're reading this and you end up negotiating with me - then we might as well set a time in the future to chat otherwise we'll never answer each other's calls.)

7) *Everytime* you sign a contract, you are giving up something. Take a step back and make sure you fully understand all that you are giving up - and all that you are receiving in return. Never sign a contract (or sleep with someone for that matter) because you feel bullied into it.

8) A common negotiating tactic is to put your adversary in an uncomfortable situation. The hope is that the adversary will compromise some just to relieve the discomfort (the more experienced the negotiator, the less likely this is). If you can, reverse the discomfort instead. (This is a class used-car-salesman tactic - think "But you told me yesterday you were going to buy this car!")

Surely negotiation is an art and there's plenty more to it. These ideas are at best a few tricks and tips. Negotiation is a dance - you can't exactly know what you'll have to do until you are forced to react to what your partner does. Thus just like dancing, practice does wonders for your skill.

Wednesday, March 05, 2008

Writing Java Multithreaded Servers - whats old is new (PDF Slides)

I'm giving another talk tomorrow at the SD West conference:

Here are the slides
Thousands of Threads and Blocking I/O: The Old Way to Write Java Servers Is New Again (and Way Better)


I've encountered some very strong misperceptions in the world that:

1) Java asynchronous NIO has higher throughput than Java IO (false)
It doesn't. It loses by 20-30%. Even with single thread against single thread. If multiple threads enter the equation (and multiple cores) which of course blocking I/O is intent on using - its skews even farther.

2) Thread context switching is expensive (false)
New threading libraries across the board make this negligble. I knew Linux NPTL was fast, but I was quite surprised how well Windows XP did (graphs inside notes).

3) Synchronization is expensive (false, usually)
It is possible for synchronization to be fully optimized away. In cases where it couldn't it did have a cost - however given we have multicore systems now its uncommon to write a fully singly-threaded server (synch or asynch), in other words every server design will pay this cost - but, non-blocking-data-structures ameliorate this cost significantly (again graphs inside show this).

4) Thread per connection servers cannot scale (false)
Thats incorrect at least up to an artificial limit set by JDK 1.6. 15k (or 30k depending on the JVM) threads is really no problem (note linux 2.6 with NPTL using C++ is fully happy with a few hundred-thousand threads running, Java sadly imposes an arbitrary limit). If you need more connections than this (and aren't maxing your CPU or bandwidth) - you can still use blocking IO but must depart from thread-per-connection. Or fall back to NIO.

I'll try to spruce up the benchmarks I used and try to post them. I'd like to point out that writing Java benchmarks is very hard. I spent a great deal of time making sure I warmed up the VM and insured there were no positional biases or other overzealous or skewing optimizations.

I was then *extremely* lucky to get help from Cliff Click of Azul systems (if you want to write a benchmark, a VM engineer is the right kind of person to get help from). He spent half a saturday tweaking my benchmark in ways I never thought of. Then ran them for me on his 768core Azul box (graph inside)!! thanks Cliff !

Sunday, March 02, 2008

Notes for my SD-West talk tomorrow on Interviewing in Silicon Valley

I'm giving a half-day tutorial tomorrow at SD-West 2008 in Santa Clara on How to Pass a Silicon Valley Software Engineering Interview.

Its the first of 3 talks I'm giving this week (subsequent notes to come subsequently).

You can download the slides Here.

If you're not attending the talk, please note that as with all slide decks, they are in a sense only half the story - as I'll be filling in many pieces during the lecture itself.

This is the third year I've given this talk and I'm amused to mention that I got a thank you a few weeks back from a veteran SD speaker that attended last year's class and now is just starting his new job at Google. He said the class was very helpful (he also offered to buy me dinner, but given that dinner at Google is free, I countered and offered to buy him dinner instead :)