51–60 of 332 posts
I've been working on remote teams for almost 20 years. The key to success is overcommunicating. In other words--don't assume people have full context or share assumptions. Write emails that lay out assumptions explicitly and detail problems completely. As a manager I sometimes feel like a Habsburg bureaucrat buried in the Chancery offices sending painstaking messages to a far flung empire. Come to think of it, remote…
Earlier quoted context omitted.
An engineer that can't communicate properly is a poor engineer, regardless of their coding ability. I've worked with too many great coders who were terrible at communicating. This includes engineers who were fluent at English. Communication is an extremely important skill. This is a reality of life. If I moved to Nigeria and could barely speak the language, should I expect people to accommodate my poor communication…
> If I moved to Nigeria and could barely speak the language English?
I just learned right now that Nigeria's official language is English!
Since we’re at the topic of eloquence, might I add that horribly-written codebases are unbearable to work with during this time, or perhaps even during regular times for as long as the set up is remote. I get it that codebases inevitably rot over time, but the amount of rot can be mitigated by good dev practices such as unit testing, code reviews, best-effort (not perfect!) documentation, and standardizing dev practi…
This isn't my experience, I find that people who are quick to initiate communication do really well. Doesn't matter too much about the writing (maybe some people are much worse than us at writing) as we simply voice chat if things weren't clear
Earlier quoted context omitted.
The other thing working remote forces me to do is to actually think before I assign a task to someone or ask a question. It's a lot easier to casually interrupt someone with half a thought than to write a poorly thought out email.
That is also the main advantage of email over IM. Email kind of forces some effect of the remoteness you described even when everyone is in the same office.
I joined a new company recently (during pandemic; July). The onboarding was not so smooth. I was constantly following up here and there to get things done (e.g access to tools with IT), more importantly to get to the part with whom do I need to follow up and how to follow up; figuring this out was another follow up. I created an onboarding guide last week (for my team) which was a very small thing for me (created a d…
I've been the "over the moon" guy when someone comes aboard who wants to improve stuff. Sometimes when you're in the trenches competent help arriving can be a godsend. Not saying this is your situation, but people may just be excited.
So much this.
I've been working on remote teams for almost 20 years. The key to success is overcommunicating. In other words--don't assume people have full context or share assumptions. Write emails that lay out assumptions explicitly and detail problems completely. As a manager I sometimes feel like a Habsburg bureaucrat buried in the Chancery offices sending painstaking messages to a far flung empire. Come to think of it, remote…
The other thing working remote forces me to do is to actually think before I assign a task to someone or ask a question. It's a lot easier to casually interrupt someone with half a thought than to write a poorly thought out email.
Earlier quoted context omitted.
That is also the main advantage of email over IM. Email kind of forces some effect of the remoteness you described even when everyone is in the same office.
On the other hand, in a colocated workspace it is infuriating when a high effort, carefully crafted email is met by recipients interrupting you at your desk with, "Hey, about that email, can you just quickly run through it with me now please?"
I've been working on remote teams for almost 20 years. The key to success is overcommunicating. In other words--don't assume people have full context or share assumptions. Write emails that lay out assumptions explicitly and detail problems completely. As a manager I sometimes feel like a Habsburg bureaucrat buried in the Chancery offices sending painstaking messages to a far flung empire. Come to think of it, remote…
Since we’re at the topic of eloquence, might I add that horribly-written codebases are unbearable to work with during this time, or perhaps even during regular times for as long as the set up is remote. I get it that codebases inevitably rot over time, but the amount of rot can be mitigated by good dev practices such as unit testing, code reviews, best-effort (not perfect!) documentation, and standardizing dev practi…
Yes, but things change over time, and there is rarely a chance to go back and refactor. Every time you introduce something new, or make some tech decision, it should be able to exist without needing to be re-written for a long time. If you are lucky enough to have some budget available for refactoring, it will probably be incremental, so choose choose things that can be adopted incrementally.
I wouldn’t say that this has been true in my experience. I’ve worked on multiple products that evolve over time and it often happens that a new feature touches on previously built features that can’t support all the behaviors of the new one, so then a refactor of the old code (at least some of it) is necessary. You can argue that doing so would require regression tests, but that’s why you automate those with a unit testing framework. This mindset of never modifying previously written code within reasonable and pragmatic boundaries is so rigid and anti-growth, I don’t even know how it came to be so popular within an industry that identifies so closely with innovation. That’s how you end up with putting band-aid solutions on top of each other and slowing down the agility of your teams over time.