Well done guys. For good insights on how you could approach some UX challenges in a tool like Plotly, I highly recommend watching Bret Victor's "Drawing Dynamic Visualizations".

For the non-Plotly folks reading this, Bret's presentation is also very effective at blowing your mind in general.

http://vimeo.com/66085662

Thanks! We are indeed huge fans of @worrydream

Just like with any technology stack.

What other things do you do regularly? Write emails, specs, contracts, documentation?

Of course you probably also do other stuff than typing on a keyboard. It's just that the keyboard often is the most efficient interface between you and your main tool, your computer.

I think typing speed is a good competency to improve to be more efficient in the next few decades.

What James is referring to is not necessarily stripping out big pieces of code when they've been working in production for a while. Rather the point is that in a given coding sprint, he gets the first thing that works going, then starts from there and rewrites them better if need be. So it's just an approach to developing a given method or class rather than refactoring for the heck of it.

I know what he's referring to.

You're a coder. I'm a coder. James is certainly a coder's coder. But stop thinking like a coder for just a moment, though.

Having (functional) product out the door (faster) beats having (better) code in the market (later). Every time.

Do I defend this? Yes and no.

Have I experienced this? Yes.

Wearing my manager hat, the product ships. Code refactoring is extremely difficult to justify.

Wearing my coder hat, I refactor and re-comment and rework and update the test cases while I still remember what I was doing with the particular routines. Then I move on.

This is the age-old conflict between better and faster; elegance and schedule. It's why managers and coders are so often in conflict, too.

True, but code is rarely ever shipped then abandoned. Refactoring is (hopefully) all about making code more manageable and as reusable as possible, not attaining some sort of aesthetic elegance.

I totally agree, and this is exactly what I do an the method/micro level. Generally I can get something working in just a few minutes but then I spend another 5-10 really polishing it up in 5+ small iterations on it (all test driven, so I know my changes still work).

Hoff's point was well above that, at the design/macro level. For that I alternate releases between adding features and house cleaning (bug fixes, refactorings, etc). With a sufficiently short iteration time, you can appease both the client/users with new features and the developers by keeping things clean and happy.