4 ms·

Currently managing an all remote team. All senior devs and a fantastic product manager, QA and analyst; all people I've known for more than a decade. I honestly

Currently managing an all remote team. All senior devs and a fantastic product manager, QA and analyst; all people I've known for more than a decade. I honestly don't know how I would do this with junior devs. Not their fault; my fault. The only problem was my father died while I was visiting relatives in France in December and it really threw people on the team off what they were supposed to be doing heading into the holidays. I was focusing on how to store a dead body from across the ocean for about a week. My takeaway: uncertainly can knock you for a loop in an expensive, subtle and quick way. Work to eliminate uncertainly for your team and if they're good, they will be happy and healthy.

mmastrac 7y ago
> I honestly don't know how I would do this with junior devs. Not their fault; my fault. Ditto. I'm still pondering how working with junior folks might work. In-office teams _may_ be able to absorb and level-up more junior people. Would love to spitball ideas on this with anyone else interested in that topic.
- Ididntdothis 7y ago
  That’s a good point. All my remote experiences have been with pretty experienced and self sufficient people. I would think that bigger remote companies like basecamp or Gitlab or Automattic have experience with onboarding junior people. Or maybe they also hire only experienced people.
  - nickbauman 7y ago
    I know a bit about basecamp's hiring from a few years back through a friend of an employee. They have a lot of trouble getting people hired. Mostly because they seem to have a unicorn list of things each hire has to come in the door with.
  - jeanduplessis 7y ago
    I’m a hiring manager at GitLab and we currently don't hire junior engineers: https://about.gitlab.com/handbook/engineering/career-development/#junior-engineers https://about.gitlab.com/handbook/engineering/career-develop... That said we are trying to bring in more junior engineers via our internship program: https://about.gitlab.com/handbook/engineering/internships/ https://about.gitlab.com/handbook/engineering/internships/ If our internship pilot is successful we hope that this will be a feasible way to bring in more junior engineers.
- house9-2 7y ago
  Pair programming is probably the best way to bring on junior developers. It isn't that difficult to do remotely. But some people just don't like it in general.
  - nickbauman 7y ago
    Love pair programming but I find it really draining when working across a video conf.
  - ellius 7y ago
    This was my thought too. At least while they're getting ramped up, then maybe slowly let them go off and take pieces on their own.
