Way back in the before times, if you wanted a copy of a book or manuscript, you needed to make that copy yourself with pen and ink by copying the text line by line. A term used to describe this is Copywork.

Copywork was also used by great authors of the past to learn more deeply about the great authors that came before them. It allowed them to feel like a master writer for a short while, make observations and connections, and ask questions about why great writers used specific words and structures.

Copying the code, line for line, of other engineers can accelerate your learning. It has been one of my goto tactics any time I endeavored to learn a new programming language.

How Copywork Helps Coders

In my opinion, one of the most significant benefits of using copywork when learning a coding language is that it gives you a break from repetition and the rote memorization process, which frees your mind to zoom out and analyze more deeply as a whole.

Copying the code of several different and more experienced engineers will expose you to other approaches to a similar problem. Some engineers have an individual style, and you can see it in their code. The more copies you make of work by different coders, the greater the scaffolding that gets created in your mind; it helps create a mental lattice for new things to stick.

This process can also reveal the varying strategies and tactics used by others. Some patterns will be evident to you, and others won’t—make a note of what you see for further investigation later. Some of what you are learning with copywork will make its way into your work someday; a combination of different styles will converge to become part of your style.

One significant side benefit of this kind of practice is that it helps relieve some of the overwhelm that accompanies learning to code in a new language. Immersing yourself in multiple compositions of code creates familiarity.

How Copywork Helps Coders

1. Find Some Authors

Start with some Google and GitHub searches for well-known and more experienced coders for your language of choice.

Examples of code authors for TypeScript:

• Anders Hejlsberg: https://github.com/ahejlsberg. This repo is a bit dated, but it’s by a lead architect and core developer of TypeScript, so tons of value here.
• James Hickey: https://github.com/jamesmh. Author of Refactoring TypeScript: Keeping Your Code Healthy.
• Boris Cherny: https://github.com/bcherny. Author of Programming TypeScript: Making Your JavaScript Applications Scale.

2. Pick a Composition of Code

When picking a composition or page of code, don’t worry too much about where it fits within the rest of an application.

The code you copy could be part of an abstraction and challenging to understand its role within the broader scheme. And that’s ok; again, our goal is to copy and zoom out, to analyze a piece from a higher vantage point.

As an example, I might choose one of the following:

• https://github.com/bcherny/undux/blob/master/src/emitter.ts
• https://github.com/bcherny/undux/blob/master/src/plugins/withReduxDevtools.ts

3. Copy and Observe

Now that you have a composition of code to copy, sit back, and start copying the piece at a steady pace and consider the following as you progress:

• In what areas of the composition did you slow down or speed up while copying? Take note of locations where you slowed down a bit, as this may indicate topics for further research. You slowed down for a reason; maybe your brain wanted a bit more time to comprehend what you were copying.
• Does what you are copying feel easily readable, or does it feel crowded or cluttered? Pay attention to how blocks of code are structured, think about the kinds of formatting decisions the coder might have made.
• Based on what you have learned so far in your coding journey, what might you have done differently from this particular composition? You might see something done differently than the way you learned to do it yourself, and that’s ok. It might be worth researching later—maybe the differences matter.
• When done, compare the copywork to others you have done in the past; what patterns seemed common and which seemed different? These differences might be coding style or preference. As you do more copywork, note the parts that resonate with you as these may contribute to your style and coding principles for that language as you improve.

Conclusion

Copying others’ work with the intent of observing a composition in its entirety is a tool I think all aspiring coders should be using. This practice has been a learning accelerator for me.

You might be thinking, “I’m already copying code all day long from books and tutorials!”. While this may be true, you may likely be doing it focusing on one particular area, as part of learning variables, scope, functions, etc. Remember that for copywork, the goal is to zoom out of the granular learning and focus on the code in its entirety.

Give it a try!

Follow me on Twitter - It's the best way to learn about any new content I publish.