【IT Observation】Methodology for programmers to train new people

[51CTO.com original article] A reader complained to me that his company is a "technology secretive" type. Every experienced programmer is afraid that newcomers will learn his technology and replace him, so he feels that he is growing very slowly. In fact, training newcomers in the team can not only let newcomers share simple, repetitive, and tedious primary work (such as the "personal center" module, which is not difficult and requires high patience), but also deepen their own solutions to uncommon problems. It is a beneficial and harmless approach. Training newcomers cannot rely on cramming preaching, but must pay attention to certain methods and steps, which is the so-called "methodology".

[[205637]]

Create a study plan

Most IT newcomers are students, fresh graduates or people who changed their careers from traditional industries. To become a qualified IT engineer, they must go through a gradual growth process. We can help them develop a learning roadmap based on the learning sequence when we entered the industry (these plans have examples to support them. 51CTO has produced the most comprehensive IT knowledge system map). At the same time, the IT industry is a rapidly changing industry. The two technical fields of Flash and J2ME, which were once in their heyday, have long become yesterday's news. We also have the responsibility to help newcomers avoid detours.

Xiaogang became my intern in the first semester of his senior year. Although he had no practical experience, he was a graduate of a professional school, had a solid foundation, was smart and had a good memory. What was even more valuable was that he had a strong interest in Android and a spirit of study. I first lent him a few of my Android books, and then made a study plan for him based on the Android knowledge system diagram produced by 51CTO (last year's Android knowledge system diagram had slightly less content than the current version, lacking Kotlin and other content). I also pointed out several pitfalls in Android learning, such as eclipse was outdated and Google Map was not suitable for use in China, so that he would not waste time on some inappropriate chapters in the book.

Hands-on demonstration

After newcomers join the team, they will surely be eager to show off. After all, everything looks like a nail to a person who holds a hammer for the first time. Their high expectations and low skills are very similar to our past. In addition to letting them write a few demos to practice, we can also give them simple and unimportant parts of the project, and then gradually increase the difficulty and complexity. Important projects cannot be given to newcomers. The last person who was sent to run before learning to walk was Ma Su. Giving newcomers simple, repetitive but error-prone tasks can help them consolidate their foundations, while also freeing up time to study some advanced technologies. It is a win-win situation.

Xiaogang read the book for a few days, and I gave him the address of SVN so that he could get familiar with the code. I tried to give him some simple tasks, such as looking at the UI picture layout, creating a new Activity or Fragment, and declaring permissions and activities in AndroidMainfest. After all, I also made a fool of myself by not being able to distinguish the difference between layout_gravity and gravity, and was so anxious that I couldn't access the network that I sweated profusely, and finally found out that I forgot to declare permissions. On the first day of the project, he asked me a question: Why is my method of binding controls different from the book? I introduced to him the benefits of using ButterKnife instead of findViewById.

Timely communication and review

Newcomers are like seeds. If you don't fertilize or weed them after sowing, they will die on their own. Therefore, it is necessary to communicate with newcomers in a timely manner. Communication and exchange is not only about answering their questions and solving their problems; it is also about helping them review their past and learn new things, imparting them some scattered knowledge points, and reviewing their code - after all, no one can write high-performance, highly readable, and highly maintainable code from the beginning.

Xiaogang and I worked on projects together every day at work. He would ask me for help when he encountered problems. I would always teach him some tips after solving his doubts. After get off work, we often learned new knowledge. Sometimes I would help him review his code, and I would find many problems, such as "***Activity", strange text marquee controls, and countdowns written with Timer. I explained to him the MVP architecture, "android:ellipsize="marquee"", and the Android countdown class CountDownTimer.

Let him be alone

The car always has to be on the road. After the newcomer has project experience, he is fully capable of completing the task independently. At this time, he should be let go and be responsible for the entire life cycle of a project independently. In actual combat, he can not only test his learning results, but also see where he is lacking.

Under my guidance, Xiaogang made rapid progress, and his growth was noticeable every day. Soon, I let him complete a complete project independently (WeChat Mini Programs had not yet been released, and even the simplest business that wanted to get a piece of the mobile Internet pie had to make an App. Now, there will probably be no such simple applications). After he got the project requirements, materials, interface documents and other information, he started working. With the experience of the previous projects, he was able to complete this project independently very smoothly.

Beyond the code

The IT industry is changing at a rapid pace. Being a programmer who can only write one language is a dead end. The real competitiveness of programmers lies beyond the code. First, we need to use our own bottlenecks to instill the concept of workplace crisis into newcomers who have already completed their entry, and then we can improve their abilities beyond code, such as the determination to solve difficult problems, the open source spirit of selfless sharing, and the corporate culture of famous Silicon Valley companies.

Xiaogang's technical level quickly grew from an intern with no experience to a junior engineer with half a year of experience. While I affirmed and encouraged his progress, I also taught him some things other than code. First, I told him not to stick to the field of Android or even mobile Internet, but to look at the entire IT industry, so I pulled him into the 51CTO Developer Exchange Group ③ to participate in daily IT topic discussions; then I recommended him to contribute to the 51CTO MDSA channel, sharing his work experience, workplace insights and technical knowledge with his peers, which not only allows him to practice the open source spirit that programmers must have, but also earns him a lot of royalties.

[51CTO original article, please indicate the original author and source as 51CTO.com when reprinting on partner sites]