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

171–180 of 205 posts

Re: Best practices for remote software engineering

#171

Post by bregma »

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

I strongly disagree. I spent years managing an all-remote team that was spread from Perth, WA to Seattle, WA (for different values of WA). It was a fantastically productive team.

It has been my experience that rarely do productive software developer depend on working with each other synchronously (is it the thinking that they share, or the typing?) and when they do, it's not hard to find a common time to meet between two timezones. It is also rarely necessary to meet together as a team on a very regular basis.

One catch is we would all meet face-to-face for a week two or more times per year. That was important for planning and socialization, but being apart was when 98% of the work was done.

Re: Best practices for remote software engineering

#172

Post by dec0dedab0de »

titanomachy wrote: post #135
dec0dedab0de wrote: post #116

Earlier quoted context omitted.

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

Fair enough. A doctor basically explained it to me like that over a decade ago, and I took their word for it. Which is uncharacteristic of me to just take someone's word for something, and repeat it.

Re: Best practices for remote software engineering

#173

Post by barbazoo »

selphy1 wrote: post #154
barbazoo wrote: post #72

Earlier quoted context omitted.

Midday showers are one of my favorite things about WFH.

You can do this in the office too, assuming it has an office gym

Been there, done that. Not the same. Unless your company is fancy I guess? I just have a really cozy bathroom with everything I need =]

Re: Best practices for remote software engineering

#174

Post by twh270 »

arvinsim wrote: post #128
mandeepj wrote: post #73

Earlier quoted context omitted.

> avoid 3 hours of writing unit tests Why? Unit tests are our closest allies

Just because something is important doesn't mean it is enjoyable.

I know this sounds like evangelism, but I absolutely hated writing unit tests until I learned TDD. Now, I don't always write tests first, but I usually do.

I'll also say that I have seen a lot of time wasted writing useless unit tests. That can contribute significantly to the "I hate unit tests" feeling.

Re: Best practices for remote software engineering

#175

Post by [deleted] »

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.

[deleted]

Re: Best practices for remote software engineering

#176

Post by solosoyokaze »

morelisp wrote: post #133
solosoyokaze wrote: post #36

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

I respect your opinion but have a different philosophy.

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

I’d argue that both of those are ok, and the former is even desirable. If you have a dev who wants to do that, they are usually quite good and you should embrace their creativity and productivity.

The vast majority of “deadlines” are completely artificial and don’t match the way great software is written (by inspired devs). So much value creation is the search for black swans. Great developers have the ability to make those if you optimize for it.

I could see an ad agency or something having deadlines, but personally I would never work in that environment as I prefer product work and maximizing creativity and individual contribution.

Re: Best practices for remote software engineering

#178

Post by beckingz »

msingle wrote: post #166
tikhonj wrote: post #103

Earlier quoted context omitted.

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…

I'm unsure if this is more your perceptions, the places that you've worked or a combination. Why do you phrase it as "public accountability ritual"? I'm sensing my definition for accountability is different than yours. I typically think of my comment at a standup as (small) opportunity to answer "what have you been working on?" once instead of if every member came by and asked in a friendly manner. I wouldn't be both…

I had a manager who would ask "is that all you're working on?" if you mentioned working on less than 3-4 unique tasks.

This incentivized breaking everything up into tiny tasks and getting things out the door instead of getting the right things done. It was not a good workplace.

Re: Best practices for remote software engineering

#179

Post by lostcolony »

beckingz wrote: post #178
msingle wrote: post #166

Earlier quoted context omitted.

I'm unsure if this is more your perceptions, the places that you've worked or a combination. Why do you phrase it as "public accountability ritual"? I'm sensing my definition for accountability is different than yours. I typically think of my comment at a standup as (small) opportunity to answer "what have you been working on?" once instead of if every member came by and asked in a friendly manner. I wouldn't be both…

I had a manager who would ask "is that all you're working on?" if you mentioned working on less than 3-4 unique tasks. This incentivized breaking everything up into tiny tasks and getting things out the door instead of getting the right things done. It was not a good workplace.

So, first, let me say that, yes, that sounds like a bad workplace.

Second, just to point out (I'm sure you realize, but just in the spirit of the parent comment), no agile workplace cares about the load of tasks dev has. Are they busy doing valuable work? If not, is there valuable work they could be doing? That's it. If yes to the first, no problem. If no to the first, and yes to the second, no problem, "hey, I've got something you can have a look at". If no to both, no problem, it's on product and management to work on getting some new work items.

Re: Best practices for remote software engineering

#180

Post by lkjlkj9 »

PoignardAzur wrote: post #156
treeman79 wrote: post #42

Earlier quoted context omitted.

So I have ADHD. Official diagnosis. My kids have it. Official diagnosis. My mom and sisters clearly have it, but refuse to be tested. If something is sufficiently interesting I can hyper focus like crazy. For decades any level of boredom was physically painful. Remote is the worse for me. Staying on task is a nightmare. What helped? Pair programming. This keeps you engaged and on task. I try and pair as much as possi…

Have you considered modafinil? It allegedly has fewer side-effects, but a similar effect as adderal.

I've been using it, finding it less useful for me than stimulant options but sometimes it can unstick a feeling of ADHD helplessness or "death spiral".
Post reply on HN