#Iam IN(dependent)

Goal

You should be capable of developing products from scratch and solve any problems along the way with only Google’s help

One of our key goals when you take the Crio curriculum is to make you an independent developer.

This doesn’t happen in a day, but we can definitely work with you to get you there with a bit of cooperation from your side.

Think of Crio support (mentors/TAs) as Team Leads in your company. You don’t want to depend upon them too much, but at the same time, you don’t want to get stuck indefinitely on issues without making progress. That’s exactly what the above three rules will help you with.

Ground Rules

Never ask for things that you can Google yourself
Spend at least an hour trying to solve a problem yourself before asking for help
Share good amount of detail about the problem you faced and what you have tried so far when asking for help

Debugging is an Art

Developers, early in their career spend 50+% of their time debugging problems during development. If you internalize better ways of debugging, your overall throughput will be easily 2-3x of your peers.

At Crio, you will extensively use the Scientific Debugging approach to improve your debugging speed.

Scientific Debugging

Scientific Debugging is a technique that helps you debug any issue in a structured manner thus avoiding lot of frustrations and making you a debugging Ninja!

The approach consists of you going through multiple iterations of the following steps

Observation
Hypothesis
Prediction
Experiment

Feel free to use any text editor or go old style with pen/paper to note down the steps!

Your journey to becoming an Independent Developer

1st Sprint - It is okay to ask for help a bit frequently especially for JAVA-1 or JS-1. We recommend you to leverage your peer help too here.

2nd Sprint - You should slowly start moving away from raising help requests without trying enough. Slowly we’ll start enforcing the ground rules of raising help.

3rd Sprint onwards - You are an independent developer at this point - we’ll enforce the ground rules on how you should request for help. You are expected to share the list of things you have tried based on a scientific debugging approach along with sufficient context for TAs to give you the best help.

Note

We understand sometimes you are too frustrated to debug problems in which case the TA may provide you a more direct answer without you having done sufficient debugging. But we would like that to be the exception and not the norm.
We have seen one off learners (<1%) pressurizing the TAs for direct solutions instead of them trying to debug the problems themselves. We strongly discourage this behavior. But all of us are adults and we can’t force our philosophy on you. In this case, we mark you differently in our trackers and we’ll happily let the TAs share direct solutions with you. Of course it will affect your learning outcomes. But it’s a choice you make!

Checklist for a Help request

What is the issue?
- Share log/screenshot of the issue
- Share context of which ME/Module in which you are running into this
Explain the issue in your words
- What is the error message saying?
Why do you think you are running into this error?
Copy paste the scientific iterations you have tried so far

Note that if you are not able to articulate the problem => It usually means you haven’t understood the error which makes it harder for us to help as well!