SlideShare a Scribd company logo
1 of 50
Download to read offline
Crafty
communications
DEALING WITH THE PESKY PEOPLE PARTS OF COMMUNICATIONS
Asher Glynn
Crafty communications - Dealing with the pesky people parts of communications
Cathedrals in the sky
Miniatures for the eye
The skills to build wonders
 Repetition and practice
 On the job education
 Communicating – working as a team
The language of craft
 Each craft builds its own language
 Each craft has problems communicating with other crafts
 Each craft is prone to relabel or abbreviate basic terminology
 Or be overly pedantic
 Measurements in millimeters only (building)
 Or be quite specific to a country
 Cups for baking (Australia vs US cup not the same)
 Or be dismissed as just using “jargon” when there is something very
specific going on
The language of craft
 Liquor = water (brewing)
 Mud = wet mortar (brick laying)
 Plumb = lead weight for determining vertical (building)
 Cover = customer (restaurants)
 Vigorish = house edge (sports betting – US specific)
 Ruck and maul = trying to murder the opposing player (Rugby Union)
 Datacentre = where servers live (Technology)
 User = someone with a heartbeat (Technology)
 Code = ??? (Technology)
Crafty communications - Dealing with the pesky people parts of communications
Crafty communications - Dealing with the pesky people parts of communications
The language of craft
 Techniques for building a common language
 User stories
 Pair programming
 Design patterns
 Reviewing for intent
 Avoidance
The language of craft
 User stories
 For a developer to demonstrate they understand requirements
 Less formal than Use Cases
 Look easy
 Where it works
 When developers write them
 And users read them
 Where it goes horribly wrong
 Nobody reading them
 A non stakeholder writing them
The language of craft
 Pair programming
 Out of the Extreme Programming toolbox
 Where it works
 Exploring a new problem domain
 Exploring a new code base
 Where it goes horribly wrong
 Religious wars
 Turning a developer into a pure typist
The language of craft
 Design patterns
 Abstractions of common coding patterns
 Should emerge from a code base
 Libraries give a common language for describing things
 Where it works
 When someone has read the book(s) and applied it to a code base
 A shortcut for explaining what is going on
 Where it goes horribly wrong
 Using every pattern
 Shortcuts turn into long cuts
The language of craft
 Reviewing for intent
 Can you read the code?
 Do you understand the intent of the developer?
 Can you do that without resorting to comments?
 Where it works
 Explore the software architecture
 Familiarise everyone with code
 Where it goes horribly wrong
 Code standards zealots
 Really really really bad code
Reviewing for intent
 Example (from Magnolia CMS)
 https://git.magnolia-
cms.com/projects/MODULES/repos/observation/browse/src/main/java/inf
o/magnolia/module/observation/commands/RestrictToTemplateEventListe
ner.java
 I’m not picking on Magnolia…
Reviewing for intent
protected String getRelevantPath(String path, Node node) throws RepositoryException {
if (template == null) {
return path;
}
// if the passed node has not the template which is observed, also checking parent nodes.
// if a parent has that template, command is executed for the path of that parent-node
while (node != null && !template.equals(NodeTypes.Renderable.getTemplate(node)) && path.length() > 1) {
node = node.getParent();
// no more parents
if (node != null) {
path = node.getPath();
}
}
// if after searching we don't find a node of the type we don't execute the event
String nodeTemplate = NodeTypes.Renderable.getTemplate(node);
if (node == null || !template.equals(nodeTemplate)) {
logger.warn("Returning null path as node was null.");
return null;
}
return path;
}
}
Reviewing for intent
 Good
 Comments
 Clear exit points
 Consistent with general approach (if you look at other Magnolia code)
 Bad
 While clause particularly hard work (structure traversal and business logic
combined)
 Assigns path and node (which disguises intent)
 Returns a null - never nice
 But…
 Idiomatic for the project – other very similar code
Reviewing for intent
 Repeat – I’m not picking on Magnolia
Reviewing for intent
 Whose driving?
 Senior team members
 Benefit of experience
 Tend to make things complicated based on experience
 Will have very distinct opinions on style
 Junior/new team members
 Benefit of naivety
 Are still trying to understand what the code does
 Will have very distinct opinions on style
 No context peers
 Might drive towards a clear “what am I trying to do” review
Reviewing for intent
 Opportunity to discuss style/teach language features
 Consensus based approach
 Team works together to understand code as written
 Not a value judgement on correctness
 Not a value judgement on quality
 Shouldn’t be about syntax
 Although can be a great way to teach Functional Programming
 May help evolve coding conventions
 Or expand understanding
