Live data from Hacker News

Best practices for remote software engineering

cacm.acm.org

51–60 of 205 posts

Re: Best practices for remote software engineering

#51

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…

The flip side of this is what I would term standup-driven-development.

You work just enough to have something to say that day. Rinse and repeat for the next day. The incentive isn't to do more or better work. The incentive is to have something impressive to say at the next meeting.

The other issue with standups is if it's not "on the board" then developers are disincentivized from doing certain things (proper testing of code, code reviews, etc.) in favor of things that show up.

Re: Best practices for remote software engineering

#52

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…

Think of it as a chance to pick up editor and language tricks you might not have known, or to socialize "best practices". The metagame is still part of the game. If you can't change the practice, try to make the most of it.

Re: Best practices for remote software engineering

#53
post #46

Earlier quoted context omitted.

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.

There would be far more experienced software engineers than brand new ones if the field was stable, but it has been growing exponentially for years.

The answer to the original question depends on the rate of growth, how you define more experienced, etc. So it's not obviously true or false.

Re: Best practices for remote software engineering

#54

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

I used to live in a commercial building (the only living space) that had a separate office suite. When in the office doing billable hours sorts of things, 0% of time was spent on non-work issues. Work computer = a big honkin' loud workstation. Home computer = a laptop.

It wasn't too hard a discipline to keep, I think it helped a lot to use physically different space and hardware.

Re: Best practices for remote software engineering

#55

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…

Being a junior previously I derived a lot of benefit from light pair coding every now and then to learn something from a more senior developer. I have also been in code reviews where 2+ people are of equal relative skill, but have different approaches to a problem, and it almost becomes a stalemate or some kind of power struggle to 'be right'. 6 devs seems very excessive and an expensive use of time heh.

Re: Best practices for remote software engineering

#56

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 don't think you're going to find the best time management tips from people who are on Hacker News in the middle of a Monday afternoon.

Re: Best practices for remote software engineering

#57
post #49

Earlier quoted context omitted.

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.

So you are telling me a person suffering from ADHD is not accountable for the $ lost in productivity. If I had ADHD, just for survival, I wouldn't ever let my boss know that I have this condition which is costing his company X amount of dollars a year.

Re: Best practices for remote software engineering

#60

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.

ADHDer here. WFH was a nightmare the first six months, but the past few months have been working out great. My findings from this past year:

* Finding the right medication, in the right dose. Biggest QoL improvement. YMMV

* Whenever I get lost in the sauce and start spinning my wheels, I schedule a call with a colleague and ask them to help sort my priorities out. This also helps me with accountability, in a softer way than accountability-by-authority. This might require some self-awareness.

* Finding a note-taking/task management system that works for me. So far, I've been having the most success with a combination of Roam Research; Apple Notes and Muse for drawing/diagramming on my iPad; and Todoist for hard reminders.

* Getting enough physical activity. My headspace becomes awful if I don't get at least 30 minutes of walking in during the day.

* Finding my context shift to work mode. Most days, 15 minutes outdoors first thing in the morning after checking my task list is enough. For rougher days, I work from the café down the street.

* Avoiding social media before lunch, as it stresses me out.

* I found the eureka moments striking at odd times, like evenings or in bed. I rarely regret following these strokes of inspiration, but they can really throw my off my work/life balance. Cutting my days shorter (most days), and allowing myself to work when inspiration strikes (a couple times a week), has really helped in lowering my stress levels.

* A couple days a week without scheduled meetings. I can't focus if I know I'm going to have a meeting in 1 hour.

* Splurging on equipment. If I'm going to spend a lot of time in front of my screen, I might as well get that 4K 32" and a G915 TKL.

Post reply on HN