Successfully reported this slideshow.

When Code Cries

2

Share

Upcoming SlideShare
Listening skills (1)
Listening skills (1)
Loading in …3
×
1 of 64
1 of 64

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

When Code Cries

  1. 1. When Code Cries Cory Foy @cory_foy cory@8thlight.com www.8thlight.com, www.coryfoy.com
  2. 2. Bad Code
  3. 3. Is this quality code?
  4. 4. Is this quality code?
  5. 5. Is this quality code? “Code that actually gets used”
  6. 6. Is this quality code? “Code that actually gets used” “Lots of merged in pull requests”
  7. 7. Is this quality code? “Code that actually gets used” “Lots of merged in pull requests” “Quality code makes me say, "hmm," not "ick."”
  8. 8. Is this quality code? “Code that actually gets used” “Lots of merged in pull requests” “Quality code makes me say, "hmm," not "ick."” “If, when used, it pleases the user”
  9. 9. “The specific patterns out of which a building or a town is made may be alive or dead. To the extent they are alive, they let our inner forces loose, and set us free; but when they are dead, they keep us locked in inner conflict.” Christopher Alexander - “The Timeless Way of Building”
  10. 10. Code Smells
  11. 11. Code Talks
  12. 12. Code Cries
  13. 13. Code Cries Because No One Understands What It Is Saying
  14. 14. So?
  15. 15. So?
  16. 16. So?
  17. 17. http://www.flickr.com/photos/bunchofpants/99848415
  18. 18. “...we have so far beset ourselves with rules, and concepts, and ideas of what must be done to make a building or a town alive, that we have become afraid of what will happen naturally, and convinced that we must work within a “system” and with “methods” since without them our surroundings will come tumbling down in chaos.” Christopher Alexander - “The Timeless Way of Building”
  19. 19. Ten Thousand Hours
  20. 20. Functional Programming Imperative Programming Logic Programming Static Typing Dynamic Typing
  21. 21. Coding Standards Define Dialects
  22. 22. BICS CALP
  23. 23. BICS Basic Interpersonal Communication Skills CALP
  24. 24. BICS Basic Interpersonal Communication Skills CALP Cognitive/Academic Language Proficiency
  25. 25. BICS Basic Interpersonal Communication Skills CALP Cognitive/Academic Language Proficiency
  26. 26. BICS Basic Interpersonal Communication Skills Context Context Embedded Reduced CALP Cognitive/Academic Language Proficiency
  27. 27. Cognitively Undemanding BICS Basic Interpersonal Communication Skills Context Context Embedded Reduced CALP Cognitive/Academic Language Proficiency Cognitively Demanding
  28. 28. Cognitively Undemanding BICS - Copying from the board - Reading a Map - Face to Face Conversation - Selecting food in the lunchroom Context Context Embedded Reduced CALP Cognitively Demanding
  29. 29. Cognitively Undemanding BICS - Copying from the board - Reading a Map - Following a class schedule - Face to Face Conversation - Telephone Conversation - Selecting food in the - Oral Presentations lunchroom - Getting an absence excuse Context Context Embedded Reduced CALP Cognitively Demanding
  30. 30. Cognitively Undemanding BICS - Copying from the board - Reading a Map - Following a class schedule - Face to Face Conversation - Telephone Conversation - Selecting food in the - Oral Presentations lunchroom - Getting an absence excuse Context Context Embedded Reduced - Demonstrations - Basic Math Computations - Science Experiements CALP Cognitively Demanding
  31. 31. Cognitively Undemanding BICS - Copying from the board - Reading a Map - Following a class schedule - Face to Face Conversation - Telephone Conversation - Selecting food in the - Oral Presentations lunchroom - Getting an absence excuse Context Context Embedded Reduced - Demonstrations - Standardized Tests - Basic Math - Math Concepts and Computations Applications - Science Experiements - Listening to a Lecture CALP Cognitively Demanding
  32. 32. Cognitively Undemanding BICS Context Context Embedded Reduced CALP Cognitively Demanding
  33. 33. Foy-Z Cognitively Undemanding BICS Context Context Embedded Reduced CALP Cognitively Demanding
  34. 34. Foy-Z Cognitively Undemanding BICS Katas Context Context Embedded Reduced CALP Cognitively Demanding
  35. 35. Foy-Z Cognitively Undemanding BICS Katas Koans Context Context Embedded Reduced CALP Cognitively Demanding
  36. 36. Foy-Z Cognitively Undemanding BICS Katas Koans Context Context Embedded Reduced Adding a new Feature CALP Cognitively Demanding
  37. 37. Foy-Z Cognitively Undemanding BICS Katas Koans Context Context Embedded Reduced Adding a new Listening to Code Feature CALP Cognitively Demanding
  38. 38. Listening to Code http://www.flickr.com/photos/jn2race/263149573
  39. 39. Listening to Code Decide to listen http://www.flickr.com/photos/jn2race/263149573
  40. 40. Listening to Code Decide to listen Listen for the whole message http://www.flickr.com/photos/jn2race/263149573
  41. 41. Listening to Code Decide to listen Listen for the whole message Let go of your own personal agenda http://www.flickr.com/photos/jn2race/263149573
  42. 42. Listening to Code Decide to listen Listen for the whole message Let go of your own personal Be patient agenda http://www.flickr.com/photos/jn2race/263149573
  43. 43. Listening to Code Decide to listen Listen for the whole message Let go of your own personal Be patient agenda Be curious http://www.flickr.com/photos/jn2race/263149573
  44. 44. Listening to Code Decide to listen Listen for the whole message Let go of your own personal Be patient agenda Be curious Test for understanding http://www.flickr.com/photos/jn2race/263149573
  45. 45. 4 Rules of Simple Design Does this code express all of the ideas we want to express? Are there concepts from our domain that can be expressed?
  46. 46. Commonality/Variability Analysis What is common? What varies? Is it easy to swap the things that vary? Is it easy to identify the things that are common?
  47. 47. Fowler’s Perspectives (from UML Distilled) Are we operating at the right level - Conceptual, Specification or Implementation?
  48. 48. SOLID Principles Do we have duplication (implementation or conceptual)? Single responsibilities? LoD violations? LSP violations?
  49. 49. To Listen, We Must Understand
  50. 50. To Listen, We Must Understand To Understand, We Must Practice
  51. 51. To Listen, We Must Understand To Understand, We Must Practice To Practice, We Must Have Context
  52. 52. To Listen, We Must Understand To Understand, We Must Practice To Practice, We Must Have Context
  53. 53. To Listen, We Must Understand To Understand, We Must Practice To Practice, We Must Have Context
  54. 54. Cory Foy (@cory_foy) cory@8thlight.com www.8thlight.com www.coryfoy.com 8th Light Software is our craft TM

