Hi, I’m Duncan Smith. I live with my wife and our two kids near Seattle, WA, USA. I joined a software consulting company after college, and my first project was in the Seattle area. After a few years with no fixed address (hooray for the consulting life), I decided to move here permanently. Since then, I have worked in software development at various companies, mainly in the Windows/.NET world. I’m currently working at a large software company which I shall not mention here, but you know where to look if you’re curious. :-)
In 2015, I started this blog about deliberate practice techniques for software developers.
Some software developers use a process called test-driven development (TDD), in which they write automated unit tests at the same time as they write their product code. One way to remember how the TDD process works is “red-green-refactor.” Here’s what each piece of that hyphenated term means:
- Red: the developer writes a unit test which is intended to exercise a missing feature, or reproduce a bug. Since the feature hasn’t been written, or the bug hasn’t been fixed, the test should fail. Test runners generally indicate this with a red icon or status message.
- Green: the developer implements the feature or fixes the bug and runs the test again. The test runner should display a green icon or message. Yay!
- Refactor: although the code now works, it probably isn’t as elegant as it could be. Refactoring means “improving the design of existing code.” By running the automated unit tests, the developer verifies that the refactoring process didn’t break anything.
Can something like red-green-refactor be applied to developers’ brains as well as to the code that they’re writing? In learning theory, active recall is a way to find out what you know, and also to consolidate information in your memory. The active recall process requires a prompt or question and an answer provided by the learner. Consider a developer learning a new programming language. One way to do this is to implement small programs based on a prompt an an expected result. For example, the prompt could be “Calculate the first 100 prime numbers” and the expected result could be the first 100 prime numbers, one per line. Rather than test-driven development, we now have learning-driven development (LDD). The analogous term to red-green-refactor is red-green-code:
- Red: to verify the developer’s knowledge of a concept, an automated test can be run against their code. A red result means the result of the programmer’s code doesn’t match the expected result. This is common early in the learning process.
- Green: when the developer can successfully write code to generate the expected result, the test passes.
- Code: after a green result, the developer has a bit more coding knowledge, which he or she can use in future coding projects.
The active recall approach is especially suited to learning programming, since computers are good at comparing actual and expected results. I’ll be writing more about how to apply this approach. Stay tuned.