chore(archive): perform canonical audit on Jen Myers and Katrina Owen

Author: just3ws

_data/transcripts/interview-with-jen-myers-general.yml

@@ -141,3 +141,132 @@ content: |-
    Well, thank you very much for sitting down.
    Absolutely.
    Thank you.
+speaker_map:
+  M1:
+    name: Mike Hall
+    role: Interviewer, community organizer at UGtastic
+  S1:
+    name: Jen Myers
+    role: Digital Native Designer and Developer, Speaker at Relevance
+turns:
+- speaker: M1
+  text: Hi, I'm Mike with UGtastic. I'm here again at SCNA. I'm sitting down with
+    Jen Myers from Relevance. You're a designer—a digital native designer—and you
+    speak to technical audiences, programmers, and developers, as well as designers.
+    I believe there's probably a big difference between those two audiences. Do you
+    see any difference when you speak to them?
+- speaker: S1
+  text: There are some differences, and I'm definitely more comfortable in the 'techie'
+    community, for lack of a better term. That's where I started and where I feel
+    most at home. When I speak to designers, I actually feel a little bit like I'm
+    on the other side because I spend so much time in the technical landscape. But
+    there are definitely differences. I know a lot of people in the UX community,
+    which is almost a subset of the larger design community. They work with different
+    mediums—some are product designers—but it's still interesting to find the common
+    ground. It sometimes just takes a little more work to figure out a designer's
+    perspective and what medium they work in compared to the tech community.
+- speaker: S1
+  text: I do think designers tend to see a larger sense of things. Not to say tech
+    people are narrow-minded—not at all—but designers like to have the large picture
+    and know how everything fits together. I'm like that myself. That's one thing
+    I like to talk to developers about, because it's easy to get wrapped up in details.
+    Details are important, but having larger context is vital, whether you're building
+    a product or dealing with a community.
+- speaker: M1
+  text: You used the term 'digital native designer.' What does that mean?
+- speaker: S1
+  text: That's a term I've started to coin to describe myself. I am a designer who
+    works in software, but I don't have a formal design background. I didn't come
+    from a print background and then learn to do it; I learned design by learning
+    HTML back in 2001. I started in a digital landscape. Everything I've learned about
+    design theory and principles has always been applied digitally. I've done some
+    print projects, but they are more of a struggle because I'm used to the flexibility
+    of digital. I get nervous with print because I can't change it afterward! A 'digital
+    native designer' understands how design specifically works in this digital medium,
+    with all its unique implementations and needs.
+- speaker: M1
+  text: When you talk to technical audiences, is there anything that is particularly
+    hard to get across? Something that just doesn't click?
+- speaker: S1
+  text: Universally, I have really good experiences talking to developers. I've spoken
+    about this at many conferences and I always have developers come up to talk to
+    me. They often ask how they can learn, and many feel like they can't. I don't
+    think there's any one thing holding them back other than not knowing where to
+    start. It's about how we are educating people and sharing information. Designers
+    need to be more explicit and clear so that developers understand, but pretty much
+    universally, the developers I talk to are really interested in learning these
+    things on their own.
+- speaker: M1
+  text: SCNA is a polyglot conference, but you've also spoken at Ruby-specific events.
+    Do you notice signature styles between different platforms, like .NET vs. iOS
+    vs. Rails? And now with Bootstrap becoming so ubiquitous—does that concern you?
+- speaker: S1
+  text: It doesn't really concern me. I think it's okay. Bootstrap isn't the solution
+    for everything, but in many situations, it makes sense to use it. There are different
+    solutions for different problems. As long as people are still going back to those
+    design foundations and staying in touch with the collaborative process, it's fine.
+    It's about making deliberate decisions. If you're just doing things unthinkingly
+    because everyone else does, that's probably not the best thing. But developing
+    platform-specific solutions isn't bad as long as we continue to think deliberately
+    about them.
+- speaker: M1
+  text: Well, thank you very much for sitting down with me.
+- speaker: S1
+  text: Absolutely. Thank you.
+insights:
+- statement: 'The ''Digital Native Designer'' represents a shift in the industry:
+    practitioners who learned design through the constraints and capabilities of code
+    (HTML/CSS) rather than traditional print mediums, leading to a deeper understanding
+    of digital interactivity and flexibility.'
+  type: durable
+  confidence: high
+- statement: Designers bring value to technical teams not just through aesthetics,
+    but by maintaining the 'large picture' context—ensuring that small technical details
+    align with the overall product and community goals.
+  type: durable
+  confidence: high
+- statement: The primary barrier for developers learning design isn't a lack of aptitude,
+    but a lack of accessible starting points and clear, explicit communication from
+    the design community.
+  type: durable
+  confidence: high
+- statement: Standardized UI frameworks like Bootstrap are not inherently harmful
+    to design diversity as long as they are chosen as a deliberate solution for a
+    specific problem rather than an unthinking default.
+  type: durable
+  confidence: medium
+- statement: Design principles are universal, but the medium (print vs. digital) fundamentally
+    changes the process; digital design requires an embrace of change and resizing
+    that traditional print design often fears.
+  type: durable
+  confidence: high
+youtube:
+  title: 'Digital Native Design: Jen Myers on Bridging the Gap Between Code and Context
+    | SCNA 2013'
+  description: Mike Hall sits down with Jen Myers at SCNA 2013 to explore the concept
+    of the 'digital native designer.' They discuss why designers are essential for
+    maintaining product context, the common misconceptions developers have about their
+    own ability to learn design, and why ubiquitous frameworks like Bootstrap are
+    a deliberate tool rather than a threat to creativity.
+  tags:
+  - Design for Developers
+  - Digital Native
+  - UX
+  - Software Craftsmanship
+  - SCNA 2013
+  - Bootstrap
+  - HTML/CSS
+  - Product Strategy
+  chapters:
+  - timestamp: '00:00'
+    title: Introduction and Technical Communities
+  - timestamp: '01:30'
+    title: 'The Designer''s Perspective: Context vs. Details'
+  - timestamp: '02:45'
+    title: Defining the Digital Native Designer
+  - timestamp: '04:30'
+    title: Why Developers Can (and Want to) Learn Design
+  - timestamp: '06:15'
+    title: Signature Styles and the Rise of Bootstrap
+  - timestamp: '08:00'
+    title: Making Deliberate Design Decisions