Avoidance
Don’t do it
=
Don’t need language to
describe it
Over engineering
 Developers love engineering for re-use
 Its more fun developing frameworks than solving business problems
 Lines of code still viewed as an indication of productivity
Over engineering
 Metrics
 How many places will you call this code from?
 How many times will you call this code (ever)?
 How many cases do you need to cater for now?
 If the answer is 1 to the above you are probably over engineering…
 Fall back to Unix principles – do one thing well
Personalities
 Communication goes in two directions
 Speaking
 Listening
 Are you:
 Using the same language?
 Using the same idioms?
 Listening?
Personalities
 Are they:
 Listening?
 Wanting to interact with you?
 Wanting the same outcomes?
 Is your self perception clouding things?
Crafty communications - Dealing with the pesky people parts of communications
Princess Programmer
Description Self promoter who, from the outside, will prefer to talk than
actually get on with it
Their perspective Persecuted genius
Your perspective Write some code…
Everything turns into a competition
Ways forward • Give them an opportunity
• Call bluff
• Play with someone else
Crafty communications - Dealing with the pesky people parts of communications
Desperate Dev
Description Component programmer who feels very uncomfortable with
business problems causing a huge number of defects to be
raised by users. Dislikes verbal communication and
confrontation. Constantly “concerned” about issues that
can’t be articulated but never go away
Their perspective Harassed artist
Your perspective Neurotic mess
Ways forward • Use instant messenger to chat
• Sit them with a user in a “production” environment
• Use written lists for concerns
Crafty communications - Dealing with the pesky people parts of communications
Advanced Agile Advocate
 Spends most of the time telling you all about Agile (in their view)Description Continuous barrage of commentary about how you don’t
understand agile
Their perspective It’ll be great just when the upon the coming of the agile
Kingdom of Heaven
Your perspective I get it – user stories, sprint planning, retrospectives, burn
down or kanban boards, lets DO it!
Ways forward • Agree the whole process
• Write it down
• Point back at the written process
• Can’t code, go away
Crafty communications - Dealing with the pesky people parts of communications
Cunning Customer
Description Attempts to be get more whether that be
- More features
- More time
- Just more
Their perspective Highly effective individual contributor – the single reason
anything gets done
Your perspective Not a team player
Ways forward • Win/Win scenarios?
• Better understanding?
• Mutual respect?
• Acceptance of a no win
Crafty communications - Dealing with the pesky people parts of communications
Careless clockwatcher
Description Can I go home yet?
Their perspective This is a job
Your perspective Yes, it’s a job, that involves doing some work
Ways forward • ???
Crafty communications - Dealing with the pesky people parts of communications
Security Sadist
Description Security is important
Very important
Which is why they leave their requirements until just before
you release
Their perspective The last, best chance for humanity
Your perspective Get out of the way
Ways forward • Stop treating them like they are special
• Security requirements are written down – same as every
other requirement
• Security can be tested at the same time as any other tests
Battle-scarred Beardy
Description Anecdoates of how it used to be in the olden days
Their perspective Look at the size of my beard!
Your perspective Punchcards are a bad punchline
Ways forward • Age isn’t an indicator of capability
• Visual appearance isn’t a great
• Be very careful – they might be right…
Process Prince
Description Always one more piece of documentation to be done before
you can release/code/test/do anything
Their perspective All about visibility
Your perspective Why don’t you have a reflection
Ways forward • Processes don’t exist in the ether
• Dummy run the process to demonstrate whether it can
actually be followed
• Follow the process
Crafty communications - Dealing with the pesky people parts of communications
Abstract Architecturists
Description Boxes and lines (optional) which apparently describe a
system
Their perspective Bearer of clarity in a world of chaos
Your perspective Eh, what?
Ways forward • No diagram can show everything
• Audiences for diagrams are important
• May have become accustomed to Executive focus
• Maybe
Crafty communications - Dealing with the pesky people parts of communications
Technology Enthusiast
Description Ohhh shiny
Their perspective I just love technology – why won’t you let me play with new
toy/gadget/platform
Your perspective Confiscate the toys
Ways forward • Dig back to a practical example of why you need to use it
• Be aware you are being sold something
• Engage and don’t immediately dismiss but don’t agree
anything
Crafty communications - Dealing with the pesky people parts of communications
Silent Superstars
Description Sits in the corner quietly coding and popping out with
something amazing
Their perspective Please stop talking with me
Your perspective Can I have 10 of them – if only they could communicate
more effectively
Ways forward • Find non verbal ways to communicate
• Embargo others from interrupting them
• Develop a culture of respect for communication
Solution Soothsayer
Description Can give you an incredibly detailed description of a solution
based on zero facts
Their perspective Hero for rescuing you from the vague requirements
Your perspective Takes the pressure off stakeholders from articulating what
they actually need/want
Ways forward • Slow it down
• Stop the code
• Make it clear that the psychic solution isn’t definitive
Crafty communications - Dealing with the pesky people parts of communications
Ultimately…
 Whats in it for you in the communication?
 What do you want?
 Do you really need to communicate?
