Former oilfield trash turned DevOps and InfoSec development specialist; father of the 3 cutest little girls ever in the same family; MtG scrub for life; C,Debian, and KDE fanboy
As an autodidact (a person who teaches themselves anything) who moved to software from another industry 2 years ago, here are the things that my supervisor utilized to get me up to speed:
1) 1 hour a day of self-directed study on the languages we used, with questions to be answered during our daily meeting.
2) He introduced me to the tools of the trade: frameworks, IDEs, debugging, our internal wiki, StackOverflow, and stack tracing. Then, at every meeting, we would walk yhrough the code using those tools together: not to resolve any difficulties, but so that I could resolve them myself.
3) the Theory behind the Practice: rather than answer a question, he would always ask a leading question to help me derive the answer. So, for example, when I couldn't understand why my PHP array parser would only throw exceptions, he asked me how i would write the code in C (since PHP is written C) to handle array parsing, then we sat down and wrote a simple implementation. Before we even got to the end of writing it in C, I already understood that my type was wrong and that I needed to pass the value as a string not as $array[$key].
4) Thank them for asking questions with sincerity.
5) Remind them that they don't have to reinvent the wheel and if it seems like they do, they need to check their assumptions.
As an autodidact (a person who teaches themselves anything) who moved to software from another industry 2 years ago, here are the things that my supervisor utilized to get me up to speed:
1) 1 hour a day of self-directed study on the languages we used, with questions to be answered during our daily meeting.
2) He introduced me to the tools of the trade: frameworks, IDEs, debugging, our internal wiki, StackOverflow, and stack tracing. Then, at every meeting, we would walk yhrough the code using those tools together: not to resolve any difficulties, but so that I could resolve them myself.
3) the Theory behind the Practice: rather than answer a question, he would always ask a leading question to help me derive the answer. So, for example, when I couldn't understand why my PHP array parser would only throw exceptions, he asked me how i would write the code in C (since PHP is written C) to handle array parsing, then we sat down and wrote a simple implementation. Before we even got to the end of writing it in C, I already understood that my type was wrong and that I needed to pass the value as a string not as $array[$key].
4) Thank them for asking questions with sincerity.
5) Remind them that they don't have to reinvent the wheel and if it seems like they do, they need to check their assumptions.
Thanks Eric!