When you first go into Zone01Kisumu, the most obvious thing is that there is no traditional lecture. There is no lecturer at the front, no slide presentation for you to transcribe, and no one available to help you when you encounter difficulties. Rather, you are given a task, a number of peers who are just as uncertain as yourself, and a deadline. At the beginning I had expected a standard bootcamp, but what actually happened was more like being put into a workshop where you learn to use the tools by getting hands-on with them. The following article gives the honest account that I wished I had been given earlier on: it sets out effective strategies for this kind of learning method, points out the real difficulties, and explains the way I decided when I had been stuck for long enough. But in order to understand all these points, it is first necessary to understand the reason for the school's structure.
Why This Model Exists
Zone01Kisumu is part of the 01 Edu curriculum and uses a peer-driven, project-based approach to education. The basic idea is that if a teacher gives all the answers, students mainly end up learning how to follow instructions; on the other hand, if they are asked to come up with solutions before being given the explanations, they acquire the ability to teach themselves. The projects make up the curriculum, and peers act as resources, reviewers, and members of the audience. Even though this might at first sound like a simple phrase, it really does alter the way a difficult day feels. Rather than thinking, "I didn't understand the lecture," the new challenge becomes, "I don't even know what to search for." Although this shift can be uncomfortable, it is exactly what allows the system to achieve its most important benefits, which become obvious soon after students start working on the projects.
What Actually Works
One of the main advantages is that concepts aren't left abstract for very long. If you are given the job of building a working program based on a specification, real-world problems come up right away, for example, unclear requirements, cases that have not been considered, and bugs which only show up when different parts of your code are put together. More have I learned about error handling from a program that failed during a review than from any chapter in a textbook on the topic. Another important benefit is the role of the reviewer; it becomes a standard part of the process to explain your work. When a fellow worker looks at your project, you have to defend your decisions orally, which makes it hard to hide mistakes during a thorough discussion.
The way in which these discussions are carried out also affects the way you deal with knowledge; when there is no clear authority present, you are encouraged to critically assess any claims, including your own. For instance, if a person says that a certain method is faster, the natural reaction is to say, "let's measure it." I have adopted this practice in my work as a technical writer by regularly carrying out benchmarks before making any assertions. Yet this habit has its disadvantages and involves certain costs which promotional materials seldom mention, thus bringing us to the more difficult parts of this educational approach.
What Is Genuinely Hard
The kind of autonomy which helps to develop problem-solving abilities may at the same time lead to a gradual and unexpectedly isolating experience. There are times when you can get stuck on a matter that might have been settled with just a short explanation, and yet end up spending hours working on it all by yourself. In some cases this difficulty is deliberate and has advantages; in other cases, it is simply inefficient. The problem is to tell the difference between these two situations. Without an expert checking your understanding, a misconception can survive for weeks because everyone around you shares it.
The risk grows if you start comparing yourself with the people around you. In a group of individuals who are of a similar age or social position, some will jump right into a topic while others will take longer, and it's easy to judge yourself by those who are ahead that week. Comparison is the fastest way of sapping the motivation you need in order to keep going, and I had to learn to concentrate on my own progress rather than on the mental leaderboard. Once I had stopped measuring myself against other people, a more practical question arose: if I'm going to have to face all the difficulties on my own, how am I ever going to know when the struggle has stopped being useful?
How I Decide I Have Been Stuck Long Enough
Instead of sticking to strict time limits, I follow a general rule. At the beginning, I try to clearly and briefly state the problem, since doing so usually helps me to identify the real issue. When this method doesn't work, I take the smallest possible version of the faulty code and isolate it in order to see whether the error still occurs, a procedure which generally gets me nearer to a solution. Only then do I refer to the documentation and afterward ask a colleague for help. Once an hour has passed and I haven't made any progress, I realize that continuing to struggle is pointless and so I ask for assistance without delay. It should be mentioned that the success of this approach depends on the way the following question is asked of others.
Asking Well Is a Skill
The ability to ask effective questions is much like that of an engineer, and I first learned this lesson here. It's not very helpful just to say "It doesn't work." On the other hand, if you give specific details such as "I expected this output but received that one and have already ruled out these two possible causes," you usually get a quick and useful response. By outlining the steps you've already taken, you show respect for people's time, and this in turn leads to more worthwhile answers. This kind of skill doesn't stay limited to the bootcamp; it meets the requirements of a junior developer in a professional team. Once you get into the habit of doing this, it naturally encourages you to take on the role of answering questions and reviewing other people's work.
Learning to Give Feedback
Another element of the peer-driven model involves the considerable amount of time spent examining other people's work, a skill that is highly valuable. At first, I would give only a superficial approval in order to prevent disagreement or concentrate on minor and unimportant matters. Later on, I learned how to tell the difference between real errors and alternative methods, and started to give explanations with my feedback. As a result, my ability to take in feedback also improved, reinforcing the idea that criticism of code does not amount to a personal attack. This distinction is important in professional settings where every pull request is subjected to review, leading to the final decision as to whether this approach is appropriate for each individual.
Would I Recommend It?
It depends on the individual since the appropriateness of this method varies from person to person. For people who value structure, prefer clear direction, and like to receive regular feedback, this approach might seem rather demanding. On the other hand, individuals who are at ease with uncertainty and who enjoy working out problems on their own, seeing setbacks as an essential part of deep learning, may find this kind of environment very beneficial when it comes to developing their skills as a developer. The most valuable thing for me was not just obtaining a list of technologies, but rather acquiring a practical method for dealing with unfamiliar problems, a skill which still holds value even as the specific tools change. The entire approach consists of a full explanation. As no one will tell you about it, the key point you need to take away is that you have to learn how to define the problem, break it down, check your assumptions, ask good questions, and then look at the situation in a kind way, with these habits staying with you longer than any particular framework. You should realize when considering a project-based bootcamp that the difficult days are real and that it is also during these days that the most growth occurs. I am still learning, and I expect to keep doing so in this way for a long time.
Top comments (0)