I think the watch list would require a lot of work and I'm amazed that a debugger could even be built in html.
I'd also like hover to expose values as in the typical debugger, also pretty difficult I think.

The time stamp added to error messages would be great (the debugger sometimes reads ahead and unfortunately identifies the wrong line when there's a problem) and the time stamp you suggested would take less than five minutes to add [edit: well, that's how I imagined it anyway, I suppose things can often be pretty complex], however then testing is probably a good next step. And it seems Quantopian, being young, is not set up yet for being able to queue changes to be tested by a number of people dedicated to that role.

So, typically the way it goes here is that someone from Q will thank you for your fine ideas and mention that their priorities are focused on new features right now, yet they have added your suggestions to their todo list and at that point, we'll see.

One thing I would like: A new developer who would work only on suggestions by users. :P
For example, they said paper trading can now qualify an algo for the fund, real money not needed (t-h-a-n-k-s), so one might be likely to enable a long list of paper trading algorithms. Wouldn't it be sweet to be able to see how they are doing comparatively by looking at that list? A Returns column, a user request similar to yours above and the type of thing the new dev can do.

Mark - thanks for the feedback. They both make sense. On the first one, I'm putting that into a list with an overhaul of our error messages. We have far too many cryptic error messages that aren't helpful enough to the algo writer, and that's one of them. On the second idea, I put it into the general debugger queue.

Gary - I agree that there is merit in a returns column on the My Algorithms page. There is also merit in additional columns, like max drawdown, a running PnL, Sharpe ratio, and more. The page becomes harder to understand with every column, and the database loadtimes mount too. There is a real design challenge there, and we haven't tackled it yet.

I very much appreciate the suggestion, and I'm not dismissing it. I'm trying to explain why it is, unfortunately, more than a 5-minute fix.

Taking a step back, I think your post is running into the core challenge of a software company, particularly a software startup that is finding its way to revenue. Our challenge isn't coming up with ideas on how to improve the website; we get thousands of them. Our challenge is how to choose which ideas to implement first.

I assure you that community feedback has a heavy weighting in that decision process. We're building a research platform and working on adding support for futures because the community has requested them. The contest itself was a feature request from the very early days (I'm sure we got the request in 2012, and my quick search found this request from 2013). Almost everything we do has come from the community directly or is something that supports a community request.

I hope that helps you understand why requests aren't implemented as quickly as we'd all like. We appreciate your patience, understanding, and support.

Thanks for your comments Dan. Since there appears to be a challenge to build a watch list in the debugger, there is one fix that will help me create an analogous 'watch list' through print statements. The problem is that the log buffer holds print results until some arbitrary limit then dumps several print statements at once into the log window. If a breakpoint is hit during debugging, I know from the debugger time signature there are several print statements per 1 min time step that haven't printed yet, and would be helpful to see while I'm stepping through the debugger code. So, when a breakpoint is hit, please dump all buffered print results into the log window. Thx!