from Hacker News

Ask HN: How to learn by observation from co-workers in a remote-first company?

by cyrux004 on 12/23/20, 9:53 PM with 8 comments

A good part of learning in my career has been by observing my co-workers work while I watch over their shoulders, specifically around areas like developer tools, productivity, operations and monitoring.

During my intern years, I had a co-worker who was a vim power user and used it extensively for wide rangings tasks which gave me a peek into effective keyboard only techniques. After a few years at Microsoft, when I joined a company that used unix style development environment and linux based stack, I learnt my way around tools by observing my colleagues.

For a lot of operational tasks and firefighting time sensitive issues, just observing co-workers and understanding how they operate in terms of what to look for first, which dashboards do they do use, quick debugging techniques etc. has given me resources to quickly on-board and become more independent.

Now that my company has decided to go remote first, I am bit concerned if these type of non-structured learning exercises can happen at the same pace ? , especially for new or junior employees.

Does anybody have any ideas/tips they recommend ? Something I can use in my own team if I become a manager ?

  • by luxurytent on 12/24/20, 12:17 AM

    A culture which prioritizes writing things down will allow for this type of pattern.

    For example, engineers who solve problems should tell stories in their commit messages, providing context, they should output ideas in Slack, and when they have questions, they should provide context and link to references they have explored (tickets, external resources)

    It sounds like a lot of work, but in my opinion it's not. That deliberate slow down by one person allows others to grow at a more healthy pace, ultimately progressing the entire team/org (sizing dependent etc.)

    I'm not saying Slack should be a knowledge share but it does become a great portal to more information, and ultimately the git log is one of the more important areas in a business to provide learning opportunities for other engineers.

    That type of culture will naturally be better at writing documentation and taking care of it because they are practising well formed communication on a regular.

  • by ZainRiz on 12/24/20, 12:25 AM

    It's certainly tricky. I personally found pairing to be pretty helpful when I joined a new company during covid.

    There's an app called Tuple which made pairing online pretty easy (if only it didn't ask permission to install updates every day)

  • by overlapping on 12/24/20, 12:18 AM

    100% remote here. It's not the same as spontaneous "over the shoulder" learning, but scheduled Lunch & Learn sessions can be a great way to let team members share what they know. Building a good lunch & learn presentation is also a very useful exercise and generally helps the presenter refine their skills as well. Pair programming or debugging, especially where there's an opportunity to share new tools/techniques can be good in one on one meetings, but are also worth documenting and bringing to a regular standup or equivalent.

  • by bamurphymac1 on 12/23/20, 11:24 PM

    We’re distributed, about 15 people now. 1/3 devs, 1/3 sales & 1/3 ops.

    We get by with frequent and non-fussy use of screen sharing in slack or zoom calls.

    If someone is leading on a project / bug / sale we expect some quick and dirty Looms or just Mac/iOS screen recordings into a shared drive for a simple knowledge base.

    I record a LOT of our calls and will do at least brief readme write ups that often end up in our git repos with links to the resource.

    I think the big cultural step is just being open to ask for advice on tooling and quick to share little finds.

  • by fiftyacorn on 12/24/20, 6:52 AM

    I've made tutorial videos in the past at organisations. How to install stuff, good things work. Nothing to long but it lets people watch any rewatch

  • by vanusa on 12/23/20, 10:13 PM

    Hey there - you might want to fix the title ("remote-first")

  • by wryoak on 12/23/20, 10:08 PM

    I've never worked in a remote first environment but interviews with such companies has revealed to me that they generally try to cultivate a culture around screensharing (often coupled with pair programming) to facilitate this kind of learning.