A bit about me
 Consult in a variety of capacities (eg
Architecture, Delivery, etc) with a variety of
companies
 Burrowing Deep Consulting – Just me
 Rituala – Delivery
 Vigil365 – Operations
 interim.team – Senior temporary assignments
Refererences
 Use Cases – https://en.wikipedia.org/wiki/Ivar_Jacobson
 Gang of Four Design Patterns - https://www.amazon.com/Design-Patterns-
Elements-Reusable-Object-Oriented-ebook/dp/B000SEIBB8

More Related Content

Similar to Crafty communications - Dealing with the pesky people parts of communications

Hidden sides of Code Review (MMM-2023)
Hidden sides of Code Review (MMM-2023)Hidden sides of Code Review (MMM-2023)
Hidden sides of Code Review (MMM-2023)Dmitrii Ivanov
 
Pragmatic programmer
Pragmatic programmerPragmatic programmer
Pragmatic programmerMaulik Shah
 
Hybrid teaching: Hidden skills and knowledge gaps
Hybrid teaching: Hidden skills and knowledge gapsHybrid teaching: Hidden skills and knowledge gaps
Hybrid teaching: Hidden skills and knowledge gapsDominik Lukes
 
UPA2007 Designing Interfaces Jenifer Tidwell
UPA2007 Designing Interfaces Jenifer TidwellUPA2007 Designing Interfaces Jenifer Tidwell
UPA2007 Designing Interfaces Jenifer Tidwellnikrao
 
UPA2007 Designing Interfaces Jenifer Tidwell
UPA2007 Designing Interfaces Jenifer TidwellUPA2007 Designing Interfaces Jenifer Tidwell
UPA2007 Designing Interfaces Jenifer Tidwellguestf59d1c4
 
Domain Driven Design - DDDSydney 2011
Domain Driven Design - DDDSydney 2011Domain Driven Design - DDDSydney 2011
Domain Driven Design - DDDSydney 2011thinkddd
 
Pair Programming Styles
Pair Programming StylesPair Programming Styles
Pair Programming StylesAttila Bertók
 
Redesigning everything ITARC Stockholm 2021
Redesigning everything ITARC Stockholm 2021Redesigning everything ITARC Stockholm 2021
Redesigning everything ITARC Stockholm 2021Alberto Brandolini
 
10 tips for adding polish to presentations
10 tips for adding polish to presentations10 tips for adding polish to presentations
10 tips for adding polish to presentationsKeith Bradnam
 
Cracking the coding interview u penn - sept 30 2010
Cracking the coding interview   u penn - sept 30 2010Cracking the coding interview   u penn - sept 30 2010
Cracking the coding interview u penn - sept 30 2010careercup
 
EXPLORA x Pepperclip - Visualization
EXPLORA x Pepperclip - VisualizationEXPLORA x Pepperclip - Visualization
EXPLORA x Pepperclip - VisualizationDorian Dawance
 
Cinci ug-january2011-anti-patterns
Cinci ug-january2011-anti-patternsCinci ug-january2011-anti-patterns
Cinci ug-january2011-anti-patternsSteven Smith
 
It's XP Stupid (2019)
It's XP Stupid (2019)It's XP Stupid (2019)
It's XP Stupid (2019)Mike Harris
 
NUS Hackers Project Intern 2016
NUS Hackers Project Intern 2016NUS Hackers Project Intern 2016
NUS Hackers Project Intern 2016Vishnu Prem
 
The 360 Developer
The 360 DeveloperThe 360 Developer
The 360 Developerenteritos
 
Testing in the Dark: Lessons in Cross-Site Communication (MEWT 2015)
Testing in the Dark: Lessons in Cross-Site Communication (MEWT 2015)Testing in the Dark: Lessons in Cross-Site Communication (MEWT 2015)
Testing in the Dark: Lessons in Cross-Site Communication (MEWT 2015)Neil Studd
 
Designing for Customer needs: A UX Perspective
Designing for Customer needs: A UX PerspectiveDesigning for Customer needs: A UX Perspective
Designing for Customer needs: A UX PerspectiveRichard O'Brien
 

Similar to Crafty communications - Dealing with the pesky people parts of communications (20)

Hidden sides of Code Review (MMM-2023)
Hidden sides of Code Review (MMM-2023)Hidden sides of Code Review (MMM-2023)
Hidden sides of Code Review (MMM-2023)
 