- soneca 7y ago
  I have some ideas. For context: I am a junior developer (actually right now, I am starting to call myself "mid-level"), but I am 40 years old. After a career change, I am frontend dev for 2.5 years now. So it's all too fresh. My first dev job was in a great company with a great engineer culture and helpful senior developers. I started without knowing a few very basic things, like git and testing. I have never worked remotely, but I learned to code studying for about 8 months, full-time, from home, alone. I will try to combine these experiences into ideas of what could work for having junior developers on a remote team. - Setting up your environment is scary. For a new junior hire, you must have someone responsible for helping the junior dev set up their machine. Someone patient and non-judgemental. Documentation must be unambiguous, really step-by-step, without assuming anything about what the dev should know already. Getting to the point when I could run a project on my computer without any issue is a big deal. - Junior developers need a safe space to ask dumb questions. In the office, I would stand up and go ask a senior developer. From meetings and conversations, I could identify the ones that were more open to answering very basic questions in a non-judgemental way. These were the ones on your team and others who took the time to come present themselves to me, show interest in you and your background, and explicitly say that I could go to them and ask for help if needed. For some people, this is natural to do in-person. But I have the impression that those same people wouldn't do that as spontaneously in a remote environment. This should be encouraged. Tell senior developers from other teams, to go and make this intro and offer for help in individual channels, not just a formal message on the public channel. Go into a DM and make sure the junior dev is comfortable with messaging that developer with "dumb" questions any time. - To the point above really work, your team must have senior developers that are patient, non-judgemental, and willing to help junior developers. Not just the ones in the junior dev's team, but a few others in other teams too. This is true for in-office too, but worth saying. In my first job, I could go to 4 or 5 senior frontend developers from all over the company to answer my noobie questions. That was ideal. I could rotate the ones that I would interrupt, I could try to identify the one that it was in a better position for me to interrupt, I could have different styles of explanations from different people, I could ask something that I had already asked, but forgot, only to a different developer so I wouldn't look stupid or annoying. Some very knowledgeable developers are great discussing complex problems of software architecture, but the moment a junior dev asks why they are getting a weird error when running a project without realizing that they just forgot to do "npm install" they just think "I don't have time for this shit" and it shows. There is such a thing as a junior dev asking too many questions too fast (without proper research on their own), but a junior dev should never feel afraid of asking. Make them comfortable to ask anything first, and only if they start incurring in this behavior of asking too much without trying on their own, you give this feedback so they can improve. - Code Reviews are essential for junior developers. In this case, almost nothing changes by being remote. Just remember that code review of junior devs should include an education part. Explanations, code samples, links to resources, clarifications of terms. Things that would sound patronizing to senior developers are fundamental to junior devs. Err on the side of explaining too much. Some code reviews require more clarification than what's written on the review. So make sure a junior dev being reviewed is comfortable in DMing the person who reviewed for clarification and guidance. - DMing itself might be an issue. I know remote teams encourage all discussions to be on open channels, so the knowledge is not siloed. But junior devs really need a private line for clarifications without exposing themselves too much. It is easier to ask dumb questions in a private message. - Lastly, I do think regular junior devs (who are also young and inexperienced, not just technically junior like myself) need closer management. At each beginning of the day, it must be clear what are the tasks to be done; at each end of the day, it should be written what was done. It can be done in a way that is not micromanagement, but it is much easier for a junior to be lost, and that leads to being unproductive. Procrastination might come from confusion, not just time management. Also, get suspicious of a junior dev going too quiet. A senior dev might disappear from communications for a whole three days and come back with a very well-done and researched PR. A junior dev doing that will probably come back in three days and say, "I am not sure if it is that what you wanted... but I did this." And it was a totally different thing. They just lost three days googling weird error messages, reading tutorials, copy/pasting stack overflow answers, only to learn they were doing something that was not what was asked. Check junior devs work every day. Of course, it requires management skills to don't do it in a condescending or micromanaging ways.

mmastrac 7y ago

> I honestly don't know how I would do this with junior devs. Not their fault; my fault. Ditto. I'm still pondering how working with junior folks might work. In-office teams _may_ be able to absorb and level-up more junior people. Would love to spitball ideas on this with anyone else interested in that topic.

Ididntdothis 7y ago
That’s a good point. All my remote experiences have been with pretty experienced and self sufficient people. I would think that bigger remote companies like basecamp or Gitlab or Automattic have experience with onboarding junior people. Or maybe they also hire only experienced people.
- nickbauman 7y ago
  I know a bit about basecamp's hiring from a few years back through a friend of an employee. They have a lot of trouble getting people hired. Mostly because they seem to have a unicorn list of things each hire has to come in the door with.
- jeanduplessis 7y ago
  I’m a hiring manager at GitLab and we currently don't hire junior engineers: https://about.gitlab.com/handbook/engineering/career-development/#junior-engineers https://about.gitlab.com/handbook/engineering/career-develop... That said we are trying to bring in more junior engineers via our internship program: https://about.gitlab.com/handbook/engineering/internships/ https://about.gitlab.com/handbook/engineering/internships/ If our internship pilot is successful we hope that this will be a feasible way to bring in more junior engineers.
house9-2 7y ago
Pair programming is probably the best way to bring on junior developers. It isn't that difficult to do remotely. But some people just don't like it in general.
- nickbauman 7y ago
  Love pair programming but I find it really draining when working across a video conf.
- ellius 7y ago
  This was my thought too. At least while they're getting ramped up, then maybe slowly let them go off and take pieces on their own.
