Excellent video — reminds me of this site with a bad word in the address.

-The biggest issue was dropped packets. Or should I say never delivered packets when the system was under stress. That was big issue #1 and, honestly, that was the killer issue. I never did track down the cause, but at the point I realized it was zmq and not me, I had given up on the package.
-The second was general flakiness in action. I’d see a deadlock here (and I remember tracing to the code and going, “huh, why are they reimplementing that data structure (for speed) and why are they doing it that way?”) and odd freeze here and occasionally a crash. The deadlock was moderate load, the crash was heavy load and run under a VM.
-The next was shut down issues – it didn’t always. I could get it to hang (much like log4cxx) if I got the ordering of events just right. This one may have been a configuration issue on my end. Since I didn’t investigate, I can’t 100% say for certain.
-we realized that we did not need all the functionality zeromq “provided”. Actually I pushed this one =)

In general, I ended up writing my own epoll reactor pattern and adding a handler class to decouple the receives from the receive processing. Since we have a java side, I grabbed Nettty (which is Awesome – seriously great code). Thankfully, we didn’t need the MPQ functionality – we just needed a scalable communications subsystem.

If I had more time, and I wasn’t stuck sitting under something like Mysql, I might have gone with ACE- which also looks great.

In other words how I manage is dictated by the schedule, by the teams accomplishments and by the teams happiness/engagement level. If I can get the last one, I can get the first two. It’s still a very nebulous answer since, in many ways, managing people is a little nebulous. To be completely honest, my first year managing I thought I was doing a terrible job – sure my product was doing ok (a little behind), my people were happy, the external teams I was working with were happy but I felt I had done nothing since I had produced almost no code. In my head I knew I was doing ok, but that still didn’t stop the feelings of failure. However once I got past that, thanks to a lot of wonderful people willing to mentor me, I learned to embrace making those around me shine and getting a sense of satisfaction from that.

There are a few hard points I can look at too:
1) Did I miss my schedule? By how much?
2) Does my team fight – internally and externally?
3) Does my team brainstorm together well?
4) Does my team constantly snipe?
5) Has my team taken risks?
6) How many people have left?
7) Does my team feel protected?

If my team can brainstorm together, they don’t snipe, they aren’t afraid to take risks, almost no one has left, and the team is seen as rockstars, then I feel I’ve done my job. Regardless of my actual review (unless it’s a 360 and my team panned me. That hasn’t happened, but boy would that be a terrible wake up call).