Live data from Hacker News

Best practices for remote software engineering

cacm.acm.org

161–170 of 205 posts

Re: Best practices for remote software engineering

#161

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.

Counterpoint: having a tricky conversation one. Jira. Comment. At. A. Time. can be comically slow and inefficient.

Re: Best practices for remote software engineering

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

Thanks, I resemble all those statements, and I've often wondered if I'm undiagnosed ADHD. My occasional brushes with modafinil... well, sometimes it works, and sometimes it turns me into the best damn house cleaner on the planet.

In my brief experience of SSRI drugs, they left me fuzzy and unable to concentrate. Like baby brain without the baby.

Re: Best practices for remote software engineering

#163

Lots of whiteboards. Clean, tidy desk. No visible cables. Sunlight. Fresh air. Caffeine

> No visible cables

I've been looking into this for a while and I'm always kind of jealous of people who manage to hide all their cables. When looking at tutorials, even advanced, on cable management, the people's setups are often so minimal to start with... Do you have any resources on how to properly cable manage a setup that is not trivial?

Re: Best practices for remote software engineering

#164

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 disagree, for the past 4 years, I've worked in remote teams that were across different timezones and different countries. There are days were half the team is offline because it's a holiday in their country, and it doesn't really impact our team. We know that some people will have a day off, and that's fine, we don't bother them, and nobody expects them to be online. Same with timezone differences, it's generally u…

In my last team we had some people in Israel which has a different weekend! And we managed fine. Totally agree about 'right now'.

Re: Best practices for remote software engineering

#165

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…

Strange tip, I use to do part time local delivery. It made my brain cool off (safe regular activity, simple money, low skills). In between deliveries I often wrote small bits or small feature branches. I found it a good balance. It also made me think differently because I'd favor changes that were high ROI. No large design, no syntactic change. Only solid and valuable additions. Something I never really felt before.

Re: Best practices for remote software engineering

#166

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…

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 bothered by them asking individually, and it saves me repeating the answer.

I've never heard the phrase "isn't living up to expectations" related to stand ups. Do you (or places you've worked) normally have those related? I'm not sure I understand.

Why do you think it's "in front of your team" as opposed to "with your team"?

I, and other people I've worked with, have never been bothered by saying "still working on the same hard task" for _weeks_. If anything, I usually hear encouraging comments; "it sucks that the task is so difficult", "anything I can do to help you out?", "I'm surprised you haven't gone crazy from that", etc.

The places I've worked at aren't even great at agile, but I've never seen the process directed towards some of the things you're saying.

Re: Best practices for remote software engineering

#167
The first is the big one for me: Work on things you care about.

If I'm engaged with a project because it's intellectually stimulating and/or just plain "cool", I'm going to be 10x more productive working remotely than I ever would be in an office. In fact, unplugging and not overworking myself becomes an issue in such a situation.

OTOH, if I hate what I'm working on, remote work makes it way too easy to procrastinate and slack off. If I'm in the office, management would be able to identify me as being unhappy and target me for termination :D You can coast working remotely an hour a day on an easy but painfully dull project for a long time.

Re: Best practices for remote software engineering

#169
post #53
post #46

Earlier quoted context omitted.

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.

> it has been growing exponentially for years

Hardly. At best it can be described by a second-order differential equation. An experienced engineer would avoid the inappropriate term 'exponential' to describe the phenomenon. The rest is true.

Post reply on HN