7 ms·

I work remotely from the rest of my team, and only started a few months ago. Often, I have quick questions or clarifications that I can't ask about in person, a

• 989809809809 10y ago
  Excuse me, but if not getting in touch with your colleagues blocks you for the whole day then you probably have the bigger problems than just not getting your questions answered on time: 1. Maybe documentation is scarce, be it code comments or business requirements specs, user stories, epics, etc. 2. Maybe your tasks are ill defined, and you accepted your assignments without asking enough questions upfront... 3. Maybe you don't get enough workload (if you had many tasks to choose from it would be harder to get blocked on all of them) 4. maybe you lack some technical knowledge or other competencies needed to make the decisions yourself instead of asking others.
  • brianwawok 10y ago
    That is rubbish. Many reasonably complex projects require a reasonable amount of communication. This list sounds like you have only worked on 1 man toy projects.
    • gcp 10y ago
      Communication, yes. But synchronous, blocking communication? You have an organizational problem there.
      • brianwawok 10y ago
        Again, I disagree. Any reasonably complex codebase I have worked in has at least parts that only a few people understood. Even if n=3, you could still very easily be blocked when trying to find someone in the know...
        • gcp 10y ago
          Right, so an organizational and architectural problem. It's even got a specific term: Bus factor. https://en.wikipedia.org/wiki/Bus_factor https://en.wikipedia.org/wiki/Bus_factor You have a problem. Disagreeing with me won't fix it. It's a common problem, but also a fixable one.
  • pgodzin 10y ago
    1, 4. Yes, documentation is absolutely scarce - given that culture, such back and forth is often required. Some configurations or details of a complex (and often legacy) system are opaque, and used infrequently enough that teamwide training on it isn't appropriate. 2. Yes, often my tasks are exploratory rather than implementation of a particular feature. Often the goal is to explore and then discuss my findings. When I can't just go up to someone's desk in person and ask them when they are free to discuss, Slack is a good resource to set up a meeting. 3. I definitely am not blocked on all, but the context switching hurts my productivity as well - to me, a quick response would have large benefits for me and a minimal distraction for my colleague.
  • afarrell 10y ago
    You're right that these are problems, but how long does it take to solve them? 1) Do you know of a way to document a significantly-sized application in such a way that it is not massively more efficient to ask a colleague for help than to go source-diving? Say we are talking about a rails app that has been maintained for 5 years and with a reasonably complete test suite. 2) Does a fresh-from-uni or perhaps 2-years-out-of-uni junior developer teach themselves how to ask just enough questions up-front that they don't need to ask more to unblock themselves? 4) How does one gain this technical knowledge if you are on a project and need to apply it but don't yet have it yourself?
    • pgodzin 10y ago
      Well put, thank you. Re 2: Often tasks are even meant to be exploratory, where those questions can't be asked upon receiving the task, but only once enough investigation has been done and implementation questions are run into. Rather than a quick back and forth that keeps me progressing, I have to context-switch to something else, and spend time re-familiarizing myself with what I had done the day(s) before again.
    • quanticle 10y ago
      Do you know of a way to document a significantly-sized application in such a way that it is not massively more efficient to ask a colleague for help than to go source-diving? Say we are talking about a rails app that has been maintained for 5 years and with a reasonably complete test suite. Yes. You can draw architectural diagrams. You can create a wiki where people document problems and solutions. You can have broader design reviews where people talk about the ways in which they solved various problems and what considerations they took into account when coming up with those solutions. I agree with the other posters in this thread: if you're truly blocked (i.e. literally unable to work) because someone can't respond to your question, there is something deeply wrong with your codebase, or in the way in which your team communicates. Personally, I would expect anyone who's been on the team for more than few months to be largely self-sufficient when it comes to actually coding. Of course, there will be questions when there are multiple possible approaches to solve a given problem, and I would expect someone to raise a flag and ask about the relevant considerations. But in the absence of a reply, you should be able to pick an approach and push forward with it. Does a fresh-from-uni or perhaps 2-years-out-of-uni junior developer teach themselves how to ask just enough questions up-front that they don't need to ask more to unblock themselves? Honestly, at some point, you have to learn your team's codebase. You say that it's massively more efficient for you to ask questions of colleagues than it is to go source diving. That, to me, indicates that you don't actually know your codebase very well. Again, this is a sign of a problem on the team. Either the source is so tangled that no one can hope to understand all of it, or people are becoming siloed - specializing in particular areas of the codebase in ways that leaves them unable to fix problems in other areas. It's all right to be better at one part of the code than another. For example, I'm better at some of the middle-tier/business-logic code than I am at UI work. But, in a pinch, I can jump in and help with UI if it's necessary. How does one gain this technical knowledge if you are on a project and need to apply it but don't yet have it yourself? I'll be honest. It's rough. You have to learn, and you have to realize that outside of university there aren't going to be TAs and professors to point you in the right direction. You will make mistakes. But that's the only way forward. Keep trying. Keep writing code. If you do something and it doesn't work, have a meeting in which you go over what you did, why it didn't work, and what you could have done better.