Pragmatic programmer
Pragmatic programmerPragmatic programmer
Pragmatic programmer
 
50.000 orange stickies later
50.000 orange stickies later50.000 orange stickies later
50.000 orange stickies later
 
Hybrid teaching: Hidden skills and knowledge gaps
Hybrid teaching: Hidden skills and knowledge gapsHybrid teaching: Hidden skills and knowledge gaps
Hybrid teaching: Hidden skills and knowledge gaps
 
UPA2007 Designing Interfaces Jenifer Tidwell
UPA2007 Designing Interfaces Jenifer TidwellUPA2007 Designing Interfaces Jenifer Tidwell
UPA2007 Designing Interfaces Jenifer Tidwell
 
UPA2007 Designing Interfaces Jenifer Tidwell
UPA2007 Designing Interfaces Jenifer TidwellUPA2007 Designing Interfaces Jenifer Tidwell
UPA2007 Designing Interfaces Jenifer Tidwell
 
Domain Driven Design - DDDSydney 2011
Domain Driven Design - DDDSydney 2011Domain Driven Design - DDDSydney 2011
Domain Driven Design - DDDSydney 2011
 
Pair Programming Styles
Pair Programming StylesPair Programming Styles
Pair Programming Styles
 
Redesigning everything ITARC Stockholm 2021
Redesigning everything ITARC Stockholm 2021Redesigning everything ITARC Stockholm 2021
Redesigning everything ITARC Stockholm 2021
 
10 tips for adding polish to presentations
10 tips for adding polish to presentations10 tips for adding polish to presentations
10 tips for adding polish to presentations
 
Cracking the coding interview u penn - sept 30 2010
Cracking the coding interview   u penn - sept 30 2010Cracking the coding interview   u penn - sept 30 2010
Cracking the coding interview u penn - sept 30 2010
 
EXPLORA x Pepperclip - Visualization
EXPLORA x Pepperclip - VisualizationEXPLORA x Pepperclip - Visualization
EXPLORA x Pepperclip - Visualization
 
Cinci ug-january2011-anti-patterns
Cinci ug-january2011-anti-patternsCinci ug-january2011-anti-patterns
Cinci ug-january2011-anti-patterns
 
It's XP, Stupid
It's XP, StupidIt's XP, Stupid
It's XP, Stupid
 
It's XP Stupid (2019)
It's XP Stupid (2019)It's XP Stupid (2019)
It's XP Stupid (2019)
 
The sweet spot
The sweet spotThe sweet spot
The sweet spot
 
NUS Hackers Project Intern 2016
NUS Hackers Project Intern 2016NUS Hackers Project Intern 2016
NUS Hackers Project Intern 2016
 
The 360 Developer
The 360 DeveloperThe 360 Developer
The 360 Developer
 
Testing in the Dark: Lessons in Cross-Site Communication (MEWT 2015)
Testing in the Dark: Lessons in Cross-Site Communication (MEWT 2015)Testing in the Dark: Lessons in Cross-Site Communication (MEWT 2015)
Testing in the Dark: Lessons in Cross-Site Communication (MEWT 2015)
 
Designing for Customer needs: A UX Perspective
Designing for Customer needs: A UX PerspectiveDesigning for Customer needs: A UX Perspective
Designing for Customer needs: A UX Perspective
 

Recently uploaded

Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Adtran
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAshyamraj55
 
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyesHow to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyesThousandEyes
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostMatt Ray
 
Things you didn't know you can use in your Salesforce
Things you didn't know you can use in your SalesforceThings you didn't know you can use in your Salesforce
Things you didn't know you can use in your SalesforceMartin Humpolec
 
Introduction to Quantum Computing
Introduction to Quantum ComputingIntroduction to Quantum Computing
Introduction to Quantum ComputingGDSC PJATK
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfinfogdgmi
 
Digital magic. A small project for controlling smart light bulbs.
Digital magic. A small project for controlling smart light bulbs.Digital magic. A small project for controlling smart light bulbs.
Digital magic. A small project for controlling smart light bulbs.francesco barbera
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureEric D. Schabell
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1DianaGray10
 
Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)Commit University
 
RAG Patterns and Vector Search in Generative AI
RAG Patterns and Vector Search in Generative AIRAG Patterns and Vector Search in Generative AI
RAG Patterns and Vector Search in Generative AIUdaiappa Ramachandran
 
Do we need a new standard for visualizing the invisible?
Do we need a new standard for visualizing the invisible?Do we need a new standard for visualizing the invisible?
Do we need a new standard for visualizing the invisible?SANGHEE SHIN
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesMd Hossain Ali
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.YounusS2
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024D Cloud Solutions
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsSeth Reyes
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPathCommunity
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxGDSC PJATK
 
Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024SkyPlanner
 

