Sandboxes

Author	Start date	Implementation issue
Darren Karl Sapalo	June 7, 2023	June 7, 2023

​

Summary

The Sandboxes protocol defines sandboxes (the places or activities to train) in the context of technologists, engineers, designers, product owners, and startups.

​

Motivation

We wrote this protocol to create a conducive environment with clear, efficient communication and alignment between mentors and apprentices (“Community Members”). We achieve this by having a shared definition of sandboxes in the context of software engineering, providing parameters that can be tweaked to achieve healthy and sustainable training. In a mentorship or apprenticeship engagement, this will reduce the likelihood of misunderstandings, mismatched expectations, and unnecessary disappointment. By reading this protocol, you will be able to assess your learning environments (sandboxes) and communicate with peers, and navigate your training phases.

​

Definition

Training sandboxes are a reduction of the actual context, whether by space, scope, or difficulty. It is the place for training. The primary characteristics of a sandbox are the following:

• Reduction - The sandbox must be reduced by space, scope, stakes, or difficulty.
• Control - The individual practicing in the sandbox has control over the training.
  • Reduction - The individual should have the ability to tweak the sandbox to their preferred difficulty setting.
  • Pace - The individual should be able to start, pause, and stop the whole training based on their evaluation of themselves.
• Bounded - The practice must be bounded, such as limited in time of practice, or limited in time of scores. Having the practice bounded helps set boundaries on how much energy, effort, or time will be spent in the practice (e.g. 3 sessions).
• Goal-oriented - The practice must have a goal set to be pursued, whether as a rough estimate or as a hard requirement, depending on the capabilities of the individual.
• Evaluated - Sandboxes will not be effective if there is no reliable or sufficiently objective feedback mechanism for the learner. Otherwise, the learner will not be able to comprehend what they’re doing wrong.

​

Non-software engineering sandboxes

Training sandboxes can be found in many non-technical contexts that demonstrate the core principles in action.

​

Software engineering sandboxes

In software engineering, you have a variety of sandboxes to iterate and practice different skills.

​

Daily Stand Up reports

Skills to practice: Communication, preparation, accuracy, truthfulness, conciseness, specificity, clarity.

​

Sprint Planning

Skills to practice: Estimation, unraveling complexity, accuracy, truthfulness, specificity, collaboration, correctness

​

Code reviews through Merge Requests (MRs) or Pull Requests (PRs)

Skills to practice: Communication, articulation, correctness, clarity

​

Brown-bag sessions with colleagues

Skills to practice: Asking questions, absorbing concepts, curiosity, attention and focus

​

1-on-1 mentoring sessions

Skills to practice: Clarity, planning, discovering one’s goals, commitment, accountability, estimation, health and sustainability

​

General Reading and Writing

Skills to practice: Communication, accuracy, truthfulness, conciseness, specificity, clarity

​

Benefits

• Simple definitions of non-sequential stages of training.
• Common terminology to understand each other when it comes to training.
• Emotionally-validating perspective when it comes to learning and growth.

​

Examples

The following examples show how there are different kinds of ‘sandboxes’ in different games, sports, or domains.