Having been in Japan for a year, I’ve always wondered how any foreigner-based startups could possibly thrive (or even survive) in the insular business culture. This is a fascinating account of one company’s successes and failures in selling software as a service to small-medium Japanese businesses.
Cross-posted. I wrote a post this morning for the CS K-12 Education seminar, summarizing what we learned about getting CS into Seattle Public Schools.
When you are receiving a critique, it’s extremely tempting to rationalize your design decisions – to explain why you did the things you did. This will always come across as defensive, because it is: your rationalization is actually a way of showing that you’ve thought through the trajectory of the conversation and already considered (and judged) the end state. The defensive quality of a rationalization changes the conversation from a way to produce new knowledge to a verbal debate.
“
| — | Jon Kolko on being at the receiving end of a design critique, in “Do you want critique, or a hug?”, published Monday. |
In my opinion, the UX of IDEs is a bigger problem than the limited applicability of program visualizations, live code execution, or refactoring tools. What could increase the productivity of developers more, better displaying information that’s already there (but hard to use or access), or digging up new information that developers didn’t know that they needed?
Probably a combination of amnesia and not-invented-here syndrome. Microsoft has incredible churn, and a lot of employees (especially those fresh out of school) lack exposure to other software ecosystems. I’m not terribly surprised their DevDiv API designers are able to shoot the same foot repeatedly.
