Sometimes you just need to leap into sharing your learning, even when you haven’t yet learned much. “Beginner’s mind” usually becomes more abstract as a person advances, making it difficult for beginners to learn from experts. If you can dare to write while you’re learning, you may find unique opportunities to create content that appeals first and foremost to learners.
Despite that, the “learn from the master” story remains powerful: of course, only those who know best should be trusted to teach! Sometimes that comes with the old guild-flavored model: masters should select worthy apprentices and mentor them for a long while.
The apprenticeship model has its benefits, but I’ve spent most of my career promoting what I generally call the DIY model. Even in the thriving field of programming, we don’t have enough masters willing to spend their time with apprentices. Masters seem better at talking with masters than with newcomers, and even the journeywomen and journeymen sometimes forget the difficulties of the paths they’ve followed to get there. The DIY model drops that lost formality and replaces it with books, videos, and occasional classes, combined with a lot of self-study.
Getting the DIY story right is incredibly difficult. Unless you’re lucky enough to be teaching in person, which has its own challenges, you have to anticipate what a reader or viewer will need. The feedback loop runs mostly through reviews, both during and after the creation of the piece. Getting ahead of that feedback loop means doing something scary: write about what you don’t know.
I’ve written most of my books for a DIY audience, in most cases writing them as I did it myself. Dynamic HTML was a concept in very beta software when I first started writing, and XML was emerging. More recently I’ve written in fields where the other books were targeted at an already knowledgeable audience – Rails, Erlang, and Elixir. At least, they were written for a more knowledgeable audience than me.
Why on earth would I write about subjects where I wasn’t a master? My usual answer is simple: no one else has written what I need. It may exist, but it’s scattered. I can work my way slowly through material meant for experts, and re-tell their stories for myself and for a broader audience. The result, if I get it right, is more than just me learning: it’s widening the door for a lot of other people.
I’m obviously biased, but I see a lot of advantages to this model. Most important, I can choose what to emphasize by the level of pain it’s caused me. Difficult installations may be dull, but they’re critically important to newcomers. Experts may be fine working from lists of available parts, but beginners need to know what the parts are for. Telling stories that show the parts working together – and stories where they fail – help newcomers figure out how the path really looks, not just how it looks to experienced professionals.
One of the best things about starting from zero is that you know what you don’t know. The hard part, of course, is that it’s everything. You need to find sources you trust, whether references or people. You need to make sure you understand the vocabulary and have at least enough experience to be able to determine how the parts fit together. Perhaps most critically, you need to find reviewers, early on, who can tell you when you’ve taken the wrong path, and develop a thick enough skin to work well with them.
Also, you’re probably not starting from complete zero. Every programming environment, for example, is different, and there are many new ways to go wrong. Their common structure, though, makes it possible to create at least the beginning of an outline. Sure, it’ll change as you become more familiar with the language, but that happens pretty much any time someone starts writing.
This approach fits badly with traditional publishing approaches. Putting together a traditional book proposal with a bio that includes “I know nothing about this” doesn’t work well. I’ve only been able to make it work because my publishers had worked with me before, and could evaluate what I was doing. While I think this is a great approach for readers, it’s a difficult place to be for prospective authors. (It’s a headache for me as I apply the same model in a very different field, too.)
Want to try this? You will learn about your subject, about the writing process, about yourself, and hopefully about your readers. You can:
- Find a subject you want to explore deeply.
- Make sure there’s enough description, even bad description, already available for you to get traction.
- Find a storyline that hasn’t been done, that you want to see, a path you want to follow. (Typically this is a gentle introduction, written for the completely unfamiliar.)
- Study. It might be reading books, it might be watching videos, and it really must be creating things with the tools you’re exploring. Keep notes, whether formally in a notebook or in Post-its scattered across the books you read.
- Write an initial description of what you want to do, written for the audience you want to enjoy it.
- Create the simplest thing someone can actually do with the tools you’re covering, and describe it so that the audience you have in mind can follow it.
- Share that creation as early as you can stand.
- Gather feedback. It’s terrifying, but I reliably find that I stick to projects where I get more feedback, even if it isn’t happy feedback. Get feedback from experts, and get feedback from ‘sample readers’.
- Check that your sequence works. One of the biggest problems with books written by masters is that they forget the order in which they learned. Beginners can get into similar trouble as they juggle parts. Mandatory forward references, or even a lot of optional ones, are a bad sign.
- Iterate, grow, iterate, grow… Making changes to existing content usually makes it easier to build momentum for creating new content.
- At some point, declare you’re done, for now.
This won’t always work. Sometimes you’ll find yourself losing interest, and abandon the project. Projects can be too ambitious, too difficult or too expensive. Other times you’ll find that someone else has done what you dreamed of, sparing you the need to do an awful lot of work. If that happens, celebrate. If you need to stop, try to make sure your creation is available somewhere – there’s very little in computing (or elsewhere) that couldn’t use better documentation.
The point of this kind of project isn’t to “become an author” or “make a lot of money”. The odds in both cases are pretty low. You can, however, learn a lot, and make a lot of other people happy along the way.