Editor's Notes

  • Thanks to SCNA for having me back out again. I had the chance to speak at the 2009 conference, and it’s great to have watched the conference - and the movement of craftsmanship - continue to grow. But yet, even with all of the work done in craftsmanship, there’s something we still have to deal with.\n
  • Bad Code is the bane of the software industry. And we have a lot of it! But why do we end up with bad code? Why is it that, over time, code becomes harder and harder to work with - and how can we prevent ours from ending up with the same fate? To answer that, perhaps we should start with identifying what quality code looks like and see if we can have our code match that. So, is this quality code?\n
  • Is this quality code? (No Code). But yet, each of you have in your mind attributes you were ready for the code to not have. And I’d bet, each of you has something different than your neighbor. That’s because quality isn’t some static attribute of the code itself it’s not a checklist. Instead, quality happens at the interaction point of the code base - either when it is attempted to be understood, modified, or used. This can be seen in the responses I got from Twitter. Four highlighted phrases show that the code is alive\n
  • Is this quality code? (No Code). But yet, each of you have in your mind attributes you were ready for the code to not have. And I’d bet, each of you has something different than your neighbor. That’s because quality isn’t some static attribute of the code itself it’s not a checklist. Instead, quality happens at the interaction point of the code base - either when it is attempted to be understood, modified, or used. This can be seen in the responses I got from Twitter. Four highlighted phrases show that the code is alive\n
  • Is this quality code? (No Code). But yet, each of you have in your mind attributes you were ready for the code to not have. And I’d bet, each of you has something different than your neighbor. That’s because quality isn’t some static attribute of the code itself it’s not a checklist. Instead, quality happens at the interaction point of the code base - either when it is attempted to be understood, modified, or used. This can be seen in the responses I got from Twitter. Four highlighted phrases show that the code is alive\n
  • Is this quality code? (No Code). But yet, each of you have in your mind attributes you were ready for the code to not have. And I’d bet, each of you has something different than your neighbor. That’s because quality isn’t some static attribute of the code itself it’s not a checklist. Instead, quality happens at the interaction point of the code base - either when it is attempted to be understood, modified, or used. This can be seen in the responses I got from Twitter. Four highlighted phrases show that the code is alive\n
  • Is this quality code? (No Code). But yet, each of you have in your mind attributes you were ready for the code to not have. And I’d bet, each of you has something different than your neighbor. That’s because quality isn’t some static attribute of the code itself it’s not a checklist. Instead, quality happens at the interaction point of the code base - either when it is attempted to be understood, modified, or used. This can be seen in the responses I got from Twitter. Four highlighted phrases show that the code is alive\n
  • Think about this. Have you ever worked with code that is a joy to work with? How freeing it is? And that feeling - I want us to capture that, and have that feeling more often! Because too often, the feeling we get is code that looks more like this <click>\n
  • 45 seconds. 7 Samples. Code that isn’t a joy. That is anti-joy. Code which is frustrating to be around. This is not code that is alive - this is code which has problems. And these problems - we tend to name them something. When we see something not right in code, what do we say?\n
  • 45 seconds. 7 Samples. Code that isn’t a joy. That is anti-joy. Code which is frustrating to be around. This is not code that is alive - this is code which has problems. And these problems - we tend to name them something. When we see something not right in code, what do we say?\n
  • 45 seconds. 7 Samples. Code that isn’t a joy. That is anti-joy. Code which is frustrating to be around. This is not code that is alive - this is code which has problems. And these problems - we tend to name them something. When we see something not right in code, what do we say?\n
  • 45 seconds. 7 Samples. Code that isn’t a joy. That is anti-joy. Code which is frustrating to be around. This is not code that is alive - this is code which has problems. And these problems - we tend to name them something. When we see something not right in code, what do we say?\n
  • 45 seconds. 7 Samples. Code that isn’t a joy. That is anti-joy. Code which is frustrating to be around. This is not code that is alive - this is code which has problems. And these problems - we tend to name them something. When we see something not right in code, what do we say?\n
  • 45 seconds. 7 Samples. Code that isn’t a joy. That is anti-joy. Code which is frustrating to be around. This is not code that is alive - this is code which has problems. And these problems - we tend to name them something. When we see something not right in code, what do we say?\n
  • 45 seconds. 7 Samples. Code that isn’t a joy. That is anti-joy. Code which is frustrating to be around. This is not code that is alive - this is code which has problems. And these problems - we tend to name them something. When we see something not right in code, what do we say?\n
  • Right - “Smelly Code”. But what I’d like to do today is reframe the discussion slightly. Instead of telling our code that it smells, let’s recognize something else - our code is trying to talk to us.\n
  • And imagine trying to talk to someone about something important - say, the building is on fire - and them not understanding your strange gestures and telling you you are smelly. Would that make you happy? Probably not - no more than it makes our code happy. In fact, it makes our code sad - so sad, that our code \n
  • And our code cries not because it is smelly, but because no one understands what it is trying to say. It’s trying to point out what it wants to do, what is important, and how to use it. And it isn’t happy about that!\n
  • Aren’t we bigger than the code? Aren’t we smarter? Are we going to let it push us around?\n
  • Aren’t we bigger than the code? Aren’t we smarter? Are we going to let it push us around?\n
  • And though we’d like to think that we can overcome the code, overcome the forces that shape it through design and architecture, we are really fighting a losing battle. \n
  • We create a design. We settle down, build a house, have a family. But the code doesn't want that. It has plans beyond our design. And if we don't listen to those plans, our days will become filled with holding off the impending - and inevitable - change (http://www.adammandelman.net/tag/harold-fisk/)\n
  • For example, in 2011, the Mississippi River tried to change course, I believe to the Orange area. And it normally would have - except for the millions of dollars the Army Corp of Engineers spent to erect dams, flood farm fields and otherwise keep it on the course best for us - not for it. We like it when things are tidy, and go according to plan. So much so that Christopher Alexander has this to say\n
  • The more we fight against the forces the code is trying to resolve, the work we have to do scales exponentially as the call of the forces increases. In fact, the entire movement behind patterns isn’t to catalog recipes, but to explain and understand forces that can be at play in our code. So what we need to do is find a way to listen to our code, understand our code, so that we can pay attention to the forces at play and allow our systems to grow incrementally in a way that is healthy. Learning Next\n
  • To do that, we need to go back a bit, and look at how we, as an industry, tell people to learn code. There’s a common figure that is given to developers about what it takes to become great in software. Does anyone know that number? <Click> This is the number of hours to “master” a skill. And it’s the wrong place to start for a couple of reasons. The first is because I have this\n
  • To do that, we need to go back a bit, and look at how we, as an industry, tell people to learn code. There’s a common figure that is given to developers about what it takes to become great in software. Does anyone know that number? <Click> This is the number of hours to “master” a skill. And it’s the wrong place to start for a couple of reasons. The first is because I have this\n
  • To do that, we need to go back a bit, and look at how we, as an industry, tell people to learn code. There’s a common figure that is given to developers about what it takes to become great in software. Does anyone know that number? <Click> This is the number of hours to “master” a skill. And it’s the wrong place to start for a couple of reasons. The first is because I have this\n
  • (Beaker story). But the second is that programming is an act of communication, precisely why they are called programming languages. And if we think about how we classify and learn natural languages, we get some pretty interesting results\n
  • (Beaker story). But the second is that programming is an act of communication, precisely why they are called programming languages. And if we think about how we classify and learn natural languages, we get some pretty interesting results\n
  • (Beaker story). But the second is that programming is an act of communication, precisely why they are called programming languages. And if we think about how we classify and learn natural languages, we get some pretty interesting results\n
  • (Beaker story). But the second is that programming is an act of communication, precisely why they are called programming languages. And if we think about how we classify and learn natural languages, we get some pretty interesting results\n
  • The first is how different languages - and paradigms - can affect our viewpoints. Linguist Roman Jakobson points out “Languages differ essentially in what they must convey and not in what they may convey”. For example, if I said, in English, I had dinner with a neighbor last night, I wouldn’t have to reveal if it was a male or female. But if I said the same thing in French or German, I would be obliged to (voisin vs voisine and Nachbar vs Nachbarin). So they same can be said for programming languages. Functional must express problems in the context of reduction of terms. Imperative expresses problems as a statement of the process, and logic expresses problems as a statement of the result. Static typing forces us to abstractions sooner, while dynamic typing allows the abstraction to be held off\n
  • But it also gives you access to words that aren’t expressed in your native language.\nEven when we are in the same language, we may not understand the code because it’s not how we would write it\n
  • But it also gives you access to words that aren’t expressed in your native language.\nEven when we are in the same language, we may not understand the code because it’s not how we would write it\n
  • But it also gives you access to words that aren’t expressed in your native language.\nEven when we are in the same language, we may not understand the code because it’s not how we would write it\n
  • But it also gives you access to words that aren’t expressed in your native language.\nEven when we are in the same language, we may not understand the code because it’s not how we would write it\n
  • \n
  • If we look at this model, we can now do something similar with programming. We can create a somewhat standardized model for increasing the success of developers from team to team, project to project and language to language\n
  • If we look at this model, we can now do something similar with programming. We can create a somewhat standardized model for increasing the success of developers from team to team, project to project and language to language\n
  • If we look at this model, we can now do something similar with programming. We can create a somewhat standardized model for increasing the success of developers from team to team, project to project and language to language\n
  • If we look at this model, we can now do something similar with programming. We can create a somewhat standardized model for increasing the success of developers from team to team, project to project and language to language\n
  • If we look at this model, we can now do something similar with programming. We can create a somewhat standardized model for increasing the success of developers from team to team, project to project and language to language\n
  • If we look at this model, we can now do something similar with programming. We can create a somewhat standardized model for increasing the success of developers from team to team, project to project and language to language\n
  • If we look at this model, we can now do something similar with programming. We can create a somewhat standardized model for increasing the success of developers from team to team, project to project and language to language\n
  • If we look at this model, we can now do something similar with programming. We can create a somewhat standardized model for increasing the success of developers from team to team, project to project and language to language\n
  • If we look at this model, we can now do something similar with programming. We can create a somewhat standardized model for increasing the success of developers from team to team, project to project and language to language\n
  • If we look at this model, we can now do something similar with programming. We can create a somewhat standardized model for increasing the success of developers from team to team, project to project and language to language\n
  • If we look at this model, we can now do something similar with programming. We can create a somewhat standardized model for increasing the success of developers from team to team, project to project and language to language\n
  • If we look at this model, we can now do something similar with programming. We can create a somewhat standardized model for increasing the success of developers from team to team, project to project and language to language\n
  • If we look at this model, we can now do something similar with programming. We can create a somewhat standardized model for increasing the success of developers from team to team, project to project and language to language\n
  • If we look at this model, we can now do something similar with programming. We can create a somewhat standardized model for increasing the success of developers from team to team, project to project and language to language\n
  • This model, which I’m calling the “Foy-Z” model, since my name isn’t Jay, looks like this. We need to start by providing context. We can provide context through the use of Katas\n
  • This model, which I’m calling the “Foy-Z” model, since my name isn’t Jay, looks like this. We need to start by providing context. We can provide context through the use of Katas\n
  • This model, which I’m calling the “Foy-Z” model, since my name isn’t Jay, looks like this. We need to start by providing context. We can provide context through the use of Katas\n
  • This model, which I’m calling the “Foy-Z” model, since my name isn’t Jay, looks like this. We need to start by providing context. We can provide context through the use of Katas\n
  • This model, which I’m calling the “Foy-Z” model, since my name isn’t Jay, looks like this. We need to start by providing context. We can provide context through the use of Katas\n
  • This model, which I’m calling the “Foy-Z” model, since my name isn’t Jay, looks like this. We need to start by providing context. We can provide context through the use of Katas\n
  • This model, which I’m calling the “Foy-Z” model, since my name isn’t Jay, looks like this. We need to start by providing context. We can provide context through the use of Katas\n
  • This model, which I’m calling the “Foy-Z” model, since my name isn’t Jay, looks like this. We need to start by providing context. We can provide context through the use of Katas\n
  • And Test for Understanding is where we get to ask questions back of the code base. Such as\n
  • And Test for Understanding is where we get to ask questions back of the code base. Such as\n
  • And Test for Understanding is where we get to ask questions back of the code base. Such as\n
  • And Test for Understanding is where we get to ask questions back of the code base. Such as\n
  • And Test for Understanding is where we get to ask questions back of the code base. Such as\n
  • And Test for Understanding is where we get to ask questions back of the code base. Such as\n
  • Patterns. 4 Rules of Simple Design. Question Every Line of Code. CVA. Conceptual/Specification/Implementation\n
  • Patterns. 4 Rules of Simple Design. Question Every Line of Code. CVA. Conceptual/Specification/Implementation\n
  • Patterns. 4 Rules of Simple Design. Question Every Line of Code. CVA. Conceptual/Specification/Implementation\n
  • Transition to summary - to listen, we must understand\n
  • Let’s work towards finding ways to establish baselines into the way we work for our teams, and growing our abilities to work with cognitive demanding tasks in limited context - keeping in mind the principles, patterns, and forces at play. And if we don’t, the code is going to do what it wants to do while we flail wildly against uttering the most sacred of phrases in the software world - WTF?\n
  • Let’s work towards finding ways to establish baselines into the way we work for our teams, and growing our abilities to work with cognitive demanding tasks in limited context - keeping in mind the principles, patterns, and forces at play. And if we don’t, the code is going to do what it wants to do while we flail wildly against uttering the most sacred of phrases in the software world - WTF?\n
  • Let’s work towards finding ways to establish baselines into the way we work for our teams, and growing our abilities to work with cognitive demanding tasks in limited context - keeping in mind the principles, patterns, and forces at play. And if we don’t, the code is going to do what it wants to do while we flail wildly against uttering the most sacred of phrases in the software world - WTF?\n
  • Let’s work towards finding ways to establish baselines into the way we work for our teams, and growing our abilities to work with cognitive demanding tasks in limited context - keeping in mind the principles, patterns, and forces at play. And if we don’t, the code is going to do what it wants to do while we flail wildly against uttering the most sacred of phrases in the software world - WTF?\n
  • Let’s work towards finding ways to establish baselines into the way we work for our teams, and growing our abilities to work with cognitive demanding tasks in limited context - keeping in mind the principles, patterns, and forces at play. And if we don’t, the code is going to do what it wants to do while we flail wildly against uttering the most sacred of phrases in the software world - WTF?\n
  • Let’s work towards finding ways to establish baselines into the way we work for our teams, and growing our abilities to work with cognitive demanding tasks in limited context - keeping in mind the principles, patterns, and forces at play. And if we don’t, the code is going to do what it wants to do while we flail wildly against uttering the most sacred of phrases in the software world - WTF?\n
  • Let’s work towards finding ways to establish baselines into the way we work for our teams, and growing our abilities to work with cognitive demanding tasks in limited context - keeping in mind the principles, patterns, and forces at play. And if we don’t, the code is going to do what it wants to do while we flail wildly against uttering the most sacred of phrases in the software world - WTF?\n
  • Let’s work towards finding ways to establish baselines into the way we work for our teams, and growing our abilities to work with cognitive demanding tasks in limited context - keeping in mind the principles, patterns, and forces at play. And if we don’t, the code is going to do what it wants to do while we flail wildly against uttering the most sacred of phrases in the software world - WTF?\n
  • \n
  • ×