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


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.


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

In non-technical terminologies, here are a few examples:


When playing Golf, going to the driving range is a training sandbox, while playing on the fairway is the actual play.

  • Reduction - There is a reduction in the complexity of the practice in that you simply focus on your learning your golf swing and calibrating to your irons.

  • Control - You have the option to choose which of your irons and woods to practice, and what your goal is, like pitching or putting.

  • Bounded - You can limit your practice by number of hours, or number of minutes you spend on your 7-irons vs. your pitching wedge.

  • Goal-oriented - You can set a goal for yourself to consistently practice having a flat head when hitting the ball, or consistently keeping your hands straight as you swing.

  • Evaluated - You can get immediate feedback from this sandbox by evaluating whether the ball went to the right place, and whether you can consistently get the results you want. Alternatively, you can get a coach or a mentor to give you feedback by observing your swing.


When playing Basketball, practicing free throws or playing neighborhood matches can be a form of a training sandbox, while playing in competitions or championships is the actual play.

  • Reduction - There is a reduction in the complexity of the practice in that you don't practice dribbling and focus on shooting.

  • Control - To lower the stakes of a competition or a championship, neighborhood basketball pickup matches are reduced in stakes. In free throw training, you can also practice shooting at the free throw line, or various places near the hoop.

  • Bounded - In your free throw practice, you can set a fixed amount of time to practice.

  • Goal-oriented - You can set a goal of 50 successful free throw shots per training session.

  • Evaluated - You can clearly see whether the ball went in the hoop, and whether you can consistently shoot the ball whenever you wanted to. Alternatively, you can get a coach or a mentor to give you feedback by observing your shooting form.

The above examples provides an idea of the required characteristics of an effective training sandbox, such that it becomes a conducive place for the individual to learn.

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


  • 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.

Last updated