apidays LIVE New York 2021 - Communication is just as Important as Code by M. Scott Ford, Corgibytes LLC
•Download as PPTX, PDF•
0 likes•222 views
apidays LIVE New York 2021 - API-driven Regulations for Finance, Insurance, and Healthcare July 28 & 29, 2021 Communication is just as Important as Code M. Scott Ford, CEO at Corgibytes LLC
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to apidays LIVE New York 2021 - Communication is just as Important as Code by M. Scott Ford, Corgibytes LLC
Similar to apidays LIVE New York 2021 - Communication is just as Important as Code by M. Scott Ford, Corgibytes LLC (20)
More from apidays
More from apidays (20)
Recently uploaded
Recently uploaded (20)
apidays LIVE New York 2021 - Communication is just as Important as Code by M. Scott Ford, Corgibytes LLC
- 2. @mscottford
- 5. @mscottford
- 7. @mscottford
- 9. @mscottford SOMEONE WHO SPEAKS SEVERAL LANGUAGES POLYGLOT
- 10. @mscottford Here’s another language you can add to your tech stack…
- 12. @mscottford
- 13. @mscottford ANY ORGANIZATION THAT DESIGNS A SYSTEM WILL PRODUCE A DESIGN WHOSE STRUCTURE IS A COPY OF CONWAY’S LAW Source: http://www.melconway.com/Home/Conways_Law.html
- 16. @mscottford “THERE IS NO CORRELATION BETWEEN HAVING A COLLEGE DEGREE AND BEING A GOOD SOFTWARE ENGINEER.” DEGREE ENVY Source: http://www.wsj.com/articles/heres-a-thing-coders-can-skip-college-1427985222 - Mike Rosenbaum
- 17. @mscottford “THERE IS NO CORRELATION BETWEEN HAVING A COLLEGE DEGREE AND BEING A GOOD COMMUNICATOR.” DEGREE ENVY Source: fifteen years of experience training technical people how to communicate - Andrea Goulet
- 19. @mscottford EVELOPED BY LISTENING & UNDERSTANDIN APPLIED BY PERSPECTIVE TAKING EMPATHY Source: Practical Empathy by Indi Young
- 22. @mscottford SYNCHRONOUS ASYNCHRONOUS OBVIOUS NOT OBVIOUS VIDEO CALLS PHONE CALLS MEETINGS EMAIL SLACK TEXTSTWITTER FORUMS DOCUMENTATION COMMUNICATION IN SOFTWARE
- 23. @mscottford SYNCHRONOUS ASYNCHRONOUS OBVIOUS NOT OBVIOUS VIDEO CALLS PHONE CALLS BODY LANGUAGE MEETINGS EYE CONTACT PUNCTUALITY EMAIL SLACK TEXTSTWITTER FORUMS DOCUMENTATION COMMUNICATION IN SOFTWARE
- 24. @mscottford SYNCHRONOUS ASYNCHRONOUS OBVIOUS NOT OBVIOUS VIDEO CALLS PHONE CALLS COMMITS BODY LANGUAGE MEETINGS EYE CONTACT PUNCTUALITY EMAIL SLACK TEXTSTWITTER FORUMS DOCUMENTATION COMMUNICATION IN SOFTWARE
- 25. @mscottford SYNCHRONOUS ASYNCHRONOUS OBVIOUS NOT OBVIOUS VIDEO CALLS PHONE CALLS COMMITS NAMING BODY LANGUAGE MEETINGS EYE CONTACT PUNCTUALITY EMAIL SLACK TEXTSTWITTER FORUMS DOCUMENTATION COMMUNICATION IN SOFTWARE
- 26. @mscottford SYNCHRONOUS ASYNCHRONOUS OBVIOUS NOT OBVIOUS VIDEO CALLS PHONE CALLS EMAIL SLACK TEXTS COMMITS NAMING BODY LANGUAGE TWITTER MEETINGS EYE CONTACT PUNCTUALITY FORUMS SCENARIOS TESTS DOCUMENTATION COMMUNICATION IN SOFTWARE
- 27. @mscottford SYNCHRONOUS ASYNCHRONOUS OBVIOUS NOT OBVIOUS VIDEO CALLS PHONE CALLS EMAIL SLACK TEXTS COMMITS NAMING BODY LANGUAGE TWITTER MEETINGS EYE CONTACT PUNCTUALITY FORUMS PULL REQS SCENARIOS TESTS DOCUMENTATION COMMUNICATION IN SOFTWARE
- 28. @mscottford SYNCHRONOUS ASYNCHRONOUS OBVIOUS NOT OBVIOUS VIDEO CALLS PHONE CALLS EMAIL SLACK TEXTS COMMITS NAMING BODY LANGUAGE TWITTER MEETINGS EYE CONTACT PUNCTUALITY FORUMS TIMESHEETS PULL REQS SCENARIOS TESTS DOCUMENTATION COMMUNICATION IN SOFTWARE
- 29. @mscottford SYNCHRONOUS ASYNCHRONOUS OBVIOUS NOT OBVIOUS VIDEO CALLS PHONE CALLS EMAIL SLACK TEXTS COMMITS NAMING BODY LANGUAGE TWITTER MEETINGS EYE CONTACT PUNCTUALITY FORUMS TIMESHEETS PULL REQS ERRORS SCENARIOS TESTS DOCUMENTATION COMMUNICATION IN SOFTWARE
- 30. @mscottford THE ARTIFACTS OF YOUR IDEAS OMMUNICATIO
- 31. @mscottford THE ARTIFACTS OF YOUR IDEAS OMMUNICATIO (hey, that’s not that different than code)
- 33. @mscottford CODE WITHOUT TESTS LEGACY CODE Source: Michael Feathers
- 34. @mscottford CODE WITHOUT COMMUNICATION ARTIFACTS LEGACY CODE Source: Andrea Goulet
- 35. @mscottford
- 41. @mscottford THE STRUGGLE IS REAL CONTEXT SWITCHING
- 43. @mscottford
- 44. @mscottford
- 45. @mscottford OU’LL BE SHOCKED HOW OFTEN YOU DO TH SHATTERING GLASS
- 46. @mscottford
- 48. @mscottford WELL, ACTUALLY YES, AND
- 53. @mscottford OMMUNICATIO IS A SKILL YOU CAN LEARN.
- 54. @mscottford OMMUNICATIO IS A SKILL YOU CAN LEARN. I BELIEVE IN YOU.
- 55. @mscottford
Editor's Notes
- So, this is me and my business partner, Andrea. We went to high school together. We became business partners after connecting at our 10 year reunion.
- I’m very much the stereotypical developer
- Andrea is not. When we first started working together, Andrea was by and far the better communicator. Her degree was in marketing and business law, and she had a lot of success working as a copywriter. But she dove head-first into software development and learned a ton. I’ve been working on doing the same when it comes to communication. But we’ve both faced some harsh stereotypes when forging this journey. Andrea was once asked if she codes, following a long meeting with a client Where she was doing most of the talking
- Since the question came up most often when she was shaking people’s hands She got this tattoo to signal to people that she knew what she was talking about.
- I’ve also had to struggle with sterotypes I’ve been told for most of my career that I shouldn’t be talking to customers.
- This idea has even been commented on in movies Someone was put between me and the customer, Because it was determined that I wasn’t capable of speaking with them
- I really started to believe this. When we first started working together, communication was something that I avoided. I would intentionally ignore emails. And when I would write them, I tried to keep them as short as possible. I tried to be very efficient. I got frustrated when I had to repeat myself.
- Andrea really challenged me. She learned that I was passionate about the idea of a polyglot developer I like to work with many different programming languages. I take pride in my ability to do so.
- So Andrea said that there was another language that I should add to my tech stack And this is a challenge that I extend to all of you as well.
- Add your team’s spoken language as one that you study and get better at Pay attention to grammar, syntax, tone, clarity, cleanliness All of the things that are valued when writing code
- If you feel that communication isn’t important Consider the impact that it has on a codebase Because it turns out that your communication structures really matter At Corgibytes, we specialize in working with older, neglected, systems We genuinely enjoy transforming them into modern, clean, systems But we’ve noticed a theme over the years. Poor communication creates poor systems There’s even a popular systems law about this
- It’s called Conway’s Law And this is why we end up with legacy rescue projects Not because the tech is bad But because the communication within an organization is incredibly poor Many of the organizations with this challenge have another common symptom
- They divide people into two buckets Technical and non-technical - But here’s the thing: it’s not an either or. Being technical or non-technical is not binary. We are quickly approaching a world where communication skills are no longer optional.
- You have to be both So that’s why we encourage people to talk about being more and less technical And realize that if you’re working on a software project in any capacity, then you _are_ technical
- degree envy. Something that comes up a lot in the software industry is The idea that you have to have a Computer Science degree To be good at software But the experience of many people, myself, included is that this simply isn’t true
- So what about communication? Andrea taught me that I don’t need to go out and get a degree to be a better communicator. It is an attainable skill. It’s within my reach. It takes you outside of your comfort zone, But like Zeno said earlier today, that’s where the magic happens.
- So here’s a crash course. And it starts by asking the question: what is communication?
- The first thing to understand is that effective communication is rooted in empathy. Empathy is a noun. It’s a thing that you acquire. It’s a skill that you build. You get it by listening and truly understanding another person Even if that person is your future self. Then, once you’ve acquired empathy, you apply it by looking at the world from a different perspective.
- We can also describe communication by looking at the artifacts that we leave behind. And a good way to think of this is too look at the different types of events: - synchronous and asynchronous.
- And then we have OBVIOUS and NOT OBVIOUS
- There are some obvious examples here. Phone calls, meetings, screenhero. Those are synchronous. Twitter, text messages, email, stack overflow. Those are asynchronous.
- Then there are some non-obvious forms of communication. On the synchronous side, things like eye contact, body language, whether or not you show up to an event on time or late. Those happen at the same time, but because they’re non-verbal, we don’t often think of it.
- On the asynchronous side we have things like Commit messages, which we believe will always be the best form of documentation. How often do you use the “description” field in your commits? That’s the best place to describe WHY you made a change and give context that might be useful to someone else later. It’s also useful because this comes up if you ever get so frustrated and run git blame…. and then it came up as yourself. Explaining the rationale of your commits is super helpful to others, even your future self.
- We also have names: variables, methods, classes. Are you naming things in a way that makes sense to other people? Or are foo and bar your best friends?
- If you’re using Test Driven Development and Behavior Driven Development, those are important artifacts.
- We do code reviews on Pull Requests. Are they thoughtful? Well organized? It it easy to understand your intention? All of that is communication.
- Many of us are consultants and have to fill out timesheets. Do you fill out the comments? That’s a form of communication. TIMESHEETS = EMPATHY FOR CUSTOMER
- And finally, my biggest pet peeve. Error messages. How many of you have ever come across a completely useless error message when you’re working? So frustrating! I sometimes feel like my mission in life is to rid the world of bad error messages by teaching developers how to communicate well. ERROR MESSAGES = EMPATHY FOR THE USER
- So here’s how I define communication. It’s just the artifacts of your ideas. That’s it. There are a lot of different forms, but don’t stress.
- Communication isn’t that different than code, and it’s just as important.
- So at Corgibytes, all we do is Legacy Code. We do a lot of upgrading frameworks, adding automated test suites, paying down tech debt. And we freaking love it. There are so many interesting engineering problems and solving them brings real value to our clients. Most people hate working on legacy code, but I think part of the reason is that legacy code is notoriously void of communication. You can’t work on legacy projects unless you have really good communication. We know this because of Conway’s Law.
- Michael Feathers defines legacy code as “code without tests” But that definition becomes problematic because it’s polarizing. And 100% test coverage isn’t realistic And if you’re just experimenting or just building a proof of concept and don’t plan to push anything to production, do you really need tests?
- So I think it’s time we expand that definition. Legacy code is code without communication artifacts of which tests are just a small part.
- I think of it as an archaeology project. Tests might be something important like bones. They tell you a lot. But you also have pottery, coins, buildings, writing, paintings. The more artifacts you have, the better understanding you can get about the culture that was there. Communication is the same. Lots of different things and they all add up to give you insight.
- Okay. So why does this matter? Three reasons.
- First, getting better at your communication is the best way to level up your career. If you want be a Lead Dev, a CTO, or own your own business, communicating effectively with people who don’t code every day is a big part of your job. If you want people to contribute to your open source project, communication is what makes them feel welcome and keeps them around. And if you want other people to use your ideas, you need to learn how to blog, speak, and maybe even write books. All of that is communication.
- The next reason is that communication builds trust. In her book, Daring Greatly, Brene Brown describes trust as a marble jar. Her daughter’s teacher would drop a marble in a jar when the class behaved and when they got to the top, they got a pizza party. Trust works the same way. It’s built over time by a series of very small interactions. Those small interactions are communication. Every artifact is a marble in the jar. Every time you communicate. Every time you leave an artifact of your ideas, you are communicating and building trust.
- And finally, good communication is the best way to ensure you don’t run around and fight fires all the time. At Corgibytes, one of our core values is Calm the Chaos. We believe the best solutions to problems don’t happen when you’re stressed out and pumped full of adrenaline. It comes when you’re calm, rational, and using your prefrontal cortex. That can only happen when your culture is soaked in good communication.
- The good news is that there are several patterns and frameworks we can lean on to improve our communication. I’m going to go over my three favorites. But first, let’s note how these aren’t static. In his book “Refactoring to Patterns”, Joshua Kerievsky talks about how you can move towards or away from patterns through all of the small choices you make. Improving your communication works the same way. It takes awareness and happens when you make the conscious choice to refactor your habits.
- The first concept we’ll touch on is about context switching. There is a real cost associated with this. You know it. But how do you communicate that with your team mates who don’t code? Before I understood the cost of context switching, I used to ask Scott all the time “Hey, you got a sec?” I was genuinely trying to be courteous. And I was surprised when his reaction was
- getting so visibly frustrated I thought he would flip the desk over.
- One day, I asked Scott why he was so frustrated and he said “I was like 7 inception layers down” We had just seen the movie Inception, which is about a dream within a dream within a dream. In the movie, if you were too many levels down and you came out too quickly, you could get hurt. Like the mental equivalent of The Bends.
- So we developed a framework to communicate more easily. When I ask “do you have a sec?” that’s not easy to answer. Scott has to evaluate - Is a “sec” five or twenty minutes? How important is what I’m currently working on? Am I in a good stopping place? And then he watches his productivity bubble burst. But if all he has to do is label where he is, he can communicate whether he’s interruptible without switching context. Above 2, he comes back to me when he’s safely back on the surface.
- Next is what I call the Shattering Glass pattern.
- Basically, you want to be less like Ted and more like Tina. In the show How I Met Your Mother, one of the main characters, Ted, starts to notice how often he says the words…
- Basically, you want to be less like Ted and more like Tina. In the show How I Met Your Mother, one of the main characters, Ted, starts to notice how often he says the words…
- Basically, you want to be less like Ted and more like Tina. In the show How I Met Your Mother, one of the main characters, Ted, starts to notice how often he says the words…
- This is a framework developed by Kim Scott, who used to run the AdWords team at Google. Her boss was Sheryl Sandberg. She calls the CARE PERSONALLY axis the “GIVE A DAMN” axis. And the CHALLENGE DIRECTLY axis the “WILLING TO PISS YOU OFF” axis. When you have both, she calls it Radical Candor.
- When you speak with Radical Candor, it has these elements. It’s HUMBLE. It’s HELPFUL. It’s IMMEDIATE. If you need to criticize someone, you do it privately. And when you praise them, it’s public. And when you criticize, you talk about the work, not the person. You don’t PERSONALIZE it. (story of Kim and Sheryl Sandberg if time)
- If you get nothing out of this talk, remember communication is a skill.
- You can learn how. If you can learn how to code, you can learn how to communicate.
- And know that I believe in you. Just like you believed in me and told me I could learn how to code when I didn’t believe in myself.
- Here are some resources to help you get started. Dive into getting curious about communication the same way you learned how to code. Add English to your tech stack, and we’ll all make the open source world just a little better.