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.
Best practices for remote software engineering
161–170 of 205 posts
Re: Best practices for remote software engineering
#162Earlier 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…
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
#163Lots of whiteboards. Clean, tidy desk. No visible cables. Sunlight. Fresh air. Caffeine
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
#164The 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…
Re: Best practices for remote software engineering
#165I 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…
Re: Best practices for remote software engineering
#166Earlier 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…
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
#167If 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
#168Re: Best practices for remote software engineering
#169Earlier 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.
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.
Re: Best practices for remote software engineering
#170* Shower first * Put on clothes * Deliver tangible things often