Everybody loves the concept of mentoring. You will both help your padawan and clarify things for yourself. Maybe you will also get a promotion for such activity. So, there are no drawbacks at all and if you have a chance, you should try it. But hard-hearted senior developers usually forget: a junior is shivery and vulnerable. He is almost like a child who needs to be taught everything in this unfamiliar world. And his further career depends a lot on his mentor.
I said goodbye to my last mentor a few months ago, and I had been almost under continuous care before that. I had five teachers. While my experience is fresh, I want to share it and warn those who are passionately willing to learn from irreparable mistakes. Or just publish a bullet list for juniors to check that your mentor is not an asshole.
Do not give final results “correct” answers. Point out the problem areas and give tools to solve it. Each final list of decisions that you give to a person will become obsolete over time. You need to create an educable developer, not an educated one, who is able to find solutions, not to memorize the standard set.
It is more important to teach tools and principles, rather than specific solutions in the code. Try pair programming, show how you use IDE, debugger and a version control system. There are many obvious optimizations of your workflow, which a junior will get only after a year or so. Save him some time at the start.
I did not immediately figure out the Interface Builder. In the beginning, it seemed to be a good idea for me to just press “Reset to suggested constraints” and pray. At some moment, this did not work, and I scribbled “not working, needs help” to my mentor. He called me in Skype, I shared the screen and like a monkey pressed the buttons, which he quickly dictated. It worked. The next time the situation was the same. When the problem has repeated for the fourth time, I finally guessed to read the guides.
If your ward respects you, he will not doubt your words. Therefore, take responsibility for your pieces of advice. Affirm something, just being absolutely sure that there are no alternatives. Explain why this is the best solution, which advantages it has, what kind of problem it solves. It is better not to give a solution at all, but to list methods known by you, their pros and cons. Let junior learn to take responsibility for decisions himself. During analyzing and comparing alternatives he might teach you something occasionally.
When it came to network requests, I obviously used Alamofire. Sometime later, my mentor looked at the code and was not very happy. His final advice was to replace the code with synchronous NSURLSessionTask
. After .resume()
call, the thread was locked and unlocked only in the task callback. No comments.
He also shared his own implementation of Result type and told me to use it without further explanation. The idea of Result, as I understand now, is ok… But that time I just left this file to lie and die in the project directory. Even one attached article about the Railway pattern could greatly boost my understanding.
You are not a coach on personal effectiveness, although you will inevitably have a strong influence. At least you should do no harm, nevertheless, even minimal motivation is going to be useful.
You are like apostle Peter at the Pearly gates. Try to present IT in a slightly more favorable light. It is clear that you are a professional who fixes bugs with crutches 24/7, but … Share IT celebrities twitter, jokes from large companies or have a beer on local devs meetup. Or just recommend Swift by Sundell, it might be quite exciting. Show a fun part of our sphere, not just dull days of dragging tasks in Jira.
Be less serious in face-to-face meetings, do not show your fatigue and pessimism on a newcomer who has not seen or achieved anything yet. Encourage any development, even if you have already fed up. Junior wants to try a new framework? No problem, go. Interested in linter setup? Yes, we have always dreamed about that! Interested in Rx? Here are a few useful articles about it.
It is clear that strict business wants it “to be done tomorrow”. But let him spread his wings before a real production. Junior is a long-term investment, you should not try to get a profit from him immediately.
My mentor has always listened to me and often approved technical solutions I had found. I will always respect him for letting us throw out legacy code when someone else would cry: “Oh, this has low priority now, don’t touch it.” Sometimes he learned a new solution from us and we had a long discussion (just like seniors) about its convenience. It was obvious that he cared about our professional growth.
Attention is good, but your time is also required. You can’t be authority just because you are the teacher. You should dig into junior’s concrete tools and current tasks. It is always more interesting to learn from a person who gives a shit about you at least minimally.
You should not break the initiative of using technologies unfamiliar to you. If he can justify his choice, let him go. It does not matter that you do not have experience in the selected framework. Your experience allows to understand it much faster.
“I knew, but I forgot”, “I haven’t used it for a long time” and “I have another tech stack now” — these phrases should be excluded. You are the king and god only while you quickly and correctly answer questions, solve problems that appeared. If you are only able to come, moan five minutes, “turn on / off“ and leave, then you are not good at all.
My app crashed due to an unconnected outlet. This can be recognized in a second if you have ever encountered a problem. My sensei was sitting, swearing, cleaning derived data for an hour. As a result, the decision was suggested by some intern.
Junior will inevitably suffer and fuck up. After all, this is the “experience”. Make his complicated path easier.
Provide task choice and clear acceptance criteria. Build processes like in real production world. Let it be sprints and planning, grooming and retrospectives. This will create an opportunity to regulate a schedule. Junior will be able to choose tasks that he is interested in or which he understands, how to do. In case of stupor or long waiting for an important answer from somebody, he can just switch to another task and not to languish. And of course, there is motivation of the fulfilled plan. Did you complete the sprint plan in the middle of it? Well done, take a beer and .
My backend team has sat without tasks for two weeks because: “frontend is lagging behind, we must wait, do something for yourself”. Frustration and cannibalism in the ranks of developers. Always feed your beasts.
If you are just a dude who sometimes comes out from nowhere in a crumpled shirt, the impression of you is disgusting. Your old colleagues know that you are a cool reviewer, excellent architect and once shared a bottle of an expensive whiskey in the office. But junior can’t recognize good/bad programmer. Everyone is equally cool for him.
study hard and become me
Think about your representation. Show that you are doing something. Make him want to get into your life. Order him to subscribe on your Instagram, where you post photos from conferences and meetups, or show a podcast episode with yourself. Share a link to the blog, show a “employee of the month” certificate. If there is absolutely nothing to boast about, maybe it’s too early to teach someone, isn’t it?
Talk more to junior. Become an idol for him, let him think that you are doing something beyond the limits, even if it is not true. Make him respect yourself. And be near, let him see what you do, that you are not somewhere in the clouds, but with him in the same company, working on a similar project.
Be alive and involved. Show that you have interests, that your growth is not over. Because soon junior will become an old fart with his family and mother-in-law, and he will definitely have no time for development and knowledge. And now it is his brief moment of productive life.
My mentor was just such a dude, who comes to the office once a week, flops on the sofa, sighs and says: “Well, what have you got there again?” With all my naivety of that time, it was impossible to believe in his competence. I did not want to evolve in order to eventually become similar to him.
clap if u remember those times
My friend junior told me a very sensible thought:
“Now I finally see the path to become a person I want to be. In order to go through this path you only need diligence and will. And talent doesn’t matter at all”
A beginner sees a rockstar programmer who turns in the middle of a development process, gives instructions, offers solutions. Junior looks around at his small tasks and does not understand how to become so cool. Should he just wait for required three years of experience?
Tell him about the past, how you started. Stories about successful well-known businessmen are much less impressive than the story about a guy from your university who get an offer from Facebook.
Give sincere hints concerning your path to success, otherwise junior will come to frustration. It causes thoughts that he was just born “without talent”, it is not possible to become “like you”. Beware of idioms like “well, I always took more responsibility and was not afraid of new tasks.” I did this, then I read that, then I got there. A two-hour conversation with beer (junior should pay) can give him an excellent development roadmap for the next few years.
For just one imperial stout brought, you can hear from the mentor a story about his youth. Hear his/her fate, the motivation of the steps taken in life, and then evaluate the results. And this is not well-known “learn from others mistakes”. Rather, “cut the path where the tutor went round and round”.
There is a lack of tasks for junior level sometimes. The standard solution is to wave aside with words: “get familiar with the code base.” The truth is that “getting familiar” with the code base without a specific task is a waste of time. How do you even imagine it? Just open and read the names of all 1000 project classes?
Come up with something. Do not let the energy boil out just like that, otherwise junior will become prematurely a cynic who is disillusioned with everything. Surely there are unwritten tests or framework whose version you need to update. As a last resort, convince him that it is extremely IMPORTANT to learn Haskell or take a course about ML.
I remember at the beginning I had a task to write tests with the Mockito, and then a simple frontend for monitoring with React. I will never forget how we configure a connector for Elastic Search full-text search worked with MongoDB. Most likely it was not necessary for anyone at all, but how damn fun it was.
padawan, why u pushed to master again
Of course, there’s no need to protect junior from all dangers of IT world. He has to be prepared for the inevitable stress and despair. We all know Dr. Cox and “Miracle on Ice”. Control junior’s self-respect. Sometimes it’s ok to remember him that he is still not so good. The main thing is not to overdo it, because there are problems with toxicity in the IT community. The ideal option is to make such a team so that every person has someone to level with, try to catch up.
Try to shake it all the time. Come to work and say: “I started learning a new framework/course/language, it’s so interesting, and you are still sitting, watching TV series?” Prohibit him to stop even for a second, it is too early for rest.
But do not forget the contrasts. Shout, criticize, and then “Cool decision, guy” on review and cheap beer on Friday at the office. Give him an understanding that satisfaction can be obtained not only from money but also from the process itself.
You have got used to slang and you know the whole community. Junior looks at all this with wide-open empty eyes. Let’s be frank, he can read the documentation of the language and search through StackOverflow.
Give him the ground under his feet, give concepts that he can not google or read. Actual answers on questions like “Who is now on demand at the market?”, “How to grow up in a company?”, “How to endure obscurantism and shit in the work team?” — which are really hard to get.
Recommend podcasts and blogs. Junior is a vase into which you can infinitely pour, so the extra will go away by itself. But leave the vase empty is not an option. Let him live by programming, breathing with terms, echoing sentences. The sooner he enters the world of Medium, Twitter and blogs — the more competitive he becomes comparing to his comrades.
Nobody has explained to me what to say during a stand-up. “What did you do today?” and I seriously went into a detailed story about which class I was testing today. I gained the most valuable knowledge “Always put the smile at the end of the chat message, otherwise, you will be called toxic” only after a year.
I learn a lot from my tutors, they were the ones who give shape to me as a developer. Even bad examples gave me knowledge of how NOT to do, although I would prefer to have only good teachers. After this article, even a junior will be able to adjust the mentor’s behavior and optimize his education.
Separate greetings to Ekaterina Petrova and Rustam Kadyrov. They gave me faith in a bright future and pushed me to many important actions in my life. And I will always remember our discussions and evenings in an office.
The relationship of a student and a teacher — the most exciting thing for the whole career. It is always nice to have a moment of nostalgia for cozy minutes of collective working ecstasy. After all, close friendship is mostly born from such a relationship. And friendship is magic!
Respect your juniors, grow them free from toxicity.
Take a short survey — https://goo.gl/forms/StARJasrqOpIqiwv1Your opinion really matters to me!
If you liked the article, give it a clap (50 times) and share it. Subscribe me to read more about iOS development. Provide your children with normal mentors :)