The document discusses various ways that video games can teach skills through techniques like repetition, exploration, immersion, feedback, and hints. It provides examples of games like Settlers of Catan that teach through repetition, Minecraft that encourages exploration, GTA that enables immersion, and Portal that gives feedback. The document also shares resources for teaching kids programming and contact information for the author.
The document provides instructions for connecting with others on LinkedIn in 5 steps: open LinkedIn, select "My Network", select the "Add" button, choose "Find Nearby", and then turn on location services and connect with contacts or message existing connections.
The document appears to be a slide presentation about test driven development (TDD). It includes slides about daily schedules, types of knowledge related to TDD skills, combining different TDD skills, writing test scenarios, the differences between BDD and an "evil programmer" approach, testing functional code, faking code to pass tests first before implementing, resources for learning more about TDD including a blog and video, and thanks and contact information. The presentation provides an overview of key concepts and best practices for TDD.
The document discusses different data formats for representing a book including XML, JSON, YAML, simple/CSV/tabbed text formats, and a C++ operator overload format. It also provides resources for approval testing and mob programming.
This document discusses the return on investment (ROI) of dedicating time each day to learning and self-improvement. It notes that small gains over time, such as dedicating just one hour per day or improving skills by 1% each month, can lead to exponential growth when compounded over months and years. Various learning techniques and formats are presented such as mob programming, pair programming, and workshops. The importance of cultivating a learning culture at work is emphasized.
The document discusses various ways that video games can teach skills through techniques like repetition, exploration, immersion, feedback, and hints. It provides examples of games like Settlers of Catan that teach through repetition, Minecraft that encourages exploration, GTA that enables immersion, and Portal that gives feedback. The document also shares resources for teaching kids programming and contact information for the author.
The document provides instructions for connecting with others on LinkedIn in 5 steps: open LinkedIn, select "My Network", select the "Add" button, choose "Find Nearby", and then turn on location services and connect with contacts or message existing connections.
The document appears to be a slide presentation about test driven development (TDD). It includes slides about daily schedules, types of knowledge related to TDD skills, combining different TDD skills, writing test scenarios, the differences between BDD and an "evil programmer" approach, testing functional code, faking code to pass tests first before implementing, resources for learning more about TDD including a blog and video, and thanks and contact information. The presentation provides an overview of key concepts and best practices for TDD.
The document discusses different data formats for representing a book including XML, JSON, YAML, simple/CSV/tabbed text formats, and a C++ operator overload format. It also provides resources for approval testing and mob programming.
This document discusses the return on investment (ROI) of dedicating time each day to learning and self-improvement. It notes that small gains over time, such as dedicating just one hour per day or improving skills by 1% each month, can lead to exponential growth when compounded over months and years. Various learning techniques and formats are presented such as mob programming, pair programming, and workshops. The importance of cultivating a learning culture at work is emphasized.
This document discusses mob programming, where all team members work together on the same task at the same time. Key aspects include having a designated driver who writes code while others navigate and collaborate. Benefits highlighted are bringing together diverse perspectives and skills to solve problems faster and with higher quality. Mob programming encourages learning, idea sharing, and focusing on work quality over individual credit. It works best when team size allows everyone to actively contribute.
The document discusses how mob programming can be applied to testing to amplify its impact. Mob testing involves having testers, programmers, and test automators work together simultaneously on testing. It provides several benefits like automated testing, exploratory testing, feedback, understanding, and serendipity. The document provides examples of applying mob testing to exploratory testing, automated testing, and production code. It emphasizes benefits like shared learning, insights, handling problems, and producing the best quality work through collaboration.
Sparrow Decks apply Machine Learning techniques to your own brain. It's AI for I.
Here we will train your subconscious to recognize:
House vs Song sparrows
Cluttered vs Relevant code
Long vs Short lines
Long vs Short methods
Good vs Bad names
Duplication vs distinct code
Inconsistency vs Duplication
This document summarizes a presentation on strong-style pairing by Llewellyn Falco and Maaret Pyhäjärvi. It introduces the concepts of strong-style pairing versus traditional pairing. Examples are provided of exercises done in strong-style pairing, including navigating, language demos, and coding FizzBuzz. Benefits of strong-style pairing include rapid learning, increased productivity over time, and addressing traditional problems with pairing like disengagement or slowing people down. Homework is assigned to initiate pairing with a new person.
This document discusses collaborative exploratory and unit testing. It introduces mob programming where testers work together in real-time. Exploratory testing focuses on exploring a product to uncover unexpected issues while unit testing verifies specific functionality. The document provides an overview of exploratory testing skills and frameworks as well as challenges of testing like non-deterministic behaviors. It emphasizes the power of collaboration between testers with different skills and perspectives.
This document discusses ways to increase testability through code seams. It recommends separating code into functional and non-functional pieces, and extracting the functional pieces. This allows the functional code to be tested in isolation without external dependencies. Specific techniques mentioned include peeling away non-functional layers and slicing functional logic from surrounding code. Examples show how to make code more deterministic and remove reliance on global state, dates, and other uncontrollable variables to improve testability.
The document discusses different types of unit testing including approval testing, combinatorial testing, theory testing, executable query testing, testing routes, custom patterns, multithreaded testing, and testing event wiring. Theory testing involves generating test cases, testing a theory against each case, and recording any failures. Executable query testing verifies that queries pass, increases complexity, provides feedback on failures, and compares original and current results.
The document provides instructions for an activity that requires some skill but is easy to learn. It mentions that one may need to try several times to be successful, but complications are minimal once successful. The activity works best with lots of room and can be peaceful without complications, though rain can interfere and having too many people doing the same thing nearby can also cause problems. A rock is recommended as an anchor, but there is no second chance if things break loose from it.
The document discusses patterns for more powerful asserts when doing approval testing. It outlines 7 approaches to asserting values in approval tests, moving from simple number and string assertions to more complex objects, files, automatically generated names, custom verification methods, and using diff tools to compare outputs on failure. The goal is to make approval testing more expressive and tests less cluttered while still using normal test scenarios.
This document contains code samples in multiple programming languages that implement the "99 Bottles of Beer" song. Code examples are provided in Haskell, Ruby, Java, SmallBasic, and other languages. Each implementation shows a different approach to modeling the song and counting down bottles of beer in a concise yet readable way.
This document discusses strategies for games and strategies. It touches on several topics:
- The importance of games for immersion, fun, and practice for life
- Different strategies like just-in-time rules versus big upfront rules
- The idea that it is in playing the game that we discover what game we must play
- Common strategies like stating the obvious, using your advantages, and changing the game
- The concept of a dominant strategy and examples like the Prisoner's Dilemma
This document discusses getting existing code under tests and the benefits of unit testing. It provides examples of code and questions to test understanding of unit testing and functional vs non-functional testing. Functional tests are described as easier since they isolate code and ensure consistent outputs for given inputs, while non-functional tests involving things like concurrency are more difficult to test.
The document outlines the process for Lean Coffee, which involves setting up topics using a ToDo, In Progress, Done framework. Participants then collect and introduce topics in one sentence before dot voting to prioritize what to discuss. Discussions are time boxed and voted on whether to continue discussing the topic or move to the next. This process repeats, creating headings, gathering ideas, introducing topics, prioritizing by vote, discussing, and determining when finished.
The document provides instructions for an activity. It states that a seashore is a better location than a street. The activity requires some skill but is easy to learn, and even children can enjoy it. While complications are minimal when successful, factors like too many participants, rain, or equipment breaking loose can cause problems. Proper space and using a rock as an anchor are advised.
This document discusses strategies for throwing better exceptions in code. It presents examples of poorly thrown exceptions and demonstrates how to improve them by including more context and details. The key rules discussed are to use variable values, wrap bad exceptions, provide context, show runtime details, include tl;dr examples, add extra information, and highlight root causes when throwing exceptions. This aims to give confused coders more guidance in debugging and understanding where errors are occurring.
The document outlines the roles and responsibilities of various participants in a coding exercise. It describes 6 roles: the Announcer who reads observations out loud, the Collector who gathers observations, the Keeper who manages rotation of roles, the Navigator who guides the Driver, the Driver who types code, and the Un-sticker who asks questions to nudge the Navigator. Each role has specific tasks to contribute to a collaborative problem solving process.
Teaching kids programming with the Intentional MethodLlewellyn Falco
This document describes Teaching Kids Programming (TKP), a free and modular programming courseware for teaching programming concepts to kids ages 10 and up. TKP has been tested on over 2,000 kids and takes an agile approach, emphasizing quick setup, collaborative and iterative learning, and rapid feedback. The course is organized into units that each focus on an experience area like "Recipe", "Recap", or "Quiz". These experiences guide students through activities like executing their first program within minutes, exploring mistakes to discover patterns, and taking quizzes where 100% of pairs get 100% right. The goal is for students to experience the joy of programming through experimentation and variations on ideas. Teachers are encouraged to try
Some Helpful Observations for successful Mob ProgrammingLlewellyn Falco
The document provides several observations for successful mob programming:
- Always be actively contributing to the mob in any way possible, such as navigation, proofreading, asking questions, or offering suggestions.
- Respect each other's strengths and weaknesses as individuals and as the group works together to learn.
- Respect the existing code while still looking to improve it, without insulting previous work and thoughtfully navigating changes.
This document discusses mob programming, where all team members work together on the same task at the same time. Key aspects include having a designated driver who writes code while others navigate and collaborate. Benefits highlighted are bringing together diverse perspectives and skills to solve problems faster and with higher quality. Mob programming encourages learning, idea sharing, and focusing on work quality over individual credit. It works best when team size allows everyone to actively contribute.
The document discusses how mob programming can be applied to testing to amplify its impact. Mob testing involves having testers, programmers, and test automators work together simultaneously on testing. It provides several benefits like automated testing, exploratory testing, feedback, understanding, and serendipity. The document provides examples of applying mob testing to exploratory testing, automated testing, and production code. It emphasizes benefits like shared learning, insights, handling problems, and producing the best quality work through collaboration.
Sparrow Decks apply Machine Learning techniques to your own brain. It's AI for I.
Here we will train your subconscious to recognize:
House vs Song sparrows
Cluttered vs Relevant code
Long vs Short lines
Long vs Short methods
Good vs Bad names
Duplication vs distinct code
Inconsistency vs Duplication
This document summarizes a presentation on strong-style pairing by Llewellyn Falco and Maaret Pyhäjärvi. It introduces the concepts of strong-style pairing versus traditional pairing. Examples are provided of exercises done in strong-style pairing, including navigating, language demos, and coding FizzBuzz. Benefits of strong-style pairing include rapid learning, increased productivity over time, and addressing traditional problems with pairing like disengagement or slowing people down. Homework is assigned to initiate pairing with a new person.
This document discusses collaborative exploratory and unit testing. It introduces mob programming where testers work together in real-time. Exploratory testing focuses on exploring a product to uncover unexpected issues while unit testing verifies specific functionality. The document provides an overview of exploratory testing skills and frameworks as well as challenges of testing like non-deterministic behaviors. It emphasizes the power of collaboration between testers with different skills and perspectives.
This document discusses ways to increase testability through code seams. It recommends separating code into functional and non-functional pieces, and extracting the functional pieces. This allows the functional code to be tested in isolation without external dependencies. Specific techniques mentioned include peeling away non-functional layers and slicing functional logic from surrounding code. Examples show how to make code more deterministic and remove reliance on global state, dates, and other uncontrollable variables to improve testability.
The document discusses different types of unit testing including approval testing, combinatorial testing, theory testing, executable query testing, testing routes, custom patterns, multithreaded testing, and testing event wiring. Theory testing involves generating test cases, testing a theory against each case, and recording any failures. Executable query testing verifies that queries pass, increases complexity, provides feedback on failures, and compares original and current results.
The document provides instructions for an activity that requires some skill but is easy to learn. It mentions that one may need to try several times to be successful, but complications are minimal once successful. The activity works best with lots of room and can be peaceful without complications, though rain can interfere and having too many people doing the same thing nearby can also cause problems. A rock is recommended as an anchor, but there is no second chance if things break loose from it.
The document discusses patterns for more powerful asserts when doing approval testing. It outlines 7 approaches to asserting values in approval tests, moving from simple number and string assertions to more complex objects, files, automatically generated names, custom verification methods, and using diff tools to compare outputs on failure. The goal is to make approval testing more expressive and tests less cluttered while still using normal test scenarios.
This document contains code samples in multiple programming languages that implement the "99 Bottles of Beer" song. Code examples are provided in Haskell, Ruby, Java, SmallBasic, and other languages. Each implementation shows a different approach to modeling the song and counting down bottles of beer in a concise yet readable way.
This document discusses strategies for games and strategies. It touches on several topics:
- The importance of games for immersion, fun, and practice for life
- Different strategies like just-in-time rules versus big upfront rules
- The idea that it is in playing the game that we discover what game we must play
- Common strategies like stating the obvious, using your advantages, and changing the game
- The concept of a dominant strategy and examples like the Prisoner's Dilemma
This document discusses getting existing code under tests and the benefits of unit testing. It provides examples of code and questions to test understanding of unit testing and functional vs non-functional testing. Functional tests are described as easier since they isolate code and ensure consistent outputs for given inputs, while non-functional tests involving things like concurrency are more difficult to test.
The document outlines the process for Lean Coffee, which involves setting up topics using a ToDo, In Progress, Done framework. Participants then collect and introduce topics in one sentence before dot voting to prioritize what to discuss. Discussions are time boxed and voted on whether to continue discussing the topic or move to the next. This process repeats, creating headings, gathering ideas, introducing topics, prioritizing by vote, discussing, and determining when finished.
The document provides instructions for an activity. It states that a seashore is a better location than a street. The activity requires some skill but is easy to learn, and even children can enjoy it. While complications are minimal when successful, factors like too many participants, rain, or equipment breaking loose can cause problems. Proper space and using a rock as an anchor are advised.
This document discusses strategies for throwing better exceptions in code. It presents examples of poorly thrown exceptions and demonstrates how to improve them by including more context and details. The key rules discussed are to use variable values, wrap bad exceptions, provide context, show runtime details, include tl;dr examples, add extra information, and highlight root causes when throwing exceptions. This aims to give confused coders more guidance in debugging and understanding where errors are occurring.
The document outlines the roles and responsibilities of various participants in a coding exercise. It describes 6 roles: the Announcer who reads observations out loud, the Collector who gathers observations, the Keeper who manages rotation of roles, the Navigator who guides the Driver, the Driver who types code, and the Un-sticker who asks questions to nudge the Navigator. Each role has specific tasks to contribute to a collaborative problem solving process.
Teaching kids programming with the Intentional MethodLlewellyn Falco
This document describes Teaching Kids Programming (TKP), a free and modular programming courseware for teaching programming concepts to kids ages 10 and up. TKP has been tested on over 2,000 kids and takes an agile approach, emphasizing quick setup, collaborative and iterative learning, and rapid feedback. The course is organized into units that each focus on an experience area like "Recipe", "Recap", or "Quiz". These experiences guide students through activities like executing their first program within minutes, exploring mistakes to discover patterns, and taking quizzes where 100% of pairs get 100% right. The goal is for students to experience the joy of programming through experimentation and variations on ideas. Teachers are encouraged to try
Some Helpful Observations for successful Mob ProgrammingLlewellyn Falco
The document provides several observations for successful mob programming:
- Always be actively contributing to the mob in any way possible, such as navigation, proofreading, asking questions, or offering suggestions.
- Respect each other's strengths and weaknesses as individuals and as the group works together to learn.
- Respect the existing code while still looking to improve it, without insulting previous work and thoughtfully navigating changes.
44. 7) YOU CAN CANCEL THE SAME CARD ON TOP OF A DIVED LINE
45. 8) A CARD NEXT TO A 1 REDUCES TO JUST THE CARD
46. 9) YOU CAN PLACE A CARD UNDER A CARD GROUP (BUT MUST DO FOR ALL GROUPS)
47. 1) SOLVE WHAT’S IN THE BOX BY GETTING IT ALONE
2) YOU CAN REMOVE THE NOTHING SPIRALS
3) A CARD COMBINED WITH ITS OPPOSITE BECOMES A NOTHING CARD
4) SIMPLIFY THE OTHER SIDE
5) YOU CAN ADD A CARD (BUT MUST ADD TO BOTH SIDES)
6) YOU CAN ADD OPPOSITE CARDS
7) YOU CAN CANCEL THE SAME CARD ON TOP OF A DIVED LINE
8) A CARD NEXT TO A 1 REDUCES TO JUST THE CARD
9) YOU CAN PLACE A CARD UNDER A CARD GROUP (BUT MUST DO FOR ALL GROUPS)
10) YOU CAN PLACE A CARD INTO A GROUP (BUT MUST DO IT FOR ALL GROUPS)
48. 1) SOLVE WHAT’S IN THE BOX BY GETTING IT ALONE
2) YOU CAN REMOVE THE NOTHING SPIRALS
3) A CARD COMBINED WITH ITS OPPOSITE BECOMES A NOTHING CARD
4) SIMPLIFY THE OTHER SIDE
5) YOU CAN ADD A CARD (BUT MUST ADD TO BOTH SIDES)
6) YOU CAN ADD OPPOSITE CARDS
7) YOU CAN CANCEL THE SAME CARD ON TOP OF A DIVED LINE
8) A CARD NEXT TO A 1 REDUCES TO JUST THE CARD
9) YOU CAN PLACE A CARD UNDER A CARD GROUP (BUT MUST DO FOR ALL GROUPS)
10) YOU CAN PLACE A CARD INTO A GROUP (BUT MUST DO IT FOR ALL GROUPS)
49. 1) SOLVE X BY GETTING IT ALONE
2) YOU CAN REMOVE ZERO’S
3) A VALUE COMBINED WITH IT’S NEGATIVE BECOMES ZERO
4) SIMPLIFY THE OTHER SIDE
5) YOU CAN ADD A VALUE(BUT MUST ADD TO BOTH SIDES)
6) YOU CAN ADD NEGATIVE VALUES
7) YOU CAN CANCEL THE SAME VALUE ON TOP OF A DIVED LINE
8) A VALUE TIMES 1 REDUCES TO JUST THE VALUE
9) YOU CAN DIVE BOTH SIDES BY ANY VALUE
10) YOU CAN MULTIPLY BOTH SIDES BY ANY VALUE
50. 1) SOLVE X BY GETTING IT ALONE
2) YOU CAN REMOVE ZERO’S
3) A VALUE COMBINED WITH IT’S NEGATIVE BECOMES ZERO
4) SIMPLIFY THE OTHER SIDE
5) YOU CAN ADD A VALUE(BUT MUST ADD TO BOTH SIDES)
6) YOU CAN ADD NEGATIVE VALUES
7) YOU CAN CANCEL THE SAME VALUE ON TOP OF A DIVED LINE
8) A VALUE TIMES 1 REDUCES TO JUST THE VALUE
9) YOU CAN DIVE BOTH SIDES BY ANY VALUE
10) YOU CAN MULTIPLY BOTH SIDES BY ANY VALUE