A Quantum Immortal

It’s been three years since I joined Delver. Three years, and three different positions in two companies (Delver and Sears Israel). There must be some lessons I can think of from this period, right?

• If you want to build a web search engine, you have to think big (and raise a lot of money). Note – lots of money does not guarantee success. This “advice” comes without any warranty. Try this at your own risk 🙂
• Do not try to replace Google as a main search engine (or a user’s homepage). This approach is probably doomed to fail. Instead, think creatively on how you can augment the Google experience.
• Dog-fooding is king. Lack of it (when building consumer products) is an alarming warning sound that should be shouted at every company meeting.
• An ideal Design Review is a meeting where you present the design, and everybody sits silently and nods (credits to Tal Kedar for this hard learned lesson).
• Sprint Retrospectives are great. They’re not always easy, and effectiveness sometimes slips in large groups, but they’re an essential component to a growing and learning organization.
• If three minutes pass and you still don’t understand what you’re doing at a meeting, find out. If you don’t find an answer that satisfies you, leave.
• Meetings should have an owner, who should come with a prepared agenda.
• Ownership is great. I encourage you to be a feature owner, domain owner, version owner, team owner. (Thanks Delver and Moti Karmona for pushing this idea to the limit)
• Feedback is vital. Don’t wait for it, create it.
  • It’s your responsibility as a professional to get feedback on your performance, and act on it. Are you making your boss happy? Are you making your employees happy? Are you making the share-holders happy? What can you do to improve?
  • It’s your responsibility as a product owner to get feedback on the product you’re building. Get this feedback fast, get it today, get it as often as possible. Developing features just because we think they’re cool is wrong. We are biased. We need to validate our assumptions and rinse out the false ones.
• Make sure you know the criteria for success. This applies to projects, positions, features.
• Expect that different people will have different (hidden, unaware) expectations. When in doubt, especially when working on large projects or with new people, make sure you are all synched in your expectations – if you’re not, it will hurt a lot more in the future.
• Communication is more important than code.
• Never start a data intensive project without planning for identification and fix of data corruptions. This will take longer than you expect, even if you take Hofstadter’s Law into account. Also, never get involved in a land war in Asia.
• Prefer to do full features, end to end, within the confines of one small team, instead of partitioning the design to different layers, implemented by different teams. It’s way too brittle.
• Human Resources really are useful (thanks Osnat Barak!)
• Management is hard. For me, it’s a tight balance between doing too much and doing too little. Thanks Shachar Zehavi for the chance to experience it.
• SSDs make developers happy and productive. So does freshly cut salad in the morning.
• The ability to effectively automate and remove little manual “pains” is precious.
• When a project’s internal milestones exceed their ETA by more than 30%, it’s a good time to wipe the plan clean and start again from scratch. People will tend to simply adjust the current ETAs, thus carrying over error.
• Hackathons/Code Dojos are fun! (and I haven’t even been to one yet)
• Think before you post/reply-to-all.
• You are responsible for your career. Nobody will build it for you.

I’d like to take this chance again to thank everyone I worked with at Delver. I learned from you all, and hope you also learned something from me as well. Till we meet again.

After 3 years at Delver (and then Sears Israel), I’ve decided that I need to “see other people”.

I joined Delver 3 years ago, fresh out of IDF and Technion. I still remember how proud and full of myself I was back then. Well, these last three years just served to show me how much more I don’t know!

In Delver Mark I, I worked under the amazing Bogen, learning what Web 2.0 and startups are all about. Is was a great year with its ups and downs, which ended with us being acquired by Sears.

Under Sears, we maintained the startup spirit and relaunched Delver.com as a social shopping site. It is intended to be a cross between Amazon & Facebook, somewhere you can discover interesting products, find trusted reviews and ratings from your friends, and leverage your social network in helping you choose your next LCD TV. We had an wonderful growth from 16 people to 60, including some amazing new talents. I started to lead a small infrastructure team, and together all of us contributed to Delver’s buildup and launch.

