What are the musts for training fresh graduate developers?

Hi Kuya,

I have a few ideas:

First, don’t think anything is obvious or assumed. When I first started working, there were many things that were not explicitly stated that those training me thought were obvious, but actually weren’t.

Second, always explain the why, and never do anything for them without showing them how to do it as you do.

Third, always ask their thoughts and reasoning behind things. This isn’t so that you can tell them they are wrong, rather so that you can understand their perspective before giving feedback. By doing this you will have the opportunity to learn and get exposed to new ways of thinking/problem-solving strategies and also be in a better place to give help and feedback when needed.

Last I would say make sure those you are training feel comfortable asking questions, and that you feel the same towards them. No matter how much training happens, everything can’t be covered and things will come up. A single person can’t know everything, but a team can more often than not find the answer needed to a problem, if someone doesn’t have it.

Dear Kuya,

The first thing you have to do is to know the learning methods that people in your care have.
You can guide yourself from this article to obtain that information:
blog.melchua.com/2013/06/19/hacker...
Example --- Active vs Reflective Learning Style
blog.melchua.com/2014/08/12/learni...

Then you will have to understand that the learning process needs an environment in which the skills they seek can be developed. You can read the part of the center's environment here: recurse.com/manual#sec-environment

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.

Building something, even a simple thing, might help you all a lot! Every time someone encounters a problem, a doubt or whatever difficulties, then it’s a good opportunity to study/explain that part. At the beginning it might sound chaotic or hard, but if you keep up tougher, results will come.

"Kuya" is Brother in Filipino, I don't know if you're a Filipino but I find that "Hi Kuya" is a bit awkward.

I'm not a graduate student. But I'm always prepared for these kind of scenario such as code reviews, readability, conventions for your team. Learning is a continuous process, and this era of programming is a never ending path to developers. Also, Be equal to their position whether you have a higher level of experience, it all comes down to PR(Personal Relationship, Not to the level of PR). So you could build a enthusiastic development with your team.