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

71–80 of 205 posts

Re: Best practices for remote software engineering

#71

Post by titanomachy »

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 stopped being able to get work done at all. It gradually tipped me into a low-self-esteem death spiral. I tried lots of different approaches to fix it: more accountability with my manager, new medication, more regular exercise, therapy, a bit of disability leave, even moved to a bigger apartment where I could have my own office. Nothing got me past the block.

I quit my job, spent six weeks studying and interviewing aggressively, and got hired for a higher-level position at a different company. I pushed back my start date enough that I'll onboard in an office instead of remotely. In the meantime I'm working on my health and personal projects, and spending lots of time with friends and in nature.

I gave up trying to work remotely this time around, but I'm still hopeful that at some point I'll improve my coping skills enough that it will be an option.

Re: Best practices for remote software engineering

#73

Post by mandeepj »

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.

> avoid 3 hours of writing unit tests

Why? Unit tests are our closest allies

Re: Best practices for remote software engineering

#74

Post by titanomachy »

nomy99 wrote: post #57
weird-eye-issue wrote: post #50

Earlier quoted context omitted.

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.

Most knowledge workers are paid for impact, not hours worked.

If your results-based performance is deemed adequate, that means either the company is getting good value for the money they pay you, or they have a broken performance management system.

ADHD doesn't really factor into it. If ADHD leads an employee to have subpar performance, they will be fired just like anyone else.

Caveat: the best companies think like this. Most don't.

Re: Best practices for remote software engineering

#75

Post by sodapopcan »

ipaddr wrote: post #43
whateveracct wrote: post #37

Earlier quoted context omitted.

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.

It's slow at the beginning, but the payoffs are huge. With mobbing, everyone knows how to do everything. Far less design mistakes are made. No one ends up "owning" certain parts of the system. It's also very humbling as everyone succeeds and fails together, discouraging "heroics". Pairing is also great for this (but you have to switch every day).

Obviously, if you're working in a feature factory, pairing and mobbing are pointless. If you care about code quality and de-siloing, they're incredibly valuable.

Obviously, it's not for everyone, but it works incredibly well where I work and I will never accept another job that doesn't encourage pairing by default.

Re: Best practices for remote software engineering

#76

Post by wnevets »

notJim wrote: post #46
morelisp wrote: post #11

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.

According to Robert Martin 50% of developers at any given time have less than 5 years of experience. [1]

[1] https://youtu.be/ecIWPzGEbFc?t=3055

Re: Best practices for remote software engineering

#77

Post by sodapopcan »

wernercd wrote: post #61
edabobojr wrote: post #35

Earlier quoted context omitted.

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

I'd say I can get behind pair-programming to a point... it helps get new ideas, different view points and leads to rubber-duck-programming like effects. I'm not sure I'm a fan of Mob programming... as others mention, over a phone/video conference, it seems inadequate. Turns more into an ad-hoc video lesson by the stronger personalities (for better or worse - I happen to be one of those in my small group at work). Do…

To do mobbing effectively you should be switching the driver very rapidly. It's a bit tough remotely, but it can be done. There are probably other ways to make it effective, but if only a few people are contributing, then the mob has failed and should either be recalibrated or stopped altogether.

Re: Best practices for remote software engineering

#78

Post by PragmaticPulp »

deckard1 wrote: post #51
lostcolony wrote: post #44

Earlier quoted context omitted.

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…

Standups can help close the short-term feedback loop, but they don't replace long-term management involvement. Teams with standups still need proper performance management and performance reviews from a hands-on manager, along with clear communication of goals and expectations.

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

If important things are missing from the board, that's a problem with the planning process.

It's easier than it sounds to simply put those things up on the board. If engineers realize something important is not on the board, they need to get it up on the board. Communication needs to go both ways in planning sessions.

Re: Best practices for remote software engineering

#79

Post by David »

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

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

As an alternative to a daily chat message, a teammate and I have been meeting for ~15 minutes at the end of the day to talk about what we did and how productive we were. It's been pretty helpful a few different ways. First, it forces me to think about what it is I'm supposed to be doing and figure out the next step. Not knowing how to approach my next task is a huge cause of procrastination for me. Second, it's a chance to notice when I've gone astray, and identify factors that lead to low productivity. (Like that I procrastinate when I haven't broken down my next task into small enough pieces.)

I think for this to work well, it needs to be with someone you don't feel the need to impress. Maybe you have a teammate you trust like that, or maybe you can find a coworker on a different team who doesn't impact your performance assessments. If you have that, this feels different than a standup. Standups easily devolve into signaling to the team that you've done work. Instead, a 1:1 meeting with a coworker who you don't feel the need to impress makes it way easier to be vulnerable and admit when you screwed around on the internet for a lot of the day.

Re: Best practices for remote software engineering

#80

Post by jwdunne »

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 have quite the story.

I was terrified I wouldn’t be able to focus. Terrified I’d get distracted by home life. That my productivity would plummet.

But it didn’t happen. In fact, the opposite. I never realised how much commuting and office noise harmed my productivity and energy levels. I was buzzing.

And I did what any ADDer would do.

I got drunk on it. Then burnt out.

In typical ADHD fashion, I thought all that new energy was permanent and I could work insane hours. Sometimes from 7am until 1am.

I was warned. But I didn’t listen - not to my mrs, not to my old man, my sister and colleagues.

And then, once the dust of lockdown settled, I burst.

After making damn sure that the company I worked for and my sisters business didn’t go bust, I couldn’t anymore.

The code I wrote only a few weeks before? Hieroglyphs. But not that I’d lost understanding. I knew I could read it if I wanted to.

But I really didn’t want to. Like my very being rejected any attempt to focus on the task at hand.

I was reduced to attending scrums. And playing video games.

It took a weekend away, a week off and a bit of advice from Dr Feynman.

Thankfully, work was understanding. I was given a project where I could play, and still deliver value. And so I played, got something small done. Then I played some more. And so on.

Now, a colleague works on the project with me. I played so much that I was prone to rabbit holes. My hyperfocus was out of tune.

But then I took stock and was able to focus. We found a way forward, took some advice, got speaking to the users and focused development on fast iteration and feedback.

The past few months have been the most productive of my life. All remote.

I learned a lot of hard lessons in lockdown. The lessons I could not predict.

Post reply on HN