Live data from Hacker News

Best practices for remote software engineering

cacm.acm.org

21–30 of 205 posts

Re: Best practices for remote software engineering

#21
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 meetings (this is for non-wfh too, but it's much easier when people are remote).

* Allow people to leave their cameras off during calls.

* Don't worry so much about flying people to meet IRL. It's expensive and disruptive. It may also introduce politics that won't exist if everyone stays remote.

* Realize that a lot of what people think of as "management" is actually unneeded babysitting that's a vestigial cargo-cult from the industrial revolution. Your job is to hire, motivate and unblock. That's pretty much it.

I wonder if the role of manager will go away and be replaced with more specialized roles. 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 nice to vent to someone who doesn't get to decide your next raise. Between some level of HR outlet, product management and mentorship, I don't really see a dedicated role for what we now call "manager".

Re: Best practices for remote software engineering

#22

Earlier quoted context omitted.

Pair and mob programming

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

I won't say it's for everyone. But for ADHD specifically, my personal experience is that pair programming is a godsend. I am able to use half my regular dose of ritalin while pairing.

Re: Best practices for remote software engineering

#23

Earlier quoted context omitted.

Most software engineers become experienced software engineers (enough to self-manage) very quickly in the right environment, I've found.

Most software environments are not the right environment.

Excellent point. Small details about your working environment, or lack of a routine, can hugely throw off your workday, and thus your productivity. You should generally pay attention to the lighting, noise level, and comfort of a work space. If you find yourself distracted by anything, you might consider changing your environment. Habitual repetition by way of thinking about your environment or making explicit choices can lead to the establishment of longer-term habits.

Someone should write an article with that advice in it...

Re: Best practices for remote software engineering

#24

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 feel like most engineers are pretty good at working remotely (c.f. all of open source).

Most engineers are not on GitHub or any of the other social coding sites, let alone contributing to or managing an open source project. And anyone who is managing an open source project can tell you how much work it is to help other engineers contribute constructively.

Your idea of a managerial role doesn't seem to leave much room for technical or team leads, only "product management". Sometimes your role is to hire/motivate/unblock - and sometimes the motivational role is make sure someone spends those three hours writing unit tests everyone agreed were important even though no one wants to.

Re: Best practices for remote software engineering

#25

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.

There are a couple of things that allow me to get past these bottlenecks. First, let it go. Then do something else, get outside, have a cup of something. Instead of thinking about "3 hours of writing unit tests", start with "write just 1 unit test". Then get back and try to find something interesting about this depressing piece of work you need to do. Just one tiny thing, like "how fast does it take to run a test" or "how does this utility method is implemented". I do this a lot - trick myself into something small, and then let myself go with the same work, just like reading "one post in HN" leads me to write this response LOL.

In my case, it is just a pure absence of motivation and interest that causes the attention to go somewhere else. And this is all right, as it's a signal that the shit I do is not worth it. I have to make it worth it in some way, worth it for my soul sake.

Re: Best practices for remote software engineering

#26

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,…

This is amazing advice. Thank you.

Re: Best practices for remote software engineering

#28
post #19

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.

This (might) help you, It helped me anyways. https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

I often find myself looking at my website and trying to figure out what is the most important thing I have to work on right now.

But hours can pass by like this.

And I’ve learned that I need to start with something small. Even a tiny improvement/fix I spend my first 15 minutes on gets me going and into the flow state!

Re: Best practices for remote software engineering

#29

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 feel like most engineers are pretty good at working remotely (c.f. all of open source). Most engineers are not on GitHub or any of the other social coding sites, let alone contributing to or managing an open source project. And anyone who is managing an open source project can tell you how much work it is to help other engineers contribute constructively. Your idea of a managerial role doesn't seem to leave much…

Open source is just one example. In general I would say engineers work well in a quite place with no distractions and minimal bureaucracy. It is creative work after all.

> Your idea of a managerial role doesn't seem to leave much room for technical or team leads, only "product management". Sometimes your role is to hire/motivate/unblock - and sometimes the motivational role is make sure someone spends those three hours writing unit tests everyone agreed were important even though no one wants to.

I did include mentorship in my list of things needed to help engineers grow. I'd also add "everyone agreed" in a traditional management setting is pretty much identical to "the person who decides how much people get paid, said so". Good devs will typically write the appropriate amount of testing unprodded.

Re: Best practices for remote software engineering

#30

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.

Is that ADHD or are you just procrastinating? You clearly recognize the issue. Maybe try Screen Time limits or changing your hosts file

Procrastination/lack of executive function is a symptom of ADHD.
Post reply on HN