4 ms·
Our company has been fully remote for 3 years now and I don't think most programmers are capable of remote work. Poor communication, inconsistent work schedules
by meritt 9y ago
Our company has been fully remote for 3 years now and I don't think most programmers are capable of remote work. Poor communication, inconsistent work schedules, spending way too much time down rabbit holes that would have been avoided if we were in the same office, and generally not delivering the desired results on a reasonable timeline. In the past 5 hires, we had one employee who actually was a solid remote worker.
I'd love to a) know how to recruit good remote-capable employees and b) how to better manage remotely -- because at this point, we're going to open an office and hire locally.
Interstate taxation, necessary corporate filings/fees/forms, and offering healthcare in multiple states also make being fully remote incredibly difficult unless to restrict employees to being "remote" from the states in which you're already established.
- mark212 9y agothere are a few hundred people at Wordpress.com and Automattic that would beg to differ. Give a read to "Year Without Pants," it's very interesting and might help your team make the transition.
- mring33621 9y agoI don't understand this. I have worked remote and semi-remote for several years at large and small US companies, with internationally distributed teams. Generally, we have run loose SCRUM/agile processes with good results. There is really nowhere to hide. Either the bug is fixed or it's not. The new feature is there, or it's not! You make stories/tickets. You run sprints. You check in code. You see passing or broken builds. You demo to customers or management that serving as proxies for customer interest. There is much imperfection in our processes, but basic visibility is good. The stakeholders can see Jira, Github, Jenkins/Teamcity. The devs cannot hide, so the work gets done.
- shitgoose 9y agoi guess it depends on the project. if business side is not too complex and can easily be translated into jiras and stories, then developers should have a good grip on what needs to be done and why. then remote is fine. but if business requirements, on the other hand, are complex, poorly understood or fluid, then developer will be absolutely lost and will start cranking up patterns instead of solutions. teamcity will be building alright and scrums will roll, but project will be a complete mess heading for a disaster. face to face will not save the day, but to some degree will mitigate lack of communication and understanding of common goal.