10 Things I learned from teaching a Full Stack Dev Bootcamp.

sh000bz
7 min readFeb 25, 2021

Until last week Friday, I spent about 3.5 months teaching a full-time Full-Stack Bootcamp remotely to a cohort of women in Malaysia. The group was small but with intense coursework packed into a 15-week curriculum. It was my first experience as an instructor and I learned a lot about … well teaching. More specifically teaching technical skills from an industry that evolves every moment with new tools, frameworks, libraries, languages, etc.

These points are based on my specific experience and I am sharing them with the intent that they can inspire both prospective teachers and students to think about how they approach teaching and learning how to code.

  1. Paradigm Shift: Coding entails a paradigm shift for many people who begin their journey into this field. This is a bigger change than learning new concepts. Teaching coding is essentially teaching how to create an entity that can respond to events, conduct transactions, record changes, and transform itself based on certain data. It may appear cumbersome once you have done it so many times but for someone who is just grasping the initial concepts of this process, it is exciting and unnerving to realize that you have a lot of control. You are being asked to create something via code, you are being asked to solve a problem and it is all so new that you have no clue where to begin but apparently, there is a solution, not to mention there are many ways to do it. To take on this means to accept that you can in fact solve a problem, you can control how you do it and you can also be creative in the way you approach it. It may help you to recognize that not all jobs or industries give this kind of autonomy. At many jobs you are following set procedures, or waiting for people to tell you what to do. I had to learn to address this and give confidence that now no one else makes the decisions, it is up to the individual/student to go forward, dive in, make mistakes, learn and build SOMETHING, anything, as long as it was theirs and they had come to it themselves.
  2. More Code less Slide: You need to get down to the code, you can talk all about it, theorize, and draw diagrams, but nothing will move us forward as fast as writing code, running it, and debugging our way out of anything that doesn’t work. Additionally, no matter how “intense” the Bootcamp got, I had to remember that we are in an educational setup. This means things may need to be repeated or revisited. Live Shares/Coding took 80% of class time. That’s where we lived, in the VSCode premises. And while we spent time there, it was important that we talked out loud. As an instructor, I wanted to make sure that they could hear what is going on in my mind while navigating a piece of code, when I feel confident and when I don’t. At the start, I noticed a lot of pseudocode would be written but there was hesitation in moving on to the code itself, this is happening because of the thought process of “I have to get the right answer on the first try” we had to move on from that to “put something down, debug, move forward”.
  3. Introduce dealing with the unknown: You don’t know what you will encounter when you fork a repo of someone’s project you’ve been meaning to look at or contribute to. Accept that things may not make sense to you right away. What happens then? What’s the plan of action? Is there a ReadME.md? Is it helpful? If not can you start putting in some log statements? Is there a routes set up? Maybe that helps with understanding how components are linked. Most of all it was the acceptance that in this industry you will be dealing with the unfamiliar very often. More often than not, when you work for a company you are enhancing or fixing code that was already present. Build the muscle that lets you face something you don’t yet understand, rather than stick to only the things you’ve always known and keep repeating till they are obsolete.
  4. Navigating the YouTube rabbit hole: It is no surprise that there are numerous YouTube videos in form of tutorials, live coding sessions, courses, in fact, people have learned just by watching YouTube. There is also a lot of content that is misleading (“Learn React in 15 mins”, really?) Before you know it you are down the rabbit hole one click after another, searching for who knows what after a few clicks. It would help to create a sort of list of reliable channels that share information with the intention of actually getting knowledge across rather than collect ratings.
  5. Set up for productivity: Usually, the nature and limited time of Bootcamps may not allow for this but I find it necessary to talk about productivity in terms of how you set up your dev environment, shortcuts in the IDE, knowledge of extensions, maybe even dipping the toes into some Linux commands that make it easier to navigate the file system, as well as a healthy dose of vi or vim. These are habits that can drive productivity. It is usually a list that you grab from the internet and feel great that you have a list but that is not the same as knowing them off the bat while coding. I realized how using these simple skills and commands a lot of focus remained on what was being built.
  6. Talk about how through coding we can create positive change in our communities: One of my students built a simple application to organize grades for teachers across classes. I found out she was motivated to build it because she had volunteered for her daughter’s school and came across a disorganized grading system. It was a reminder that as a developer we gather skills which can help people in their everyday lives. Maybe not exactly a superpower but I think it comes close. The ability to build things that can make tasks easier. During discussions of what after the Bootcamp, the future seemed a lot more rewarding if we shifted focus on the community around us and how these skills could benefit it rather than constantly worrying about whether we will be valuable for a company with the skills we have. Sure, everyone would like to work for a great company that takes care of them and enhances their skills, while that is pursued, it may surprise us to know what we can build with our skills that can directly improve lives.
  7. Valuing experiences of professionals from other industries, disciplines, and/or careers who are becoming developers: Though most of the Bootcamp was people who had never written code in their lives, they had skills and experience from their past or current careers. As an instructor I was curious about them, I wanted to know how one thinks when working in real estate, or hospitality, etc. This can inform the teaching style. When you know how someone processes information you will find it effective to feed it to them in that manner.
  8. Invite other speakers and lecturers: We made time for both all-day and quick / flash lectures by those who could confidently present different topics that weren’t directly concerned with coding but were in the periphery. For example, a designer talk led to the cohort understanding how to approach designing UI for an idea that they have only been thinking of in terms of frontend and backend. A lecture by an industry professional who studies user behavior helped them ask meaningful questions on why someone would interact in a particular way with their application. My favorite was a lecture by a marketing professional who spoke about the role of communication and empathy in her job as well as in her professional relationships.
  9. Bootcamp is one step on the way to a longer journey: It has to be communicated well and understood deeply that not everyone putting themselves through an intense technical Bootcamp will be rewarded with a job right away. Some are able to have that opportunity however, a reasonable look would show us that to truly understand all the concepts and feel confident takes additional time. If you feel dejected and overwhelmed towards the end of the Bootcamp, don’t quit, plan. Make a plan where you take into account more time for you to understand and complete your projects. Maybe we are at the end of the course and there is still confusion on how something works, that’s ok. It could take a couple of days of deep study or maybe even weeks, the bigger question is how committed is this person to understanding the concept and then implementing it. Once that question is answered then a plan that is suitable to their abilities can be created.
  10. Confidence IS a game-changer: When you fuel someone’s confidence they will show up and try harder. When you sit down with someone who just doesn’t think they can keep up or are slowing everyone else down, tell them that they have their own pace, tell them to not give up, and check in on them. Let them work slowly and when they achieve even a smaller task, communicate to them that they have made progress. Be supportive as a group so they believe that others also want them to succeed. Confidence builds upon confidence. Encourage to speak up, encourage to do rather than get stuck thinking. Encourage them to make a mistake so they can learn to debug. As an instructor, you’d like them to not give up, do the same, and don’t overlook someone who is struggling. Nothing is more rewarding as an instructor than watching a student overcome challenges.

--

--