Live data from Hacker News

Best practices for remote software engineering

cacm.acm.org

41–50 of 205 posts

Re: Best practices for remote software engineering

#41

I feel like most engineers are pretty good at working remotely (c.f. all of open source). Managers however seem to have a very hard time adjusting. If I were to give some "best practices" for remote management, they would be: * Don't worry about how your reports are spending their time. If someone doesn't get back to you, they are busy. * Don't factor an employee's location into their compensation. * Minimize meeting…

>I actually think it might be nice for a company to provide a therapist for people to to privately talk to. That's always been a weird roll that managers often play. It would be interesting to break down what percentage of 1:1 time with employees is spent in therapy-like discussions. It feels like this role isn't recognized enough, except perhaps by the managers themselves.

Two great managers I've had both regarded this as one of their highest duties.

As an engineer, having someone above you in the chain of command who regularly asks things like "how are you feeling about work? Bad? Good? Are you stressed or content?" is a big deal. Even if the answer is a totally noncommittal "everything's fine" 99% of the time, that 1% is absolutely critical to be aware of.

Re: Best practices for remote software engineering

#42

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.

So I have ADHD. Official diagnosis. My kids have it. Official diagnosis. My mom and sisters clearly have it, but refuse to be tested.

If something is sufficiently interesting I can hyper focus like crazy.

For decades any level of boredom was physically painful.

Remote is the worse for me. Staying on task is a nightmare.

What helped? Pair programming. This keeps you engaged and on task. I try and pair as much as possible.

Medication. I was on Adderal for awhile. It works great. I had to stop due to serious side effects. (Strokes)

However it got me past the mental block of “boring is painful”

I function a good better without medication now. It’s not where it needs to be to cope with 8 hours of no human interaction, but better.

I tried another non stimulate med. my focus was fine, but I was so sleepy my work was crap.

I’m on Vyvanse now. My kids are on Vyanse.

It works a lot better.

I get some of the same side effects as adderall But not as intense.

Re: Best practices for remote software engineering

#43

Earlier quoted context omitted.

In my experience, pair and mob programming are just yet another scenario where neuro-atypical people are punished for approaching their work differently.

I just recently started working at a place where mob programming is commonplace. It is easily the most wasteful use of time I have ever seen in my professional career. 1.5hr session * 6 devs = 9 hours down the drain. Only one person can speak during a Zoom call! It's a single-threaded, low throughout, low latency communication medium. So it always ends up being one or two people talking - the one or two driving what…

I had an admob interview once. I don't understand why this would ever be used. It seems so costly, slow and disrespectful of everyone's time.

Re: Best practices for remote software engineering

#44

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.

Time management at home is a different ball game. A good first step is to understand what's fundamentally different about working from home, alone, versus working from the office. Some common differences: - Context shifting into the office can help context shift you to work mode. At home, if you use the same workstation for games and Reddit and work and entertainment, you lose the physical context shift. If possible,…

That accountability step is part of the intent for daily standups in most agile disciplines. The five minutes it takes for everyone to say what they worked on since the last one, what they plan to work on, and what obstacles they have, is great both for forcing people to focus a bit, as well as for managers to help point out when someone is stuck (i.e., "you've been working on that the past few days; is something wrong?")

Re: Best practices for remote software engineering

#45
post #39

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'm not sure if it's wise to publicly post this "taking advantage of that freedom and focusing instead on podcasts or reddit for 3 days to avoid 3 hours of writing unit tests."

At least he is honest and wants to change. Better than 99% of people out there.

Re: Best practices for remote software engineering

#46

Barking at the wrong tree. In my view, most experienced software engineers can self organise and self manage. Not saying everyone can or that everyone should do remote work but many that enjoy and prefer remote work can. “This Viewpoint is intended for remote software engineers who are facing new challenges to thinking about routine, responsibility, and goal setting.” This viewpoint should be intended for non technic…

Most software engineers are not experienced software engineers.

Hmm, is that true? Just from a numbers perspective, it seems like there would be far more experienced software engineers than brand new ones.

Re: Best practices for remote software engineering

#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.

Re: Best practices for remote software engineering

#48

Earlier quoted context omitted.

Time management at home is a different ball game. A good first step is to understand what's fundamentally different about working from home, alone, versus working from the office. Some common differences: - Context shifting into the office can help context shift you to work mode. At home, if you use the same workstation for games and Reddit and work and entertainment, you lose the physical context shift. If possible,…

That accountability step is part of the intent for daily standups in most agile disciplines. The five minutes it takes for everyone to say what they worked on since the last one, what they plan to work on, and what obstacles they have, is great both for forcing people to focus a bit, as well as for managers to help point out when someone is stuck (i.e., "you've been working on that the past few days; is something wro…

"Yes, I can't stop worrying about tomorrows standup and, as a result, I'm incredibly inefficient."

Re: Best practices for remote software engineering

#49
post #39

Earlier quoted context omitted.

I'm not sure if it's wise to publicly post this "taking advantage of that freedom and focusing instead on podcasts or reddit for 3 days to avoid 3 hours of writing unit tests."

At least he is honest and wants to change. Better than 99% of people out there.

Honesty doesn't replace accountability. Wasting three days is a long time to just be "procrastinating"

Re: Best practices for remote software engineering

#50
post #49

Earlier quoted context omitted.

At least he is honest and wants to change. Better than 99% of people out there.

Honesty doesn't replace accountability. Wasting three days is a long time to just be "procrastinating"

I can tell you've never suffered from ADHD.
Post reply on HN