Live data from Hacker News

Best practices for remote software engineering

cacm.acm.org

11–20 of 205 posts

Re: Best practices for remote software engineering

#11

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.

Re: Best practices for remote software engineering

#12

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.

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.

Re: Best practices for remote software engineering

#13

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, try using your company-provided computer for only work, and your personal computer for only play. Even better if you can have them in different rooms. Start training yourself to associate one context with work, and one context with not-work. When you sit down in the work context, it's time to work.

- Accountability can feel lessened when no one can see over your shoulder. This can be misleading in the short term because it's easy to get away with it for a while: You can tell people you ran into unexpected difficulties, or you had to spend time on something else, or any number of excuses that work in the short term. Over the long term, the productivity difference starts to show up in your output relative to peers, so avoid falling into this trap. If your company isn't big on short-term accountability, give yourself some daily accountability. A good practice would be to write a short message to your team's Slack channel with what you're going to be working on for the day. At the end of the day, write a short summary of what you accomplished. Once this is routine and public (within your team) you will feel some of the same accountability you did when your team was sitting in the same room and could see you working (or not).

- Offices provide a lot of social exposure that we take for granted. Slack and Zoom can't fully replace it. Make sure you get out of the house and see other people routinely, even if it's just walking around the neighborhood. Simply seeing other, real human beings goes a long way.

- Track your time. Entering the office in the morning and leaving in the evening are natural delineators for your work day. Try to have some similar start and end times at home. Consider using something like RescueTime so you can see where your time is going during the day.

Re: Best practices for remote software engineering

#14

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.

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

Re: Best practices for remote software engineering

#15

Earlier quoted context omitted.

Most software engineers are not experienced software engineers.

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

That's probably survivor's bias and not true at scale. "Right environment" is shaky - we should strive towards defining what makes an environment the "right" one and how can we increase the number of engineers that successfully acclimate to their new way of working.

Re: Best practices for remote software engineering

#16

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…

I think its pretty clear there are problems on both sides. Managers need to learn the correct approach to facilitate acclimating their team to remote work but each individual also could improve how they work so that remote settings are more optimal. Nothing is so black and white.

Re: Best practices for remote software engineering

#17

Earlier quoted context omitted.

Most software engineers are not experienced software engineers.

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

I disagree (my anecdotal estimate would be around 1/3 do quickly, and 1/3 do "slowly" i.e. within 3-5 years), but those who do can still accelerate the process by reading documents like this, no? People who can self-teach still benefit from learning materials.

Re: Best practices for remote software engineering

#18
post #7

Earlier quoted context omitted.

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

Aren't these synonyms?

No, far from it. The pop culture definition of ADHD has become extremely vague and watered down, almost to the same degree that "OCD" has become a pop-culture term for attention to detail.

Procrastination is a common behavior in people with and without ADHD. Procrastination alone is not an indicator of ADHD.

Likewise, someone who procrastinates does not fully understand the struggles of someone with ADHD.

Re: Best practices for remote software engineering

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

Re: Best practices for remote software engineering

#20

Earlier quoted context omitted.

Most software engineers are not experienced software engineers.

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