soneca 7y ago
I have some ideas. For context: I am a junior developer (actually right now, I am starting to call myself "mid-level"), but I am 40 years old. After a career change, I am frontend dev for 2.5 years now. So it's all too fresh. My first dev job was in a great company with a great engineer culture and helpful senior developers. I started without knowing a few very basic things, like git and testing. I have never worked remotely, but I learned to code studying for about 8 months, full-time, from home, alone. I will try to combine these experiences into ideas of what could work for having junior developers on a remote team. - Setting up your environment is scary. For a new junior hire, you must have someone responsible for helping the junior dev set up their machine. Someone patient and non-judgemental. Documentation must be unambiguous, really step-by-step, without assuming anything about what the dev should know already. Getting to the point when I could run a project on my computer without any issue is a big deal. - Junior developers need a safe space to ask dumb questions. In the office, I would stand up and go ask a senior developer. From meetings and conversations, I could identify the ones that were more open to answering very basic questions in a non-judgemental way. These were the ones on your team and others who took the time to come present themselves to me, show interest in you and your background, and explicitly say that I could go to them and ask for help if needed. For some people, this is natural to do in-person. But I have the impression that those same people wouldn't do that as spontaneously in a remote environment. This should be encouraged. Tell senior developers from other teams, to go and make this intro and offer for help in individual channels, not just a formal message on the public channel. Go into a DM and make sure the junior dev is comfortable with messaging that developer with "dumb" questions any time. - To the point above really work, your team must have senior developers that are patient, non-judgemental, and willing to help junior developers. Not just the ones in the junior dev's team, but a few others in other teams too. This is true for in-office too, but worth saying. In my first job, I could go to 4 or 5 senior frontend developers from all over the company to answer my noobie questions. That was ideal. I could rotate the ones that I would interrupt, I could try to identify the one that it was in a better position for me to interrupt, I could have different styles of explanations from different people, I could ask something that I had already asked, but forgot, only to a different developer so I wouldn't look stupid or annoying. Some very knowledgeable developers are great discussing complex problems of software architecture, but the moment a junior dev asks why they are getting a weird error when running a project without realizing that they just forgot to do "npm install" they just think "I don't have time for this shit" and it shows. There is such a thing as a junior dev asking too many questions too fast (without proper research on their own), but a junior dev should never feel afraid of asking. Make them comfortable to ask anything first, and only if they start incurring in this behavior of asking too much without trying on their own, you give this feedback so they can improve. - Code Reviews are essential for junior developers. In this case, almost nothing changes by being remote. Just remember that code review of junior devs should include an education part. Explanations, code samples, links to resources, clarifications of terms. Things that would sound patronizing to senior developers are fundamental to junior devs. Err on the side of explaining too much. Some code reviews require more clarification than what's written on the review. So make sure a junior dev being reviewed is comfortable in DMing the person who reviewed for clarification and guidance. - DMing itself might be an issue. I know remote teams encourage all discussions to be on open channels, so the knowledge is not siloed. But junior devs really need a private line for clarifications without exposing themselves too much. It is easier to ask dumb questions in a private message. - Lastly, I do think regular junior devs (who are also young and inexperienced, not just technically junior like myself) need closer management. At each beginning of the day, it must be clear what are the tasks to be done; at each end of the day, it should be written what was done. It can be done in a way that is not micromanagement, but it is much easier for a junior to be lost, and that leads to being unproductive. Procrastination might come from confusion, not just time management. Also, get suspicious of a junior dev going too quiet. A senior dev might disappear from communications for a whole three days and come back with a very well-done and researched PR. A junior dev doing that will probably come back in three days and say, "I am not sure if it is that what you wanted... but I did this." And it was a totally different thing. They just lost three days googling weird error messages, reading tutorials, copy/pasting stack overflow answers, only to learn they were doing something that was not what was asked. Check junior devs work every day. Of course, it requires management skills to don't do it in a condescending or micromanaging ways.