Dave Nicolette
Download a PDF of this article.
On July 19, 2019, Jessica Rose posted a very thoughtful message on Twitter:
The reponses illustrate several challenges faced by self-learners of software development. They also provide a rich source of information for people who teach software development, prepare training materials, create training videos and screencasts, and develop tutorials.
It seems the latter group tend to make certain assumptions about why people are interested in learning this type of work, how they approach it, and what they find frustrating or challenging about it. It would be useful to listen to the self-learners and adapt the training approaches and materials to meet their needs. People who sign up for guided learning, such as training classes and boot camps, experience the same frustrations, too.
Some of the responses reveal assumptions on the part of the learners themselves that may create additional challenges for them. Those who create training materials and who teach software development can learn from this, as well. We can be sure and clarify common misconceptions, rather than carrying on with our old assumptions about why people want to learn these skills.
When I grouped the responses thematically, the following general issues emerged:
- Jargon: Insider jargon is impenetrable; I don’t know how to ask a question, or understand the answer
- Assumptions: Tutorials and documentation assume I already know certain things, but I don’t know them
- Level of detail: I want to skip over topics I already know, and dive into topics I don’t already know
- Industry: So many things are happening in the software world, I can’t determine which skills will be marketable
- Interest: Tutorials use examples that don’t interest me
- Multiple skills: I can’t get my software to work without learning a bunch of other things, like web servers, databases, and operating systems
- Context: Tutorials and documentation aren’t clear about how the examples fit into the bigger picture
- Time: It’s hard to find time to study and practice
- Ideas: I can’t think of anything to work on that would be useful for learning
- Fear of Sharing and Asking: I’m hesitant to share my work or ask questions because I might appear foolish
- Self-discipline: I keep getting distracted by “shiny objects,” and I can’t seem to finish anything I start
- Self-monitoring: How can I keep track of my progress and stay motivated?
- Real World: I can’t find “real world” examples; tutorials are based on trivial cases
Jargon
Based on the very small sample of responses to this single tweet, and the very unscientific analysis of the responses by categorizing and counting them, the biggest challenge for self-learners of software development appears to be terminology or jargon. Many concepts in software development and computer science have precise meanings, and specific terms have been coined to describe them. When people with no previous background in the field dive into a programming tutorial, they encounter a lot of unfamiliar terms.
Yes, you read that right: Foo and bar are confusing. Why? Because people who are completely new to the subject have no frame of reference to recognize which terms are “real” technical jargon and which ones are just placeholders. Even foo and bar must be explained.
Every field has its own jargon. I doubt that can be avoided. It would be challenging enough for a self-learner to get used to the jargon, but on top of that we also tend to “overload” words, such that the same term has different meanings depending on context.
We even overload the word, “overload.” A normal person would think “overload” means “to put too much weight on something,” like putting 1100 kg of material on a forklift rated for 800 kg. To a software developer, “overload” means giving a function or method the same name as another function or method. We’ve incorporated this into our everyday speech, so we’ll talk about other things being “overloaded,” too.
When a learner asks what we mean by that, we may be at a loss to think of anything to say except, “You know, like polymorphism.” That answer isn’t helpful to the learner. They may not be familiar with the terms “polymorphism,” “function,” or “method.” And, of course, they still don’t know what “overload” means.
Now imagine trying to learn a new subject when everything you read or hear is expressed in jargon terms whose meanings are neither obvious nor stable, and when someone tries to help you they can’t think of a way to explain it clearly or simply.
Out of Date Materials
There’s a lot of information available online. Once it’s online, it never goes away. Yet, the software industry is constantly changing. So, most of the tutorials, examples, and documentation you can find in an online search are out of date.
Those who develop training materials can’t completely solve this problem, but we can at least be very clear about which versions of things our tutorials refer to. We can also add a statement to the effect that software products and languages are continually evolving, and the reader should try to find information about the latest version of the software they want to learn about.
Assumptions and Level of Detail
A lot of material intended for self-guided learning makes assumptions about what the learner already knows. People have expressed frustration about this. Some have said they would like to skip over topics they already know, and to have the opportunity to learn more about certain other topics. But most training material and documentation is not organized in a way that allows for this.
People who create material for self-guided learning can help. We can provide links to explanatory material about each concept or jargon term we use in our material, at the first point when the concept or term is used. We can also include links to allow people to skip over sections of our material that they already know, and to skip back again after they discover they were mistaken to think they already knew it.
Industry, Interest, and Multiple Skills
Some respondents mentioned they had difficulty choosing what to focus on, as the software industry is so broad and is changing so rapidly. What sort of “coding” should they learn, to maximize their chances of getting a job? Also, some people find it challenging to relate to tutorials based on a domain that doesn’t interest them.
This sort of question is understandable, if a person has no background at all in computer-related work, and is primarily interested in learning a marketable skill to get a better job. But this isn’t a problem with training materials or documentation. It’s a fundamental misunderstanding of what the work is really about.
What we do isn’t “coding.” There is no job called “Coder.” What we do is software development. The work can be seen as something like engineering, something like art, something like applied science, and something like problem-solving. “Coding,” or typing in program source statements on a keyboard, isn’t really the point. Yes, it’s something we do, but it isn’t the point.
People want to know how they can qualify for an entry-level programming job as quickly as possible. That’s understandable. But to gain the basic skills necessary to achieve that goal, they need to learn more than just “coding.” There are no short-cuts.
Others have a specific idea of something they would like to write; maybe a mobile app or web app. They become frustrated when they discover there’s no quick-and-easy way to do that. They have to learn a range of different skills. There are no short-cuts. Did I say that already? It bears repeating.
Aside from the “technical” fundamentals, of which there are many, successful software developers also have knowledge and skills in one or more business domains, interpersonal skills, organizational or management skills, and more. The “rabbit holes” are the fundamental skills. You can’t skip them.
Some respondents were disappointed that they couldn’t find tutorials and examples that aligned with their personal interests. The thing is, you can’t learn just a few quick things to enable yourself to write the thing that interests you; you have to learn fundamentals, and then use your creativity to apply the fundamentals to whatever interests you. The tutorials and examples you use to learn the fundamentals don’t have to align with your interests. They just have to provide you with a way to learn the fundamentals. What you do with that knowledge is up to you.
The approach to prepare for a job in this field is to learn the fundamentals of software development and support without worrying about which language or “stack” will get you a job. Choose a language that’s straightfoward to learn. If you enjoy math, a language like Scheme or Racket would be a good choice. If you think logically, but not necessarily mathematically, a language like Ruby or Python would be a good choice.
You’ll be able to apply what you learn to other languages easily, after that. If you start with a language that has a lot of “baggage” or requires a lot of “scaffolding” in order to work, you’ll bog down and become frustrated.
Some languages that are highly marketable aren’t necessarily good choices for a beginner to start with. Java, C++, and JavaScript all come to mind here. You have to “know” some things before you can get much traction with those languages. You must learn some fundamentals before you dive into “real” work. Start with a language that’s easier to work with, and take one step at a time.
This stuff isn’t easy. That’s not a deficiency in tutorials or documentation; it’s the nature of the beast.
You might become interested in programming because you want to write a mobile app or web app because those are things that everyone sees all the time, but once you get into it you’ll discover there are many more opportunities beyond those. You don’t know what kind of job you’ll get initially. You don’t know what kinds of software development will ulimately interest you. Everything in the universe isn’t written in JavaScript to run in a web browser. Learn the fundamentals, and you’ll be prepared to take your career in any direction.
Context
Materials for self-guided learning often don’t provide the learner with sufficient context. It may be context about the industry as a whole, or the context of a specific example within the larger tutorial at hand, or context with respect to which examples are “real” and which are contrived to illustrate a point, and might not be used in a “real” application.
I have to say this problem isn’t limited to beginners. Often when I find an example to help myself learn something new, the example doesn’t give me any hints about when, how, or where to apply it. It’s just a couple of lines of code with no context. If that confuses me, with 42 years experience, I imagine it might confuse someone who is just starting out.
To those who write tutorials: Don’t assume the audience for the tutorial is a copy of yourself. Explain the context of everything, even if it seems obvious to you.
Time
Anyone who has the usual responsibilities of an adult will find it challenging to make time to learn the skills to begin a new career. Many people who are interested in learning software development are blue-collar workers, and many of them work more than one job. They may have families to care for, which means both financial support and meaningful family time.
There’s no easy answer to this issue. The best advice I can offer is to plan time for practicing and studying. If you can manage to allocate one hour per evening, three or four evenings a week, that’s better than nothing. The trick is to schedule that time and stick to the schedule. Make your studying a “thing to do” just like other things you have to do. If you wait until you have “spare time,” it won’t happen. You’re too busy already.
Something will have to “give.” Maybe you have to set a hobby aside for a few months so you can use the time to learn new skills. Later you can reactivate the hobby. Maybe you have to stay up an extra hour at night, even though you’re already tired at the end of a long work day. You’re trying to make a major life change, and it’s going to be hard.
You might think there’s nothing the creators of self-guided learning materials can do about this issue, but I think there is. We can carefully modularize our training materials and break the information down into short sections. That way, people can consume the self-guided learning modules at their own pace, and reach small milestones quickly so they feeling as if they’re making progress.
Ideas
You want to practice programming, but you can’t think of anything to work on.
If you want to practice software development but you can’t think of anything to work on, you can get some ideas from a coding “challenge” site like Code Wars. Code Wars presents various small programming challenges at different levels of difficulty. You can see the solutions that other people have written, and learn how they approached the problems and how they thought about designing a solution. All this can be very valuable for a learner (at any level).
For another source of ideas for small practice projects, look at sites that describe so-called “code katas.” Katas are small programming challenges intended to help us practice specific programming techniques. Start with the Code Kata site. You can find many more with a Google search.
If you’re looking for something a little more “real world,” consider contributing to an Open Source project. As a beginner, you might think you aren’t qualified for that. But here’s a little context for you: Almost no Open Source projects have much in the way of (a) documentation or (b) executable test cases.
Most of the experienced developers on those projects are fully occupied with bug fixes and new features. They don’t have time to catch up on the documentation or tests. That means you, even as a beginner, have an opportunity to read and study some “real world” code, and gain an understanding of how it’s designed and why it’s designed that way. Writing documentation and/or test cases is a great way to learn a code base, and to learn principles and techniques you can apply in your own work…or that you can mindfully avoid in your own work, as the case may be.
You can’t do any harm, because Open Source projects use a mechanism called “pull requests” to ensure random people can’t throw code into the project helter-skelter. You notify the project’s owners that you’ve made a change you’d like them to consider adding to the product. They review it and give you feedback. That’s a learning cycle for you.
There are so many thousands and thousands of Open Source projects out there that you can find at least one that has a friendly bunch of developers who will be happy to help you learn…but not all of them. Try not to become discouraged if you have to try a few projects before you find a friendly team to work with.
Fear of Sharing and Asking
Some respondents mentioned a fear of looking foolish. They are hesitant to ask for help or to show anyone their work.
Tens of millions of people work in the software field. You’ll find every type of person in the software field that you find in the general population. Some people are not interested in helping others learn, and some of them even go so far as to make fun of others. If the first one or two people you ask for help treat you that way, you’ll be tempted to forget the whole idea. But there are also a lot of people in the field who will be happy to help you. Keep looking. You’ll find them.
When it comes to looking dumb…get used to it. No matter how much experience you gain in this field, you will frequently experience moments when you feel stupid. We’re constantly making mistakes and learning. It’s part of the job.
Self-Discipline
When you’re working on your own in your spare time and you have neither a teacher nor fellow students around you, it can be hard to stay focused.
It may be helpful to make a list of the things you intend to study and learn over the coming week or month. When you find yourself attracted to a “shiny object,” refer to the list to remind yourself of what you should be spending time on. You can always add the shiny object to your list…but after you get through the material you planned to learn.
The point about practicing is important. You can spend a lot of time repeating code katas and so forth, and still not really internalize the underlying principles. Those principles are what will carry you forward in your career, as you learn more languages and frameworks and apply your skills in more business domains.
It isn’t just the amount of practice that matters, it’s mindful practice. That’s true of any skill that requires practice, such as music or martial arts.
Self-Monitoring
Working alone, how can you tell if you’re doing okay? How do you stay motivated?
It can be very challenging to find sources of encouragement or positive feedback for your efforts when you’re working entirely alone. It’s also hard to tell whether you’re making good enough progress. It’s important to connect with others who are also learning, and if possible more-experienced people who can advise or mentor you.
For those who create materials for self-guided learning: Organize the material in such a way that the learner can always see where they are along a path toward a particular learning goal. It’s useful to create relatively independent modules, but if topics or concepts are presented in isolation it can feel as if there’s no direction, but just a random jumble of stuff. Decompose the material into small pieces so that the learner achieves milestones frequently. Just achieving a milestone will provide a measure of positive reinforcement. People also respond well to small rewards, like “badges,” that provide evidence of progress. That seems to be true even if the rewards are nothing more than an image file that represents the milestone they’ve achieved.
Where’s the Real World?
People new to software development can’t always tell whether the tutorial or example they’re studying represents anything they will see in the “real world” when they get a job in the field. Sometimes they can tell quite easily that the tutorial is based on a trivial example. Having completed an introductory tutorial, they can’t find a step-by-step sequence of tutorials leading to a realistic solution that has some of the complications of actual software.
The “real world” is pretty broad. There’s a wide variety of different kinds of software development. When beginners say they want to see “real world” examples, I think they’re expressing the desire to learn things that will be useful to them when they get a job in the field. There are a lot of things that could mean.
When people see a code kata like FizzBuzz or Bowling, it doesn’t look very realistic to them. The realistic part of exercises like those is the programming skills or techniques they allow us to practice. Writing “real” code involves exactly the same skills and techniques as writing contrived, trivial examples. That’s not obvious to a beginner. They might think they have to write a “real” application in order to learn anything useful. It isn’t so. If you’re a beginner, don’t skip this level of tutorials; work through it. You need the basics before you start adding “real world” complications.
Regarding the lack of intermediate-level tutorials, I think those of us who write such materials can fill the gap. We usually assume that people need a tutorial to get introduced to a new technology, and once they’ve been introduced to it they’ll be able to apply the technology to larger or more interesting problems without further help. But people who are learning these skills for the first time would benefit from a sequence of tutorials that lead them further into the details.
When you go beyond the introductory level, and you need tutorials and examples at an intermediate level, that’s the right time to start getting into these other areas. Those of us who prepare materials for self-guided learning should fill the gap in this space by providing intermediate-level tutorials that help people get started with “real world” things like branching strategies, continuous integration, incremental refactoring, working with databases, supporting existing code, handling exceptions, working with frameworks, and troubleshooting production issues.