_data/transcripts/interview-with-katrina-owen-general.yml

@@ -139,3 +139,132 @@ content: |-
    user groups with lots to say interviews and more no way sharing great ideas in the tech community
    fascinating conversations a plethora of information find out for yourself today at ucdastic.com
    foreign
+speaker_map:
+  M1:
+    name: Mike Hall
+    role: Interviewer, community organizer at UGtastic
+  S1:
+    name: Katrina Owen
+    role: Developer and Open Source Contributor, Creator of Exercism.io
+turns:
+- speaker: M1
+  text: Hi, it's Mike with UGtastic. I'm here at SCNA 2013 and I'm sitting down with
+    Katrina Owen, who is going to be giving a talk called 'Here Be Dragons.' You're
+    the last talk of the sessions, so I wanted to make sure we caught up now. 'Here
+    Be Dragons'—what does that mean?
+- speaker: S1
+  text: It's a reference to old mapmaking where explorers would draw dragons in the
+    parts where they didn't know what was there. My talk is a code review, so it's
+    a metaphor for all the scary things you don't know are in the code. I'm using
+    an anonymized version of production code I ran into a couple of years ago.
+- speaker: M1
+  text: Does the person who wrote it know you're doing this?
+- speaker: S1
+  text: No, hence anonymized. It's actually kind of awkward because they weren't on
+    the team when the bug was reported. I started looking at the code, and it was
+    crazy, so I asked around the office to see who wrote it. Nobody recalled writing
+    it! When I finally checked git blame, I found out who it was, and they truly had
+    no recollection. That happens when you have thousands of lines of code over years.
+    And sometimes, you check git blame and the 'idiot' who wrote the code was actually
+    you.
+- speaker: M1
+  text: That's a good reminder to be kind, especially when the person who wrote it
+    might be sitting right next to you. What makes this specific code worth a talk?
+- speaker: S1
+  text: The code is so bad it has a punchline, but I really use it as an excuse to
+    talk about the people issues. We have a tendency toward the Fundamental Attribution
+    Error—assuming code is terrible because the author is 'stupid' rather than understanding
+    the pressures they were under. Maybe they were new to the language, or under a
+    tight deadline, or just really tired. If we knew the pressures, we would assume
+    they wrote it that way for a passing, temporary reason.
+- speaker: M1
+  text: There was a recent situation on Twitter where someone was blasted for a first-time
+    open source contribution, and it was quite harsh. It made people think about being
+    kinder. Is that the line you're walking?
+- speaker: S1
+  text: 'I do tear this code apart because it makes a good story, but in real life,
+    I try to be both kind and realistic. I look at the code and ask questions about
+    context: ''What trade-offs did you consider? Why did you go in this direction?''
+    Sometimes they say, ''I didn''t know that method existed,'' and I learn something
+    too. Other times, they had a constraint I didn''t see. We aren''t fixed points
+    of intelligence; we flex based on context.'
+- speaker: M1
+  text: So the point is to be context-aware rather than context-free.
+- speaker: S1
+  text: Exactly. Stay aware of the fact that there is context. Let that inform the
+    questions you ask rather than the judgments you make.
+- speaker: M1
+  text: I think that's a great point. One goal of these interviews is to humanize
+    people who are otherwise only known through technical personas or online handles,
+    where they can sometimes be abused because people forget they are human. We all
+    make mistakes and fumble.
+- speaker: S1
+  text: The reason I wanted to do this talk is that I'm actually very bad at empathy.
+    People talk about it constantly, but I can't always conceive of what they mean.
+    However, when you explain it as 'asking about the pressures rather than making
+    judgments about who they are,' I can do that. I know how to ask questions. That
+    is a concrete way I can practice empathy, even if I'm someone who is naturally
+    quick to judge.
+- speaker: M1
+  text: If we can feel frustration with the code, we can probably bet the author was
+    frustrated writing it too. It all comes back to context.
+- speaker: S1
+  text: Yeah. Thank you for having me.
+- speaker: M1
+  text: Thank you, Katrina.
+insights:
+- statement: 'The Fundamental Attribution Error in software: Developers often attribute
+    ''bad code'' to the author''s lack of intelligence (dispositional) rather than
+    the external pressures, deadlines, or lack of knowledge at the time (situational).'
+  type: durable
+  confidence: high
+- statement: 'Empathy as a technical practice: For those who find the abstract concept
+    of empathy difficult to grasp, it can be operationalized as ''asking about the
+    pressures and constraints of the author'' rather than making character judgments.'
+  type: durable
+  confidence: high
+- statement: 'The ''Git Blame Paradox'': The emotional distance provided by technical
+    tools can lead to harsh judgments of others, yet we often find ourselves being
+    the very authors of the code we once criticized.'
+  type: durable
+  confidence: high
+- statement: 'Code review should be a dialogue of discovery: Asking ''Why did you
+    go in this direction?'' often reveals hidden architectural constraints that the
+    reviewer was unaware of.'
+  type: durable
+  confidence: high
+- statement: 'Intelligence is not a fixed point: A developer''s performance varies
+    significantly based on current context (tiredness, personal stress, environment),
+    and code represents only a single snapshot of that fluctuating capability.'
+  type: durable
+  confidence: medium
+youtube:
+  title: 'Here Be Dragons: Katrina Owen on Operationalizing Empathy in Code Review
+    | SCNA 2013'
+  description: Mike Hall sits down with Katrina Owen (creator of Exercism.io) at SCNA
+    2013 to discuss her talk 'Here Be Dragons.' They explore the psychology of code
+    review, the 'Fundamental Attribution Error' that leads us to judge other developers
+    too harshly, and how to practice empathy by asking about constraints and pressures
+    rather than making character judgments.
+  tags:
+  - Code Review
+  - Software Craftsmanship
+  - Katrina Owen
+  - Exercism
+  - Empathy in Tech
+  - SCNA 2013
+  - Git Blame
+  - Psychology of Programming
+  chapters:
+  - timestamp: '00:00'
+    title: Introduction and Mapmaking Metaphors
+  - timestamp: '01:15'
+    title: The Git Blame Surprise
+  - timestamp: '02:30'
+    title: The Fundamental Attribution Error
+  - timestamp: '04:15'
+    title: 'Walking the Line: Critique vs. Kindness'
+  - timestamp: '06:00'
+    title: Operationalizing Empathy for the Logical Mind
+  - timestamp: '08:15'
+    title: Intelligence as a Fluctuating State