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

101–110 of 205 posts

Re: Best practices for remote software engineering

#101

Post by heroHACK17 »

flir wrote: post #100
titanomachy wrote: post #71

Earlier quoted context omitted.

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…

If you don't mind me asking, how did you find programming on meds? I can't do it.

Not OP, but I have ADHD and would love to chime in here. I love programming on meds and I hate programming on meds. Meds connect the dots, but meds also over-engineer everything. Then the meds wear off and I am stuck with a huge solution and I have no idea what I just did.

Re: Best practices for remote software engineering

#102

Post by picobread »

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 struggling. When we were in the office there was still some semblance of normality. Particularly in 2021 my productivity has plummeted. I'm considering leaving this field altogether and have started applying for other jobs. At least with a physical job I can do the task at hand. I don't think I can be a successful developer with ADHD and I refuse to take meds full time. If anyone has figured out a solution to their own problems I'm all ears.

Re: Best practices for remote software engineering

#103

Post by tikhonj »

lostcolony wrote: post #99
tikhonj wrote: post #95

Earlier quoted context omitted.

This is why I find standups (and other ceremonies) patronizing and exhausting. It's like you have to publicly defend yourself and your work every single day. There's a massive difference between setting up accountability for yourself and having your manager/team/etc impose a public accountability ritual on you. Doubly so because it's usually billed as being about "visibility" or "alignment" or something else, as if i…

So as with everything agile, the process is -nothing- without the culture. You can't fix culture with process. If the culture is right, it's enabling. If the culture is wrong, it's patronizing. It's not intended to be a public accountability ritual; it's intended to make it so you're participating in setting the expectations of the team, and if you're not living up to them, the team looks to figure out how to better…

I'm sorry, a process that happens in front of your team so that they can judge whether you're "living up to expectations" is literally a public accountability ritual.

You can't fix culture with (just) process, but process certainly affects culture. And this kind of process directly contributes to a culture where people are pressured based on how they work at an extremely finely grained level. Even if somebody is doing top-notch work and having real impact long-term, if they're not making legible progress day-to-day, Agile is going to make them look bad and feel bad. The process itself emphasizes consistency and incremental work while deemphasizing individual flexibility and agency.

Now, perhaps some teams have a culture that's strong and accepting enough to compensate for this and provide a great environment for people who work in different ways, but if that's the case it's despite the process, not because of it. I've never seen that myself though.

Re: Best practices for remote software engineering

#104

Post by mavelikara »

lolinder wrote: post #94
mavelikara wrote: post #92

Earlier quoted context omitted.

The Oreilly library access alone is totally worth the price of ACM membership.

Is the Oreilly access that comes with the ACM membership full access? The same level of access you'd get for $500/yr from Oreilly directly?

I think so, although I am not sure.

Re: Best practices for remote software engineering

#105

Post by titanomachy »

flir wrote: post #100
titanomachy wrote: post #71

Earlier quoted context omitted.

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…

If you don't mind me asking, how did you find programming on meds? I can't do it.

It's ok, although I have a tendency to wear myself out mentally when I take stimulant meds.

Certain kinds of programming have a very high activation energy. In each programming session, it can take a lot of time (sometimes hours) before I've gathered enough context to start making progress on a problem. Once I start making progress my motivation is usually self-sustaining. Sometimes I can't focus long enough to get to that point, and in that case the stimulants do help.

However, I also become very reluctant to take breaks and lose the context I've built up, so I often end up working quite late. I feel exhausted and sort of disoriented sometimes after these sessions. I can't do days like that too often without sacrificing health, relationships, etc.

In 2020, meds didn't help me at all. I just ended up being really focused on some useless distraction or cleaning my house or whatever. My problem was more fundamental than "I can't focus long enough to build up self-sustaining momentum."

What don't you like about programming on meds?

Re: Best practices for remote software engineering

#106

Post by lostcolony »

tikhonj wrote: post #103
lostcolony wrote: post #99

Earlier quoted context omitted.

So as with everything agile, the process is -nothing- without the culture. You can't fix culture with process. If the culture is right, it's enabling. If the culture is wrong, it's patronizing. It's not intended to be a public accountability ritual; it's intended to make it so you're participating in setting the expectations of the team, and if you're not living up to them, the team looks to figure out how to better…

I'm sorry, a process that happens in front of your team so that they can judge whether you're "living up to expectations" is literally a public accountability ritual. You can't fix culture with (just) process, but process certainly affects culture. And this kind of process directly contributes to a culture where people are pressured based on how they work at an extremely finely grained level. Even if somebody is doin…

It's in front of the team so that obstacles can be solved by the team. It's why it's not in front of people outside of the team. The number of times where someone says "I'm struggling with X" and someone else says "Oh! I know about X! I can help!" has been innumerable.

And, it really doesn't contribute to a etc. I've had devs spend days with basically the same status, but it also was a large task. I've had devs make incremental progress, and everyone understood. I've had devs (and been a dev!) who said "I got nothing done; I was in meetings and they drained me", and it's fine (though it helps highlight that the meetings are too much very early).

The process presumes culture. It assumes the team functions together and is aligned in delivering, and isn't looking to blame one another. If the culture is bad, then, as with any bad culture, it's easy to blame the process.

Re: Best practices for remote software engineering

#107

Post by lostcolony »

codingdave wrote: post #20
lostcolony wrote: post #14

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.

100%, but the fix, then, is the environment. Not the developer.

Re: Best practices for remote software engineering

#108

Post by alberth »

Async communication = email overload?

Now I’m the first to say I find synchronous communication (eg Slack) to cause massive productivity loss for an organization & can also cause employee burnout … but how do companies that have a culture of async communication not fall into a similar bad issue of email overload?

Re: Best practices for remote software engineering

#109

Post by brown9-2 »

alberth wrote: post #108

Async communication = email overload? Now I’m the first to say I find synchronous communication (eg Slack) to cause massive productivity loss for an organization & can also cause employee burnout … but how do companies that have a culture of async communication not fall into a similar bad issue of email overload?

what makes you think that Slack must be synchronous and that asynchronous == email?

Re: Best practices for remote software engineering

#110

Post by alberth »

brown9-2 wrote: post #109
alberth wrote: post #108

Async communication = email overload? Now I’m the first to say I find synchronous communication (eg Slack) to cause massive productivity loss for an organization & can also cause employee burnout … but how do companies that have a culture of async communication not fall into a similar bad issue of email overload?

what makes you think that Slack must be synchronous and that asynchronous == email?

I’m curious now, what would you view then as examples of both synch and async communication?
Post reply on HN