I wish I could say I had the same experience with the box. The firmwares were consistently buggy and never quite worked well.
By far the two most frustrating aspects being the forced updates (which were often more buggy or broke features) and the lockups while in sleep. There was nothing more annoying than having to get up and hard reboot the thing every time I wanted to watch something.
Once the Pi and raspbmc became a viable alternative I quickly replaced my boxee boxes because, while not bug free by any means, they're much closer to "just working" than the boxee box ever was.
The one good thing I can say about the boxee box, though, is that its remote was a real treat. That thing worked like a charm.
This reminds me of a situation I've seen and found myself in far too many times. When I encounter a performance problem I immediately think about areas where, during initial development, I stopped and said "this might cause a problem with a large amount of data" versus doing the proper thing of actually hooking up a profiler or doing proper testing to determine what the actual problem is; Rarely is it in an area I previously identified as potentially causing future problems.
Ego (I know what the problem is!) and the drive to fix problems quickly always get in the of finding the solution. Tales like this are a great reminder to not assume you know what the problem is.
I've always thought "being the dumbest person in the room" was a bit of overstatement to the truth. It's probably more accurate to say you don't want to be the smartest person. Not so much because you avoid having a target on your back if something fails and a scapegoat is needed, but more because you not only have the ability to teach those that know less than you, consequently reinforcing things in your head and giving yourself a better understanding, but also having people around that you can learn from.
I can say being the smartest person in the room gets really old fast because you always feel like you have your hands tied behind your back and as much as X may be a better solution to a problem you have to fall back to something the entire team can understand.
The general environment would probably make a difference too. If you in an environment with people that enjoy learning and sharing the knowledge they gain being the dumbest person in the room probably isn't as bad. I can't say I've met a work environment that is like that, though.
I'm by no means an expert but these are some of the links/books I've found informative.
Smashing The Stack For Fun And Profit [1]
Reversing: Secrets of Reverse Engineering [2]
The IDA Pro Book [3]
The iOS Hacker's Handbook [4] was interesting as a sort of case study on exploiting and hacking embedded hardware.
Mostly what I've found, though, is just starting with a question and googling the answer yield the most results. For example, see mention of a stack overflow attack google how and why stack overflow attacks work (or don't) and once that side of things is understood the thought process behind finding them becomes easier to understand, although not really easier to do (for me, at least).
By far the two most frustrating aspects being the forced updates (which were often more buggy or broke features) and the lockups while in sleep. There was nothing more annoying than having to get up and hard reboot the thing every time I wanted to watch something.
Once the Pi and raspbmc became a viable alternative I quickly replaced my boxee boxes because, while not bug free by any means, they're much closer to "just working" than the boxee box ever was.
The one good thing I can say about the boxee box, though, is that its remote was a real treat. That thing worked like a charm.