Monday, December 18, 2017

Montreal seeks to be world leader in responsible artificial intelligence research | Montreal Gazette

Montreal seeks to be world leader in responsible artificial intelligence research | Montreal Gazette: "Abhishek Gupta "



'via Blog this'

Innovation - How to explain code to someone

Ask Slashdot: How Can Programmers Explain Their Work To Non-Programmers? - Slashdot : https://ask.slashdot.org/story/17/12/16/0015204/ask-slashdot-how-can-programmers-explain-their-work-to-non-programmers?sbsrc=md

Case in point: Home for the holidays, I was asked about recent accomplishments and attempted to explain the process of producing compact visualizations of branched undo/redo histories.

You've gone into the wrong kind of detail. The useful answer generally has the form "X is the general problem that people have which you can relate to in some way from your personal experience. Y is the state of the art. I've improved upon the state of the art in Z."

Thus: "You know how sometimes in Word you type a paragraph, then want to undo it and start again, but you sometimes want to keep a sentence or two from the thing you typed even though you undid it? People usually use copy+paste, if they remember, but it gets hard to keep track and sometimes you accidentally mess things up so you can't redo back to your first draft. You're confused at this stage? -- exactly! :) Well, I've been working on a new way that avoids the pitfalls. It seems to be working, and users have been giving good reports so far. I'm not adding it in Word of course. But who knows? maybe my idea will catch on."

People aren't interested in the technical details of your solution. They're more interested in the general scope of human endeavor, and the conflicts and social dynamics in the research field. So if you meet a researcher or a PhD student, the second question you ask them (after "what's your field?") is "what are the main opposing ideas in the field?"

If you're not advancing the state of the art in any way, and if you're just implementing a solution that someone else has done, again don't talk about the technical details of the implementation. For instance you're doing a back-end database and you're copying some scaling algorithm/implementation from someone else, you can say "Imagine how Amazon must have to process like two hundred million order requests every day? My company also needs to process one hundred million widgets. We're not quite at the same scale as Amazon, but I've been copying some of their techniques too. It's fun. I've learned [incidental social fact about the human endeavor that is software development]".

My day job is doing technical implementation of language features inside a code editor (think autocomplete, signature-help, hover, ...). Even when I'm speaking with my MANAGERS and PEERS I don't talk about the technical side. The first and last thing to talk about is always what's my overall mission? and specifically, what user-facing problems/scenarios am I trying to solve? The technical details is always an afterthought. Successful software engineers are primarily good communicators.


Montreal seeks to be world leader in responsible artificial intelligence research | Montreal Gazette