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

31–40 of 205 posts

Re: Best practices for remote software engineering

#31

Post by morelisp »

solosoyokaze wrote: post #29
morelisp wrote: post #24

Earlier quoted context omitted.

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

Engineers (and everybody else) like working in places with no distractions and minimal bureaucracy. But that doesn't mean they all work well them.

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

Absolutely no one on our team deciding what people get paid has any say in how many tests we write. The engineering manager has some say (mostly as a tie-breaker) in technical decisions but does not "decide" how much anyone gets paid (outside of salary range for new job postings), but can choose to advocate (or not) for a particular person's salary with higher management. The senior developers have the most say, and they determine no one's salary.

> Good devs will typically write the appropriate amount of testing unprodded.

Qualifying this with "good devs" somewhat begs the question. I would rather avoid judging the developers and just say, no, most developers will not typically write the appropriate amounts of tests by without some friendly reminders.

Re: Best practices for remote software engineering

#32

Post by TigeriusKirk »

solosoyokaze wrote: post #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 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.

Re: Best practices for remote software engineering

#33

Post by dragosmocrii »

What a great article! I specifically like the emphasis on the human touch, like showing empathy and trying to build a connection with the customer and the team, despite the remote aspect.

I also believe that correct use of communication media plays a huge role in the effectiveness of remote work. But personally, unlike the author, I believe that written communication is much better for remote teams. Shameless plug, I've wrote an article specifically on the topic of communication for remote work https://dragoshmocrii.com/remote-work-and-efficient-communic...

Re: Best practices for remote software engineering

#34

Post by bradstewart »

sublimefire wrote: post #25
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.

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…

Agreed. Creating small, achievable tasks to start my day gives me some easy "little victories" which provide some confidence to tackle harder problems. Often tiny things like "send an email to X" or "write JIRA ticket for Y".

Sounds stupid, but it really tricks my brain into not procrastinating on the more important tasks.

Re: Best practices for remote software engineering

#35

Post by edabobojr »

jacques_chester wrote: post #22
edabobojr wrote: post #12

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

I am glad it works for you. Maybe (hopefully?) I have just had an abnormal experience.

Re: Best practices for remote software engineering

#36

Post by solosoyokaze »

morelisp wrote: post #31
solosoyokaze wrote: post #29

Earlier quoted context omitted.

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

Engineers (and everybody else) like working in places with no distractions and minimal bureaucracy. But that doesn't mean they all work well them. > 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". Absolutely no one on our team deciding what people get paid has any say in how many tests we write. The engineering…

> Engineers (and everybody else) like working in places with no distractions and minimal bureaucracy. But that doesn't mean they all work well them.

I don't think evidence exists to suggest they don't. From a burnout perspective alone, making people work in an environment they don't like will cause attrition. Especially now that there are plenty of WFH options. That's not even touching on how stress impacts creativity.

> Qualifying this with "good devs" somewhat begs the question. I would rather avoid judging the developers and just say, no, most developers will not typically write the appropriate amounts of tests by without some friendly reminders.

Our personal experiences are diametrically opposed to each other then. I've never seen lack of tests be an issue on any team I've worked with. I have however seen unproductive teams create tests in place of being productive.

Re: Best practices for remote software engineering

#37

Post by whateveracct »

edabobojr wrote: post #12
brotherofsteel wrote: post #3

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 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 is being mobbed on.

Due to this, I try to only jump in when I have something valuable to add. Which isn't often given the situation I described. If I'm driving or directly involved with the design or w/e of the mob session's focus .. sure of course I'll talk. But I'm not going to sit around trying to get a fluffy word in edgewise for 90 min just for its own sake.

And yet a frequent driver of this mob culture (a "principal" engineer if you can believe it) loves to mention how I'm not "engaged."

??? I sit in your dumbass meetings and pay attention for 90 minutes! My time is 100% focused on the meeting!

Re: Best practices for remote software engineering

#38

Post by gibrown »

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.

Re: Best practices for remote software engineering

#39

Post by nomy99 »

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'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."
Post reply on HN