Recently uploaded (20)

Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
 
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyesHow to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
 
Things you didn't know you can use in your Salesforce
Things you didn't know you can use in your SalesforceThings you didn't know you can use in your Salesforce
Things you didn't know you can use in your Salesforce
 
Introduction to Quantum Computing
Introduction to Quantum ComputingIntroduction to Quantum Computing
Introduction to Quantum Computing
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdf
 
Digital magic. A small project for controlling smart light bulbs.
Digital magic. A small project for controlling smart light bulbs.Digital magic. A small project for controlling smart light bulbs.
Digital magic. A small project for controlling smart light bulbs.
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability Adventure
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1
 
Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)
 
RAG Patterns and Vector Search in Generative AI
RAG Patterns and Vector Search in Generative AIRAG Patterns and Vector Search in Generative AI
RAG Patterns and Vector Search in Generative AI
 
Do we need a new standard for visualizing the invisible?
Do we need a new standard for visualizing the invisible?Do we need a new standard for visualizing the invisible?
Do we need a new standard for visualizing the invisible?
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and Hazards
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation Developers
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptx
 
Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024
 

Crafty communications - Dealing with the pesky people parts of communications

  • 1. Crafty communications DEALING WITH THE PESKY PEOPLE PARTS OF COMMUNICATIONS Asher Glynn
  • 5. The skills to build wonders  Repetition and practice  On the job education  Communicating – working as a team
  • 6. The language of craft  Each craft builds its own language  Each craft has problems communicating with other crafts  Each craft is prone to relabel or abbreviate basic terminology  Or be overly pedantic  Measurements in millimeters only (building)  Or be quite specific to a country  Cups for baking (Australia vs US cup not the same)  Or be dismissed as just using “jargon” when there is something very specific going on
  • 7. The language of craft  Liquor = water (brewing)  Mud = wet mortar (brick laying)  Plumb = lead weight for determining vertical (building)  Cover = customer (restaurants)  Vigorish = house edge (sports betting – US specific)  Ruck and maul = trying to murder the opposing player (Rugby Union)  Datacentre = where servers live (Technology)  User = someone with a heartbeat (Technology)  Code = ??? (Technology)
  • 10. The language of craft  Techniques for building a common language  User stories  Pair programming  Design patterns  Reviewing for intent  Avoidance
  • 11. The language of craft  User stories  For a developer to demonstrate they understand requirements  Less formal than Use Cases  Look easy  Where it works  When developers write them  And users read them  Where it goes horribly wrong  Nobody reading them  A non stakeholder writing them
  • 12. The language of craft  Pair programming  Out of the Extreme Programming toolbox  Where it works  Exploring a new problem domain  Exploring a new code base  Where it goes horribly wrong  Religious wars  Turning a developer into a pure typist
  • 13. The language of craft  Design patterns  Abstractions of common coding patterns  Should emerge from a code base  Libraries give a common language for describing things  Where it works  When someone has read the book(s) and applied it to a code base  A shortcut for explaining what is going on  Where it goes horribly wrong  Using every pattern  Shortcuts turn into long cuts
  • 14. The language of craft  Reviewing for intent  Can you read the code?  Do you understand the intent of the developer?  Can you do that without resorting to comments?  Where it works  Explore the software architecture  Familiarise everyone with code  Where it goes horribly wrong  Code standards zealots  Really really really bad code
  • 15. Reviewing for intent  Example (from Magnolia CMS)  https://git.magnolia- cms.com/projects/MODULES/repos/observation/browse/src/main/java/inf o/magnolia/module/observation/commands/RestrictToTemplateEventListe ner.java  I’m not picking on Magnolia…
  • 16. Reviewing for intent protected String getRelevantPath(String path, Node node) throws RepositoryException { if (template == null) { return path; } // if the passed node has not the template which is observed, also checking parent nodes. // if a parent has that template, command is executed for the path of that parent-node while (node != null && !template.equals(NodeTypes.Renderable.getTemplate(node)) && path.length() > 1) { node = node.getParent(); // no more parents if (node != null) { path = node.getPath(); } } // if after searching we don't find a node of the type we don't execute the event String nodeTemplate = NodeTypes.Renderable.getTemplate(node); if (node == null || !template.equals(nodeTemplate)) { logger.warn("Returning null path as node was null."); return null; } return path; } }
  • 17. Reviewing for intent  Good  Comments  Clear exit points  Consistent with general approach (if you look at other Magnolia code)  Bad  While clause particularly hard work (structure traversal and business logic combined)  Assigns path and node (which disguises intent)  Returns a null - never nice  But…  Idiomatic for the project – other very similar code
  • 18. Reviewing for intent  Repeat – I’m not picking on Magnolia
  • 19. Reviewing for intent  Whose driving?  Senior team members  Benefit of experience  Tend to make things complicated based on experience  Will have very distinct opinions on style  Junior/new team members  Benefit of naivety  Are still trying to understand what the code does  Will have very distinct opinions on style  No context peers  Might drive towards a clear “what am I trying to do” review
  • 20. Reviewing for intent  Opportunity to discuss style/teach language features  Consensus based approach  Team works together to understand code as written  Not a value judgement on correctness  Not a value judgement on quality  Shouldn’t be about syntax  Although can be a great way to teach Functional Programming  May help evolve coding conventions  Or expand understanding
  • 21. Avoidance Don’t do it = Don’t need language to describe it
  • 22. Over engineering  Developers love engineering for re-use  Its more fun developing frameworks than solving business problems  Lines of code still viewed as an indication of productivity
  • 23. Over engineering  Metrics  How many places will you call this code from?  How many times will you call this code (ever)?  How many cases do you need to cater for now?  If the answer is 1 to the above you are probably over engineering…  Fall back to Unix principles – do one thing well
  • 24. Personalities  Communication goes in two directions  Speaking  Listening  Are you:  Using the same language?  Using the same idioms?  Listening?
  • 25. Personalities  Are they:  Listening?  Wanting to interact with you?  Wanting the same outcomes?  Is your self perception clouding things?
  • 27. Princess Programmer Description Self promoter who, from the outside, will prefer to talk than actually get on with it Their perspective Persecuted genius Your perspective Write some code… Everything turns into a competition Ways forward • Give them an opportunity • Call bluff • Play with someone else
  • 29. Desperate Dev Description Component programmer who feels very uncomfortable with business problems causing a huge number of defects to be raised by users. Dislikes verbal communication and confrontation. Constantly “concerned” about issues that can’t be articulated but never go away Their perspective Harassed artist Your perspective Neurotic mess Ways forward • Use instant messenger to chat • Sit them with a user in a “production” environment • Use written lists for concerns
  • 31. Advanced Agile Advocate  Spends most of the time telling you all about Agile (in their view)Description Continuous barrage of commentary about how you don’t understand agile Their perspective It’ll be great just when the upon the coming of the agile Kingdom of Heaven Your perspective I get it – user stories, sprint planning, retrospectives, burn down or kanban boards, lets DO it! Ways forward • Agree the whole process • Write it down • Point back at the written process • Can’t code, go away
  • 33. Cunning Customer Description Attempts to be get more whether that be - More features - More time - Just more Their perspective Highly effective individual contributor – the single reason anything gets done Your perspective Not a team player Ways forward • Win/Win scenarios? • Better understanding? • Mutual respect? • Acceptance of a no win
  • 35. Careless clockwatcher Description Can I go home yet? Their perspective This is a job Your perspective Yes, it’s a job, that involves doing some work Ways forward • ???
  • 37. Security Sadist Description Security is important Very important Which is why they leave their requirements until just before you release Their perspective The last, best chance for humanity Your perspective Get out of the way Ways forward • Stop treating them like they are special • Security requirements are written down – same as every other requirement • Security can be tested at the same time as any other tests
  • 38. Battle-scarred Beardy Description Anecdoates of how it used to be in the olden days Their perspective Look at the size of my beard! Your perspective Punchcards are a bad punchline Ways forward • Age isn’t an indicator of capability • Visual appearance isn’t a great • Be very careful – they might be right…
  • 39. Process Prince Description Always one more piece of documentation to be done before you can release/code/test/do anything Their perspective All about visibility Your perspective Why don’t you have a reflection Ways forward • Processes don’t exist in the ether • Dummy run the process to demonstrate whether it can actually be followed • Follow the process
  • 41. Abstract Architecturists Description Boxes and lines (optional) which apparently describe a system Their perspective Bearer of clarity in a world of chaos Your perspective Eh, what? Ways forward • No diagram can show everything • Audiences for diagrams are important • May have become accustomed to Executive focus • Maybe
  • 43. Technology Enthusiast Description Ohhh shiny Their perspective I just love technology – why won’t you let me play with new toy/gadget/platform Your perspective Confiscate the toys Ways forward • Dig back to a practical example of why you need to use it • Be aware you are being sold something • Engage and don’t immediately dismiss but don’t agree anything
  • 45. Silent Superstars Description Sits in the corner quietly coding and popping out with something amazing Their perspective Please stop talking with me Your perspective Can I have 10 of them – if only they could communicate more effectively Ways forward • Find non verbal ways to communicate • Embargo others from interrupting them • Develop a culture of respect for communication
  • 46. Solution Soothsayer Description Can give you an incredibly detailed description of a solution based on zero facts Their perspective Hero for rescuing you from the vague requirements Your perspective Takes the pressure off stakeholders from articulating what they actually need/want Ways forward • Slow it down • Stop the code • Make it clear that the psychic solution isn’t definitive
  • 48. Ultimately…  Whats in it for you in the communication?  What do you want?  Do you really need to communicate?
  • 49. A bit about me  Consult in a variety of capacities (eg Architecture, Delivery, etc) with a variety of companies  Burrowing Deep Consulting – Just me  Rituala – Delivery  Vigil365 – Operations  interim.team – Senior temporary assignments
  • 50. Refererences  Use Cases – https://en.wikipedia.org/wiki/Ivar_Jacobson  Gang of Four Design Patterns - https://www.amazon.com/Design-Patterns- Elements-Reusable-Object-Oriented-ebook/dp/B000SEIBB8

Editor's Notes

  1. This is Notre Dame de Paris – home to a hunchbank and an amazing example of mediaeval craftsmanship. Construction started in 1163 and was completed in 1345 – nearly 200 years later. Not unlike some projects I’ve been on. While we can admire the sheer skill involved in constructing something on the scale of a cathedral the thing that’s interesting is the common understanding of what was being built over such a vast period.
  2. Similarly we can look at the triumphs of the Faberge company in creating minatures – their eggs were the result of a years work sometimes by individuals but also from a whole workshop contributing. There is something far more going on here than individual virtuosity – this is precise work.
  3. Nobody walks onto a building site with all the skills to do the job without a huge level of investment – its significant and something that is almost impossible to explain to anyone else
  4. So this is my garden from last weekend – you can see the spirit level telling me I had the sleepers dead straight. You can also see the orange line running down to let me line up the sleepers as well. I remember a lot of techniques from when I was doing slave labour with a brickie building an extension. But I’d be useless on a real building site because I don’t know the builders terminology for any of the techniques I was using or what the tools are called. The steel bar – rebar The wood bit – Auger wood drill bit That’s no so different for some developers – some really really good ones who just don’t have the communications tools to work on our metaphorical site
  5. But it turned out OK
  6. Let me come clean here – my ambition for this presentation is incredibly limited – its about maybe one team, or one company but its about some of the techniques I’ve personally found useful. Or not as the case might be
  7. User stories are fantastically flexible especially when you compare them to Use Cases which are quite prescriptive in the interactions – you have an actor, you have a system, its all about the interface and you can’t (shouldn’t) dive into system internals to describe them – if you are doing them properly. User Stories are comparatively a free for all – and should be – its about communication between the developer and the user to achieve a common understanding. If you’ve got a great relationship between a developer and a user – especially one with hands on experience – you need absolutely minimal documentation – a list of points or maybe a knowing grunt – because the communication challenge is already solved. But if you are writing them – vast, lengthy, detailed, weighty use cases – you probably want someone to read them. If you can’t convince another developer to read them, or a user, you are into this category here – you are a non stakeholder. If you aren’t coding, you are adding a layer of interpretation on top of someone else. And if you aren’t the end user, you are interpreting someone else’s message. Let me qualify this – I’m talking about this in the context of craft and communications, not whether business analysts are useful – they are, some I’ve worked with are amazing and single handedly responsible for saving projects from the wilderness but when they write requirements, in whatever form, they bring something different to the table with their ownership of the problem
  8. I’m not going to get into the rituals of Pair Programming – I know for a lot of developers – maybe most of them – development is a solo sport done in the early hours of the morning fueled by caffeine and pizza. I just want to focus on communication part – pair programming is great for developers coming to a common understanding of a problem domain and evolving a language and idioms to deal with that problem domain. This works really well if you don’t work well with tools like diagrams. I admire people who can do pair programming well, a lot of mine ends up with “let me type” especially when its more “pair system administration”
  9. Design patterns have had a bad rap, especially since some of the original Gang of Four patterns turned out to be anti-patterns, but is a great way to communicate at a level above the level of code. If you see a pattern, say singleton, being repeated in the code. As with a lot of techniques it got abused – hands up whose worked on a code base where someone has tried to use every design pattern?
  10. Putting my project lead hat on and say – if it passes the tests and works and is OK, I’m fine with that piece of code. As a developer it drives me nuts I’m just doing “wha”/
  11. I worked with a company in Sydney once which prided itself on being able to turn over work within a day – paper. requests would come in the morning, responses would be out by last mail at night. This meant they never developed a language or systems to handle overnight paperwork, because they didn’t need to. I didn’t really appreciate the level of genius in this – however accidental. It made it a lot easier to train staff, the paperwork itself was a lot simpler and it avoided a lot of complex tracking and workflow. If you watch builders and mechanics there are remarkably similar patterns – anything that is sub a day works well, anything over increases dramatically the chances of going wrong. This presentation is about communication though, not how to do optimise your processes. There’s possibly as much value with some of the techniques we’ve seen over the past 2 days – DDD, no estimates, visualisation techniques - in what they mean we can leave out and not deal with. You don’t have to spend vast amounts of time arguing about what things mean, or training new team members to understand your particular interpretation of a process.
  12. A friend of mine started a club for programmers because he loves to code. Just code. What he actually likes doing is writing complex frameworks for solving problems that make him happy. They aren’t scalable, designed for production use or anything like that. But they are still over engineered. And I was stuck trying to explain to him why they were over engineered. So I
  13. I was sat in an architectural review once for a database migration from a legacy system to a new one. And it was a weird review. The architects from the team doing the work were good – like really good. But we were really stuck It took about 30 minutes for the penny to drop – the job was going to run once. This wasn’t a permanent piece of code, it wasn’t something that needed to run for the next decade. It was going to run once. Once. It needed to be tested. Just tested. From an engineering perspective if it worked once and got chucked that was fine. Hit delete, move on. That’s a dramatic example but you see lots of code which exhibit very similar properties. Take a method – how many callers does it actually have? If its more than one and provides a contract to an external system, go for it, engineer away. But if nobody else is going to call it.
  14. Not everyone is the same person all the time – if you self identify with any of the following slides, please do NOT be offended its just about trying to see how we work together. Communication goes both directions and you need willing participation on both parties.
  15. I’ve written unappreciated genius there – what I meant to say was possibly the greatest neglected contribution to computer science if only Google
  16. I think we’ve all had projects where there is a constant worrier. Some of the worries are completely valid, but often can just end up being self reinforcing – meta concerns – concerns about concerns. The thing keeping them up at night is the thing keeping them up at night. Had one developer who had “lots of concerns”. We wrote them down, turns out there were 3. Of which one when it was written down he suddenly wasn’t really worried about any more! Don’t engage until the concerns are written down.
  17. Its 9.30am. The caffeine hasn’t kicked in yet. Your eyes are only just open. And the agile zealot is giving you a lecture (again) on how to run the scrum. Or how user stories work. Or grooming a backlog. Or something, lets face it you’ve tuned it out a few weeks ago. I don’t get religious about many things but let me get religion hard for this – Agile is about users and developers and being really biased its about us. Developers. And development is about writing code. So lets get on with it
  18. I’d like to pretend there’s a clever way around this one, but sometimes you need to know when to give up. A cunning customer who sees the engagement as a zero sum game – they “win” and you “lose” isn’t something you can ever actually make work. You can beat yourself up about it – I have – but if there are only 2 options and one of them is inconceivable for them, the exercise is damage mitigation not
  19. I’d like to say everyone is passionate about something in their work, and its just a matter of finding that persons calling or helping them realise their full potential but frankly. No.
  20. Lets get this straight – security is super important. Security is absolutely fundamental to writing useful, quality software and is at the absolute foundation of good design. It’s so important that what you don’t do is leave it to the last minute and beat someone around the head with new requirements. There’s a game that some people play with security – to use it as a blocker. “Ohhh, security won’t be happy about that”. It’s another no win game – no matter what you do, you’ll get the security sadist telling you that there is something wrong.
  21. Annoyingly the fundamentals of computer science haven’t actually changed since the 1960’s – and a lot of the underlying concepts of the Internet haven’t changed at all. There’s lots that has changed which is makes the beardy particularly
  22. Full title is probably The Process Prince of Darkness and I’m not entirely convinced they have reflections. Or souls. I was working with a team which was doing “agile” – so no tests, no backlog, no estimates, no burndown – you know agile. Their development manager was a Prince2 Process Prince and wanted tickets for everything. We got a junior to fill in the tickets the seniors didn’t want to and suddenly everything was fine. That only worked because the process was written down, well understood and the barriers and bars are well known. Been in other scenarios where there is a Process Prince with no written process. Can anyone spot the problem there.
  23. I’ll put my hand up for this one – I’ve been there, I’ve got the lines and boxes diagrams to prove it. And architecture is such a loaded term – what is it, software, systems, integration, what???
  24. So whether its Hadoop or Kafka or Disruptor or Docker or whatever it happens to be your local technology enthusiast will want to be using it
  25. Sometimes you do need a Soothsayer