Hacker News Reader

Comment by onion2k | Hacker News Reader

I suspect by the end of 2021, we'll see more 50% work from home, particularly for new engineers.

I like remote working, and I've done it on and off for more than 2 decades. It suits me.

In my experience, mentoring junior devs and new hires on my projects is much harder for everyone involved when you're not in the same office. Sometimes you're lucky and get someone who'll speak up and ask questions when they get stuck, but often (especially with juniors) people will just try to figure things out on their own in order to not look bad at their job or incompetent or something. Some devs would rather spend a whole day on a problem and only bring it up in the following day's stand up than show they can't solve it alone. That is really bad for a project. I find I have to poke the quieter juniors regularly on Slack just to make sure they're OK, but then people get annoyed about being micromanaged. This is something I really want to solve...

View on HN

Maybe you should publicly commend the vocal juniors so that the rest can learn from their example. Say something like, "Jim Halpert realized that it would be a good idea to collaborate with me on the A4 project, and together we finished it far ahead of schedule." Phrase it so it ascribes agency to the junior, focusing on how they (with agency) decided to use the resources they had appropriately.

My Dad, still programming at 72, was one of the first people I know of to work as a remote developer. From about 1982 We lived on a remote-ish farm in Australia and out in the shed we had an IBM mainframe with a bunch of terminals and PCs on makeshift tables made from doors resting on filing cabinets. A couple of times a year some of his colleagues from the UK would fly out from the UK with a bag of tapes of source code, they would spend the next month merging their code and planning the next few months work.

Sounds like you're doing a fine job.

One thing you can do is let people flounder and fail on irrelevant small tasks for a week or two early, to help them learn the lesson that they don't know what they're doing.

The best way to make someone appreciate guidance, is to have them fall on their face, receive guidance and notice the difference.

One suggestion I had was, if you're stuck for more than 30 minutes, ping me. Juniors will almost always be stuck with something trivial you can answer within a few minutes. It gives you a break and it is something they really appreciate. If you communicate to them that they're not expected to know anything and that the first few years on the job is their real world education and a chance to ask questions without raising eyebrows, they'll be far more likely to do it.

Juniors are nice in my experience, you can mold them into something half-decent if they've got a bit of a brain and their mistakes are ones of innocence, not cunning or apathy. It's the 'senior' devs who don't know shit that you have to put up with that's almost always a disaster. They'll be well versed in lying and politics, wasting everybody's time.

I got over this by having teammates who regularly asked for help in Slack. Suddenly, it felt very acceptable for me to do so. Our #dev channel is full of my coworkers and me asking and answering questions for everybody to see that we all need a nudge in the right direction from time to time. I think when that stuff gets hashed out in DMs or in other less public places, the new devs don’t realize it’s happening.

This is why remote mature companies like Gitlab emphasize transparent communication and highly discourage private channels / DMs. Otherwise it is much easier for individuals to become silo-ed in a remote company than in a onsite company. Remote teams need to overemphasize transparent and public communication.

The flip-side of this is that the constant interruptions from the help channel prevent you from entering flow / getting deep work done.

I find that a balance can be managed if people are nudged to at the owner of the specific component they need help with, i.e. @guild-frontend or @owner-fooservice

>"I like remote working, and I've done it on and off for more than 2 decades. It suits me."

Exactly the same here for exactly 20 years. I make my own products and make products for other companies as consultant.

No real problems when I need to hire subcontractor though. Being an old fart I know many very experienced people who would never pass an opportunity to make some dosh.

I've also noticed in the job post data that remote-mature companies prefer employees with remote work experience. I'm guessing it's partially due to this problem of difficulty of getting juniors up to speed remotely.

Now most of us have remote work experience...

Pairing maybe?

I always feel like pairing is the most annoying and most mediocre way of getting people to ask the right questions. It takes double the time for easy tasks, and makes everyone really awkward. In sessions I have supervised it looks like ~70% of the time it just one person driving the keyboard solo. It does get people to learn, and if someone does something weird or gets stuck, the other usually speaks up. But it seems so slow in the average case.

Reply on news.ycombinator.com