At the end, it all comes down to Choice. After three years at the same place, and a few months of deliberations, I made the difficult choice that I had to move on. I feel that my personal career’s growth will be better served by having more experience working with people I don’t know, and expanding the limits of my comfort zone. I feel the burning need to “be all that I can be”, and I feel that the best way for me to achieve this goal outside of Delver.

So … what’s next for me?

I don’t have a specific job offer yet. My top priority right now is continuing my growth and education, in both technical and product aspects. I have a few candidates already on my list, in no particular order:

• Google
• TypeMock
• Soluto
• Waze
• And a few more…

I would love to hear your opinions on these companies, and of course if you have other ideas on cool startups or places where I can learn about B2C websites, scalability, product design – and most importantly, work together with amazing people.

What do you think – should programming language carry any weight in deciding where to work next? Should my next programming gig be in Java, C#, Ruby or perhaps the language doesn’t matter at all? For reference, I’m attaching this chart from langpop (although according to it, the market leader in C. Even if I’m paid double my current salary, I won’t program in C for a living.)

And to all the great people I’m leaving behind in Delver – I wish you all the best, and hope to read that TechCrunch or HighScalability article about how you scaled Social Commerce to 100,000,000 active users. Best of luck, until we meet again…

After more than a year of work, we have finally released Delver beta – a “social shopping platform”.
You’re more than welcome to check it out at http://delver.com/

We are still in “closed beta”, which means you need an invite to get in (but can then forward invites to your friends).
If you want one, drop me a line with your email.

Big big thanks to everyone in our team for making it happen!

With Delver‘s future clouded by a big question mark, I’m looking for a new job. This reminded me of my previous job hunt, and the part we all “love” about it – job interviews.

Last year, two companies I was interviewing for asked me to implement a ReaderWriterLock. It took me more time than I’d hoped, but I got the implementation done. Since this was one of the hardest interview questions (for me at least), I’ve decided to implement one or two versions, and to test the performance vs the built-in reader writer locks available in .NET.

First, I wrote the test code, which is roughly composed of:

1. Shared (singleton) counters object with two counters, X & Y.
2. Some reader threads. When a reader reads, it reads both X & Y and makes sure they are equal.
3. Some writer threads, that increment X & Y together (thus maintaining X == Y).

Then, I tested this setup without any locks, and as expected the reader threads got different values of X & Y.

Next, I implemented the following locks:

1. DummyReaderWriterLock – a horribly inefficient implementation that is reader/writer-oblivious. It just locks the object regardless of reads/writes.
2. SemaphoreReaderWriterLock – already a huge improvment, this locks uses a semphore that holds some large number (~2000) locks. Each reader requests only a single lock from the semaphore, and a writer must obtain ALL locks before continuing. Two writers are prevented from deadlocking by a separate Mutex. One immediate problem with this lock is writer starvation. For a writer to obtain the lock, it must first get the mutex and then all locks in the semaphore. This means a single writer is competing against all readers for the semaphore.
3. EventReaderWriterLock – implemented by two events and a reader count. The first reader & all writers must get signaled in order to get the lock. Once any reader got the lock, other readers are free to enter without blocking. The last reader out is responsible for signaling the event and letting other writers or readers back in.

I also pulled my team leader Oren into this problem, and he came up with a state based implementation – not that far from my own, with an additional “state” integer that represents whether the lock is in “writing mode”, “reading mode” or free. He also added a few TestAndCompare hacks for checking the state.

Finally, I tested the performance of these locks vs two locks that are availble in .NET 3.5: ReaderWriterLock and ReaderWriterLockSlim. I only tested only one scenario, but was pleasantly surprised to discover the performance of both my EventReaderWriterLock and Oren’s StateReaderWriterLock were identical to that of ReaderWriterLockSlim, and better than ReaderWriterLock! (The performance of DummyReaderWriterLock were literally off the charts).

