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

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

18 pointscyrux0048 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 ?

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.

I like to write a personal log of discoveries and my day. It seems to help my team catch up on stuff I am working on.

I got this idea from dask dev notes [1]

Its amazing how every day/week history of project can help new comers.

It also helps getting your team members reach out to you. When I used to work in office a lot of people used to reach out with problems and I loved solving them. There was a freshness to these problems

But in remote scenario when I joined a new team, no body knew my strengths and I missed those times. But I think a log of this kind can help people know your abilities and give you more opportunities to solve problems outside your routine context.

https://blog.dask.org/

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)

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.

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.

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

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

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.

Reply on news.ycombinator.com