Skip to content

Latest commit

 

History

History
76 lines (50 loc) · 9.23 KB

learning_strategies.md

File metadata and controls

76 lines (50 loc) · 9.23 KB

Table of Contents

Learning and Success

Approach to Learning

Dev Bootcamp requires you to acclimate to a new learning environment and mindset. You will be confronted daily by your own limitations whether they be technical or cultural. Moreover, you will not be able to rely on grades to figure out how you are doing. You will have to assess yourself and determine whether you are progressing at a rate that satisfies you.

Our educational model is fundamentally different from those offered in traditional institutions. A Dev Bootcamp instructor's role is to act as a guide and resource, rather than a transmitter of information or an "expert." You will learn new information and technologies through challenges, not lecture. You will spend the majority of your time working and learning with a pair or group as well.

That said, the Dev Bootcamp experience is not for everyone. The curriculum condenses an inordinate amount of information into 9 weeks, and the rigor, pace, and teaching style does not suit every student's needs. It is important to be honest with yourself and your teachers if this teaching style does not suit your learning needs.

In order to be successful at Dev Bootcamp, students need to:

  1. Be comfortable not knowing everything
  2. Be willing to make mistakes
  3. Turn failures into learning opportunities
  4. Ask questions, even when they think they know
  5. Be excited to teach others
  6. Adopt, adapt, or create approaches to solving problems

*Also see Learn to Code or Code to Learn? *

Learning and Thinking Styles

As part of the prep work for Phase 0, we asked you to identify your VARK learning style and Gregorc thinking style . We ask you to do this so you can better tailor your experience at Dev Bootcamp to your unique learning needs. For example, if you are a multimodal learner who is an Abstract Random (AR) thinker, you will probably not do as well coding by yourself without any resources to guide you. You would do better to have a couple of videos, bits of reading, and a pair to work with to solve challenges.

There is not just one way to learn how to program or be a programmer, and we are not trying to make you into the "typical" programmer who works by him/herself and solves all problems without help.

In fact, the popular view of a programmer sitting in a basement alone is completely wrong for the vast majority of coding jobs. As a software developer, you will pair program, work with a team of engineers (and sometimes teams of teams), and work with other teams within a company, such as marketing, product, customer service, and design. Part of being a professional programmer will be assessing a problem, thinking through and discussing solutions, "spiking" (or experimenting) alone or with a team, and estimating how long something will take to code. All of DBC will prepare you for that. You are starting now.

In other words, you should ask for help, seek additional resources, and work on your own when you need to.

We are working to create a curriculum that appeals to all different learning and thinking styles, but it's not perfect. We appreciate any feedback on our curriculum and suggestions for improvement.

Strategies

Whatever your learning or thinking style, here are a few strategies you can try to incorporate to help you learn and succeed.

  1. Take Breaks Do not expect to will yourself to a solution through sheer effort without any breaks. If you find you are working for two hours and aren't making any progress, don't get frustrated, take a break. Spend time thinking about strategies without feeling guilty that you aren't coding. You'll be amazed at how much easier it is to solve problems after taking a break.
  2. Get Sleep This goes with #1. If you aren't making progress and you are tired, go to bed. I guarantee you that you will have an easier time solving the problem tomorrow.
  3. Pseudocode Do not expect yourself to write code without having to think through an approach, and give yourself the time and space you need to think and pseudocode a strategy. Practice pseudocoding even when you think you don't need to. It will be even more important when you get to more intricate problems, and you don't want to have to learn how to do it when you need it most.
  4. Be honest with yourself If you don't understand something, ask. Each person comes to the program with different knowledge, levels, and experiences, and it's important to give yourself the space to ask questions. No one knows everything, and contrary to what you may feel, you aren't the only person who doesn't get something.
  5. Be curious If you don't know why something works, go into IRB and break it down. Figure out what it's doing at every step. This will probably be more natural for people who are Concrete Random thinkers, but IRB is a great way of really learning how to tinker with code and learn what methods are doing. Challenge yourself to use it and never be satisfied with not knowing how or why something works.
  6. Be true to you, pt. 1 Yes, it sounds cliche, but humor me. Don't think you have to ascribe or assimilate to some stereotype of how you think programmers work. If you need to work with people, seek out your cohort mates, attend meet ups, pair with friends to get what you need. Don't lock yourself in a room for 12 hours while you bang your head against a wall hoping to figure it out because that's what you think programmers do. If you need to stop programming at a certain time, do it. Whatever you need, do it.
  7. Be true to you, pt. 2 Also, recognize that you don't have to "fall in love" with coding. It's ok to be frustrated, it's also ok not to have fun occasionally when you're stuck. If you see coding as a means to an (awesome!)end, that's fine. If you see coding as a be all end all, that's fine too. Avoid comparing yourself to a stereotype or "typical programmer" that you've made up to determine your value, aptitude, or ability.

Success

The Phase 0 program attempts to bring the DBC environment to your home in a way that helps you prepare for your new life and enter Phase 1 at a level where you feel prepared enough to be successful. That said, Phase 0 is a different beast than Dev Bootcamp. Because you are remote, you need to be far more organized than you will when you get to DBC. You will have to manage peer pair programming, guided pairing sessions, four to six challenges per week, reflections, etc. It will take quite a bit of organizational work, so be ready for it. Phase 0 also requires you to communicate with instructors differently than you will at DBC. We depend on you to initiate a conversation when you are falling behind or having difficulty. You can't assume your Phase 0 Facilitator will initiate contact in the event you fall behind. It is up to you to take Phase 0 seriously and to learn as much as you can during the time. Instructors and facilitators are here to guide you and help you, but Dev Bootcamp relies on students taking the initiative to learn.

Not for Everyone

All this said, Dev Bootcamp is not the right learning environment for everyone, and one of the motives for Phase 0 is figure out who the environment won't work for before they pay over $12,000, quit their job, and move across the country. This is intended as a favor to those students. There are many people who honestly need more time than 9 weeks and a less intense environment. That is ok, and there are other options.

####Yellow flags We gauge a student's fit in Phase 0 and Dev Bootcamp through their kindness, integrity, and effort that they put into the program. Participation and communication are key components. Students who demonstrate any or a combination of the indicators below may be put on a path for monitoring or being asked to leave. These indicators, or Yellow flags include, but are not limited to:

- Leaving challenges unfinished
- Not following the submission procedure
- Copying code on solo challenges
- Demonstrating apathy for their pair or the challenge
- Letting a pair drive and navigate during a GPS session (taking a back seat)
- Missing Guided Pairing Sessions (GPS)
- Missing scheduled peer-pairing sessions
- Having difficulty engaging with a pair
- Lacking the ability to demonstrate the learning objectives
- Failing to submit or rate feedback
- Not submitting the Reflections

####Getting asked to leave It's not our goal to kick people out of the program. It is our goal to identify people who will not thrive at Dev Bootcamp. We truly want to save students the pain of leaving their jobs, moving etc. only to find out that Dev Bootcamp isn't the right environment for them.

We take the decision to ask a student to leave seriously, and we do so after considerable thought. Having one yellow flag emerge during the course of Phase 0 is not a deal-breaker in and of itself, but showing a combination or repeatedly demonstrating any of these indicators is a problem. If this happens, we will warn the student through email. We make decisions to allow students to continue, or ask them to leave, at the end of each unit.

In the event a student is asked to leave, Dev Bootcamp will provide the student with a full refund, including the non-refundable deposit.