Here is my implementation:

    /// 
    /// A ReaderWriter lock implemented by events.
    ///
 
    /// An AutoReset event that gives ownership of the lock either to one writer or to all the readers.
    /// A manual reset event that allows readers to enter, and is only reset when the last reader finishes
    /// 
    /// 
    public class EventReaderWriterLock : IDisposable
    {
        /// 
        /// Both readers and writer need this lock to work
        /// 
        private readonly AutoResetEvent _lockAvailble = new AutoResetEvent(true);
 
        /// 
        /// Further readers beyond the first one wait on this object
        /// 
        private readonly ManualResetEvent _canReadEvent = new ManualResetEvent(false);
 
        /// 
        /// Used to synch the reader lock/release
        /// 
        private readonly object _readerLock = new object();
 
        private int _readers;
 
        public void LockReader()
        {
            lock (_readerLock)
            {
                int oldReaders = _readers++;
                if (oldReaders == 0)
                {
                    // I'm the first reader, let's fight for the lock with the writers
                    _lockAvailble.WaitOne();
 
                    // got lock, notify all other readers they can read
                    _canReadEvent.Set();
                }
                else
                {
                    // wait for the first reader to signal me
                    _canReadEvent.WaitOne();
                }
            }
        }
 
        public void ReleaseReader()
        {
            lock (_readerLock)
            {
                int oldReaders = _readers--;
                if (oldReaders != 1)
                {
                    // If I'm not the last reader, I do nothing here
                    return;
                }
 
                // I'm the last, let's forbid other readers but allow writers or a first reader.
                _canReadEvent.Reset();
                _lockAvailble.Set();
            }
        }
 
        public void LockWriter()
        {
            _lockAvailble.WaitOne();
        }
 
        public void ReleaseWriter()
        {
            _lockAvailble.Set();
        }
 
        public void Dispose()
        {
            _lockAvailble.Close();
            _canReadEvent.Close();
        }
    }

And the entire zip with the other RWLocks and test harness.

A few immediate conclusions:

1. Writing a working reader writer lock is a very non-trivial problem for a job interview – but watching an applicant struggle with it can give you insights about his know-how around multi-threaded code.
2. Writing an all-purpose RWLock seems like a daunting task. In my exercise I specifically avoided broad considerations such as fairness & readers upgrading to writers. Testing it for all end cases seems almost impossible (though some formal theoretical tools exists for such correction proofs)
3. At least for some problems, writing your own lean solution can be better (performance wise) than relying on the de facto standard. While our solutions weren’t better than ReaderWriterLockSlim, they were significantly better than ReaderWriterLock – again, only in the context of this test harness.

Bonus: my first implementation didn’t have a lock statement in LockReader() and ReleaseReader(), and used Interlocked.Increment() and Decrement() to update the _readers variable. Still, it contained a hidden bug – can you find it, and understand why the lock is necessary?

Check out my post in Delver’s blog. The feature has only been in production for a few days and already I see cool search results from blogs of friends. Let me know if you search and find something useful with it.

Still alpha, but starting today we are open for business – try it out yourself at www.delver.com.

I won’t write about the user experience much because I want you to try for yourselves, and because many others have done so already.

Since the few people I asked didn’t jump on the opportunity (why? ask them, not me), we’ll be giving away 5-10 invitations to the Delver beta, launch scheduled in the following weeks.

If you’re interested, let me know…

Now that the formalities are over, like Tomer and Shlomo, I can now announce I’ll be joining Delver (A.K.A Semingo) on April 1st. Delver is a startup building a social search engine, that will allow you to find information based on your social network.

Starting April I will be in Herzliya daily, and will move back to the center around May.

If you’re interested, you can about us at Techchrunch, register for the private beta or watch our CEO Liad previews Delver at a demo conference.

Oo, and for some reason this next image, which is the first Google Images result for “delver” was blocked by SafeSearch (Google’s adult images filtering), and only showed up when I disabled it. Weird.

UPDATE:
Fix broken link to Delver, thanks Sagie.