• atis 10y ago
  That sounds a bit strange because there's always something else you could be doing while waiting for that answer? Either working on another issue, or trying to improve something without being asked to, or even just learning something that could (or not) be helpful sometime in the future. Worst case scenario: read some HN :-) But really: doesn't working remotely mean that, when blocked, you can just leave the computer and do some life stuff, then come back a few hours later and continue from there?
  • pgodzin 10y ago
    Sure, I can always do something else instead, but that context switching is costly for me as well, when a minute-long conversation, though briefly distracting for a colleague, would have been able to keep me working at the task at hand.
    • lbatx 10y ago
      How is context switching costly for you, but only briefly distracting for your colleague?
      • pgodzin 10y ago
        To me it's the difference between a few line exchange that is briefly distracting vs switching to working on a completely different task, getting up to speed on it just in time to have to switch back and refamiliarize myself with where I left off. Order of minutes vs hours.
        • Sacho 10y ago
          In my experience the questions tend to cluster towards a small group of individuals; so from their perspective, you're the 5th interruption in line for the day and they've barely been able to start their own work. That's one reason why I like the idea of taking forced breaks; they give you a scheduled time to handle brief interruptions, and if you're fairly regular people can tune in to your schedule(e.g. if you're always "working" the first 50 mins of an hour and "resting" the last 10 mins, it's easy to know whether you'd be able to quickly answer a question). Of course, the forced breaks are another form of an interruption from flow; it's still a trade-off.
• dbcurtis 10y ago
  So I think it is necessary to differentiate between "deep work" jobs (See Cal Newport's blog/books...) and "interrupt driven" jobs. Engineering design generally is a "deep work" job. Long periods of uninterrupted concentration are key to productivity. Other jobs, like receptionist and office managers, for instance, are interrupt-driven. Receptionists add value by responding quickly and handling a continuous stream requests. Now let's talk about engineering managers. Being an engineering manager is IMHO, an interrupt-driven job. The job of an engineering manager is to tell you where to find answers to your questions, or on a good day, actually answer the question. The friction comes when an engineering manager does not understand that the interrupt-driven nature of his/her job is not reciprocal. A good manager will handle interrupts quickly, but only very judiciously use the power to interrupt. Another source of confusion is dev/ops. Anything operational will tend to be interrupt driven. An engineering manager that has been running a high-functioning dev/ops team that is a team of crack fire-fighters might be a very disruptive force in a design engineering team if that manager expects a constant volley of chat messages among the team.
  • yakult 10y ago
    It's perhaps more accurate to say there are 'deep work' tasks, and there are 'interrupt driven' tasks, and any job is a combination of both, in various ratios. Often you can't even tell ahead of time whether a given job is going to be mostly one or the other. Maybe what we need is a system where instant messages are allowed, but it imposes a cost of some kind to the person initiating it, so that it won't be used frivolously. Like the proof-of-work antispam captchas, except it should take ~30 seconds and be just once per conversation (defined as ending when 5 minutes go by without message; first replies are free). We could also add a social cost by displaying how often each user has used this feature in the past 24 hours, next to their username.
    • morgante 10y ago
      This is a great point. It's really important to recognize the nature of different tasks and to build different habits around them. As a startup founder, by far my two biggest tasks are customer acquisition and development. The former is interrupt-driven while the latter is emphatically deep work. Right now, I try to address this by blocking off 4 hours a day for deep work and the rest of the time is available for sales and general operations. It's working okay but the big problem is that I have an added stress of worrying what important customer messages I might be missing during my deep work time.
• forgottenpass 10y ago
  If your bosses aren't planning to lay everyone off in a month, there has got to be something slightly-lower priority to be working on. Unless you're on the critical path, spending half a day blocked on your primary task and focusing on a secondary priority is no big deal (or, at least, shouldn't be). If you are on the critical path, scoop up that phone and start dialing. Since you're new there, you might not have the assignments and/or enough responsibility to know what else needs to be done. But that should happen soon, and there is no reason not to proactively talk to your boss about secondary goals to focus on when you're blocked waiting on communication. I think it's just good management to convey the bigger picture to everyone. Between the steady stream of tickets assigned to me and other existing responsibility I haven't had to ask my boss "what do I work on now?" in... like... 3 or 4 years.
  • pgodzin 10y ago
    Sorry, meant to imply I was blocked on that specific task, which is often the highest priority one, rather than on all tasks. Unfortunately, the highest priority ones are often the most difficult and trickiest, requiring occasional questions when I run into things other have had experience in. Is the loss in time spent on high priority items worth fewer quick distractions to the rest of the team?
    • forgottenpass 10y ago
      Oh, OK. I get where you're coming from now. Is the loss in time spent on high priority items worth fewer quick distractions to the rest of the team? It all depends on the tasks and your particular work environment. It's going to vary from place to place, so I don't have anything specific to tell you other than this kind of prioritization is the kind of conversation you should be comfortable having with your lead. Or at a status meeting or standup, if your process makes that the better place to ask.
  • ehnto 10y ago
    I work at an agency where there is a steady stream of tickets. We are very concious of the cost of task switching. In the case where you are blocked on a task and it is left unfinished in favor of a new task of lower priority, when you finally get an answer on the first task you often have to dro the second task abruptly. So you have two unfinished tasks and all the mind balls you were juggling are dropped on the floor. However we are also an almost entirely engineering team so there is no resource for getting unblocked that isn't bugging another developer who then drops his mind balls. It is just the reality of it though, we have tickets and tasks to complete and we can work toward being more efficient, making sure we aren't going to get blocked befor getting started on a ticket and such. It's all a balancing act and it's important to be aware of it, but I no longer get my knickers in a knot over it.
• cel1ne 10y ago
  I just write together what I need to know and combine into a single email or phone call.
  • hackflip 10y ago
    Do you ever find that this approach leads to a subset of your questions being answered? I've found that asking n questions in a row frequently leads to only the nth question being answered (which I presume is often due to content being pushed "below the fold" on mobile devices).
    • cel1ne 10y ago
      Yes of course, because people are often busy or too lazy to think the answer through. But that doesn't matter, I can work with the subset. Sometimes the questions resolve themselves, sometimes I just write another email, it really depends.
• gcp 10y ago
  Doesn't Slack have a similar system to IRC, where you can specifically send a notification to someone by prefixing with their handle? I've worked remotely for many years and this was never a problem. Need some company? Just read and follow a few channels. Want to get work done? Ignore client and code. If someone needs me, a notification + sound will pop up. Works fine with IRC, really.
• ehutch79 10y ago
  You can't pick up the phone?
• lucidguppy 10y ago
  Questions should be on slack.... answers should be on the wiki... Then check the wiki before you ask a question. Query driven documentation.