Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Best practices for remote software engineering

cacm.acm.org

Post reply on HN
Print view View original

141–150 of 205 posts

Re: Best practices for remote software engineering

#141

Post by bit_logic »

anonytrary wrote: post #134
bit_logic wrote: post #118

The most important thing is the whole team being in the same time zone. Even a 1 hour difference is too much. That may seem extreme, but I've had so many important discussions happen around 5pm near end of day when everyone's done with their main task and meetings and have time to think about something else. Then they realize it's really important and need to chat right now. If the team is not in the same time zone,…

Displeased to see the best comment at the bottom. This is spot on. People will always get the most work done when synchronicity is able to be maximized!

I’m a bit surprised at the downvoting and wondering if there’s misunderstanding. To be clear, I’ve been working remote for years and fully support it. Physical location doesn’t matter. A team could have someone in a Bay Area house, someone in Bakersfield with farming as a side project, another living in a Tahoe cabin with Starlink and hiking everyday, another in Oregon living in the small town they grew up in. Remote is the future and allows wonderful quality of life. But note that these examples are all the same time zone. My comments are from experience, I’ve been on teams with mixed time zones. And the issues from mixed time zones are hidden and silent because no one wants to upset anyone. No one wants to tell the manager that Bob is nice but hard to work with because he’s never online when we need him. But that doesn’t mean the issues don’t exist. The best way to handle this is to never let it happen in the first place. If it’s already happened, the next best option is to refactor the teams by time zone, for example hire more in Bob’s time zone and form a new independent team in that zone.

Re: Best practices for remote software engineering

#142

Post by mjrbrennan »

gibrown wrote: post #38
philangist wrote: post #2

I was just having a discussion about this with my manager during 1:1. I'm curious how any fellow devs with ADHD have managed the transition to remote work over the last year? I love the freedom and ability to focus that working from home provides, but I often find myself taking advantage of that freedom and focusing instead on podcasts or reddit for 3 days to avoid 3 hours of writing unit tests.

A coworker of mine (our company has always been “remote”) has written a lot about ADHD and working remote. https://aaron.blog/?s=Work https://aaron.blog/2016/03/25/how-working-remote-probably-sa... is a good place to start.

That was a great read, thanks for linking!

Re: Best practices for remote software engineering

#143

Post by j4yav »

autora wrote: post #140
titanomachy wrote: post #105

Earlier quoted context omitted.

It's ok, although I have a tendency to wear myself out mentally when I take stimulant meds. Certain kinds of programming have a very high activation energy. In each programming session, it can take a lot of time (sometimes hours) before I've gathered enough context to start making progress on a problem. Once I start making progress my motivation is usually self-sustaining. Sometimes I can't focus long enough to get t…

I've been a programmer for 20 years and you just described my daily struggle with my job so precisely. Is this kind of experience happening to neuro-typical people or is this a very ADHD thing? I ask because I have often wondered if I am undiagnosed as something or other and this post hit me hard.

It is common with tasks requiring deep focus also in people without ADHD.

Re: Best practices for remote software engineering

#144

Post by jimmySixDOF »

tikhonj wrote: post #103
lostcolony wrote: post #99

Earlier quoted context omitted.

So as with everything agile, the process is -nothing- without the culture. You can't fix culture with process. If the culture is right, it's enabling. If the culture is wrong, it's patronizing. It's not intended to be a public accountability ritual; it's intended to make it so you're participating in setting the expectations of the team, and if you're not living up to them, the team looks to figure out how to better…

I'm sorry, a process that happens in front of your team so that they can judge whether you're "living up to expectations" is literally a public accountability ritual. You can't fix culture with (just) process, but process certainly affects culture. And this kind of process directly contributes to a culture where people are pressured based on how they work at an extremely finely grained level. Even if somebody is doin…

I understand the argument that most people don't implement Agile as it was intended, but I don't think it is an enabler of bad management practices any more than what would be implemented in it's place if you remove the Stand-ups and Backlogs. It's like what they say about Democracy being the worst system of government except for all the rest. Brittle teams who are not in it together with each other are going to be hard work whatever the organizational structure. The fact that situation is so normal is not the fault of Agile.

Re: Best practices for remote software engineering

#145

Post by vladojsem »

u801e wrote: post #126
vladojsem wrote: post #47

I believe asynchronous communication is the key for remote work. It is super-hard to learn and requires a trust, however, I find it the most efficient style of work. Of course there will still be some regular meetings / synchronous communication, but more asynchronous you can do more focus time remains.

I've really had a difficult time trying to get other team members to rely on asynchronous coummunication as opposed to video chat. Frequently, there are issues with video chat where the video or audio freezes and what was said doesn't get transmitted. Then there are issues where people don't precisely remember what was said during the meeting and it having to be repeated in chat.

yes, it requires a change in the mindset. we were also fighting with it at the beginning. but i work in a small company, cca 30 people, i guess it would be harder in a big company.

Re: Best practices for remote software engineering

#146

Post by tgaj »

titanomachy wrote: post #71
philangist wrote: post #2

I was just having a discussion about this with my manager during 1:1. I'm curious how any fellow devs with ADHD have managed the transition to remote work over the last year? I love the freedom and ability to focus that working from home provides, but I often find myself taking advantage of that freedom and focusing instead on podcasts or reddit for 3 days to avoid 3 hours of writing unit tests.

I stopped being able to get work done at all. It gradually tipped me into a low-self-esteem death spiral. I tried lots of different approaches to fix it: more accountability with my manager, new medication, more regular exercise, therapy, a bit of disability leave, even moved to a bigger apartment where I could have my own office. Nothing got me past the block. I quit my job, spent six weeks studying and interviewing…

Heh, same problem as ADHD developer. The one thing that was helping me was a custom in our company that we sit on zoom as much as possible. But, to be honest, I just got back to office as soon as it was possible in my country.

Re: Best practices for remote software engineering

#147

Post by tgaj »

j4yav wrote: post #143
autora wrote: post #140

Earlier quoted context omitted.

I've been a programmer for 20 years and you just described my daily struggle with my job so precisely. Is this kind of experience happening to neuro-typical people or is this a very ADHD thing? I ask because I have often wondered if I am undiagnosed as something or other and this post hit me hard.

It is common with tasks requiring deep focus also in people without ADHD.

I think for neurotypical people it is easier to create some kind of system/framework for being more efficient in work. Every solved problem add some mental tools to this systems. But it is much harder for ADHD because of how our brain works. Working step-by-step is hard for me. It is easier for me to load as much info to my brain RAM and try to digest it. And it is not something that you can get better in because it's not really a systematic method.

Re: Best practices for remote software engineering

#150

Post by tgaj »

cdogl wrote: post #97
tikhonj wrote: post #95

Earlier quoted context omitted.

This is why I find standups (and other ceremonies) patronizing and exhausting. It's like you have to publicly defend yourself and your work every single day. There's a massive difference between setting up accountability for yourself and having your manager/team/etc impose a public accountability ritual on you. Doubly so because it's usually billed as being about "visibility" or "alignment" or something else, as if i…

I couldn't agree more. The feeling you are describing is felt particularly acutely by individuals who are junior, or for one reason or another (low self esteem, flagging mental health, membership of a group that experiences disproportionate marginalisation in the workplace), and in my experience it subtly but profoundly warps developers' motivations and drives. Tasks can become all about rushing to get some progress…

I don't understand. Can't you say on stand-up that you are "patiently thinking problem"? You can try to explain how this process works for other team members and maybe they will learn something new. If you can't explain what you are doing maybe it's not as important as you think.
Post reply on HN