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

131–140 of 205 posts

Re: Best practices for remote software engineering

#131

Post by honkycat »

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 struggle in meetings, always have. Ive found i have to slow people down in meetings and have them repeat themselves a lot, and I will repeat back to them what they are saying because I easily miss a lot.

I keep a list of tasks in a notebook and take the time to break them down and make sure I check them off.

I take a nap when I need one, take a break occasionally. Keeo the task ritual going. I always get my work done on time.

Re: Best practices for remote software engineering

#132

Post by mch82 »

mavelikara wrote: post #92
znpy wrote: post #88

Since we're commenting a piece from the ACM: would you people recommend an ACM membership subscription and reading the communication of the ACM magazine? What if you're not directly a software engineer but more like a system engineer / system administrator / DevOps engineer?

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

Nice tip!

Re: Best practices for remote software engineering

#133

Post by morelisp »

solosoyokaze wrote: post #36
morelisp wrote: post #31

Earlier quoted context omitted.

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

There's a wide range between "burn out" and "had to do something I didn't want to at work today", just like there's a wide range between "my manager's bugging me every 30 seconds on slack" and "why can't I just write the whole feature from my one-sentence description heads-down for 3 weeks and then put up 5k lines at once for code review?" A lot of otherwise-competent developers will do the latter if you don't force them otherwise. (Way more common even among developers skilled at time management: Getting caught up in a bug for X days and not asking for help.)

One view is of course that these are not "good developers" and you should not hire them or work with them. Two better views are that these are developers that need to learn a new skill to be even more effective and this will take time and someone pushing to actively learn it; or that even if they don't ever learn it, they can still be effective at their job when supported by a more active manager. (And a critical piece of advice for managers - that doesn't mean you need to be more active for everyone else on the team at the same time.)

I have worked on teams closer to as you have described, but I would say that's on a separate axis from functional/dysfunctional - it's very easy to get a team of insular divas - or even sustainable/non-sustainable - developers can build the perfect thing on schedule which no one will want to pay for, which a heavier-handed product-focused manager might have prevented.

I do think people who can self-organize are also very good at self-selecting into similar groups. This can result in the illusion that developers are much more effective at this than they believe. Two decades of free money and easy job-hopping resulting in no consequences for bad decisions also helps maintain that illusion - for bad managers also.

Re: Best practices for remote software engineering

#134

Post by anonytrary »

bit_logic wrote: post #118

The most important thing is the whole team being in the same time zone. Even a 1 hour difference is too much. That may seem extreme, but I've had so many important discussions happen around 5pm near end of day when everyone's done with their main task and meetings and have time to think about something else. Then they realize it's really important and need to chat right now. If the team is not in the same time zone,…

Displeased to see the best comment at the bottom. This is spot on. People will always get the most work done when synchronicity is able to be maximized!

Re: Best practices for remote software engineering

#135

Post by titanomachy »

dec0dedab0de wrote: post #116
esperent wrote: post #112

Earlier quoted context omitted.

As a person without ADHD that sounds weirdly similar to my experience of studying or coding on amphetamines (from brief experiments in college that I quickly decided were not worth it). Is there actually any difference between ADHD meds and speed?

Depends on the meds, but Adderall is a combination of different amphetamines and dextroamphetamines. Some of which are added just to make it uncomfortable if you take too much. The greatly simplified idea is that people with adhd have trouble using parts of their brain at the time they need to. So by increasing all brain activity the parts that are normally diminished are about normal. The side effect is that all the…

This isn't quite right. Adderall is a 3:1 mixture of dextroamphetamine and levoamphetamine. These are different enantiomers (configurations) of the amphetamine molecule. The two molecules have subtly different effects in the body, but as far as I know, neither is added to "make it uncomfortable if you take too much".

Re: Best practices for remote software engineering

#136

Post by stanboyet »

ketzo wrote: post #41
TigeriusKirk wrote: post #32

Earlier quoted context omitted.

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

Two great managers I've had both regarded this as one of their highest duties. As an engineer, having someone above you in the chain of command who regularly asks things like "how are you feeling about work? Bad? Good? Are you stressed or content?" is a big deal. Even if the answer is a totally noncommittal "everything's fine" 99% of the time, that 1% is absolutely critical to be aware of.

Thank you for your message. I recognize myself in the "regarded this as one of their highest duties", but sometimes it's a lot, especially when you get your own thing going (covid and such).

So thank you. I feel appreciated for the effort I put in this, even though we don't know each other :)

Re: Best practices for remote software engineering

#137

Post by titanomachy »

pa7ch wrote: post #120
titanomachy wrote: post #105

Earlier quoted context omitted.

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

Just wanna say I relate strongly to these posts. Sometimes it just feels like i'm trying everything to manage my motivation and adhd and it just doesn't work and I just gotta breath get outside and be unproductive for awhile.

I hear you.

If you otherwise like your job and the people you work with, then I think it's good to just accept that some days you won't get work done and that's ok.

If you feel that way all the time, maybe it's time to find work that you care about more.

Re: Best practices for remote software engineering

#138

Post by legulere »

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.

It’s important to have a good working environment with clear boundaries between work and private:

- Work starts at a certain point and ends at a certain point with a pause or pauses.

- Only work happens on the work computer, no work happens on the private computer.

- Keep private distractions away when you work (put your phone in another room)

Re: Best practices for remote software engineering

#139

Post by joshxyz »

u801e wrote: post #126
vladojsem wrote: post #47

I believe asynchronous communication is the key for remote work. It is super-hard to learn and requires a trust, however, I find it the most efficient style of work. Of course there will still be some regular meetings / synchronous communication, but more asynchronous you can do more focus time remains.

I've really had a difficult time trying to get other team members to rely on asynchronous coummunication as opposed to video chat. Frequently, there are issues with video chat where the video or audio freezes and what was said doesn't get transmitted. Then there are issues where people don't precisely remember what was said during the meeting and it having to be repeated in chat.

> Then there are issues where people don't precisely remember what was said during the meeting and it having to be repeated in chat.

In my experience that's crucial, after meetings there must be a short summary of what was discussed and decided, what are the next steps for everyone, and what they need to report on, and when are those expected.

There are times we ditch video too and go audio-only if it's really important, otherwise things are only discussed in chat. When working with people in other timezones that's where async chat communication really shows its value.

Re: Best practices for remote software engineering

#140

Post by autora »

titanomachy wrote: post #105
flir wrote: post #100

Earlier quoted context omitted.

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

I've been a programmer for 20 years and you just described my daily struggle with my job so precisely. Is this kind of experience happening to neuro-typical people or is this a very ADHD thing?

I ask because I have often wondered if I am undiagnosed as something or other and this post hit me hard.

Post reply on HN