5 ms·

> To summarize, the main problem for me is to feel like a text processing machine, receiving mails, Jira tickets and chat messages as input and writing code as

> To summarize, the main problem for me is to feel like a text processing machine, receiving mails, Jira tickets and chat messages as input and writing code as output, without the human interactions needed to make it more meaningful. I do not like becoming a kind of a remote developer black box. This sounds fantastic, where can I get such a gig? There's really nothing better than being given a more-or-less defined task, and being free to just go get shit done, without interruptions, or waffling, or hemming and hawing about whether it should be done this way or that way, by people who have no understanding of the technical realities. Thank god it's a work-from-home Friday. I predict I will get far more accomplished in four hours today than I did in the 40+ I was in the office Monday-Thursday.

badpun 9y ago
> about whether it should be done this way or that way, by people who have no understanding of the technical realities. This will most likely still happen, just over Jira, chat, and code review comments, making it more painful (as the bandwidth is lower) than in real life.
- yoz-y 9y ago
  Those are much easier to ignore though.
  - badpun 9y ago
    The non-essential stuff (ex. people asking to "take a quick look" at something) yes, but for anything that still pertains to your task at hand you'll still need to respond. You get the benefit of being able to respond asynchronously, but so does everybody else, which can make a simple conversation (on which your task depends) take days.
- asdjasldkjkljd 9y ago
  I've been working in my career for 20 years and I've literally never thought "I wish more people had immediate access to me constantly" — lower bandwidth is a very good thing.
mason55 9y ago
It seems to me that one reason you are able to sit down and just get shit done on Friday is because you've been in the office Monday - Thursday to get context, discuss implementation strategies, understand the business goals, and ask/answer any questions. Then by the time Friday comes around you're ready to sit down and bang out code. But whether you're in the office or not while writing that code is completely orthogonal to whether you have the context & requirements to do it. A good organization that's built for remote workers can communicate all of that without people having to be together in person. Likewise, a bad organization will have bad development & requirements practices whether you're in the office in person or remote. The big difference is that it's easier to ignore distractions when you're remote so once you have your work (mostly) defined then it's easier to get into flow when you're by yourself.
- sheeshkebab 9y ago
  Ah, gotta have the requirements to get things done - right, I’m with you on that one. Where would all software dev be if we didn’t have requirements? ideally printed out and distributed in neatly packed binders. </s> Seriously, do you really think that something that cannot be worked out over slack/confluence/phone call can be worked out in person sitting in the busy office with all kinds of distractions and stress caused by commute in/out....
  - spdionis 9y ago
    Yes. Get a meeting a room and do a proper meeting. The thought of having a 1 hour long meeting makes me sick. The thought of having a 1.5-2 hours long phone call (adjusted for inefficiency of the phone call) makes me want to kill myself. I will not get anything done ever after that.
    - Clubber 9y ago
      The person writing the spec should actually be able to think it through a few times before needing a developer in the room. If the spec writer can't think through a spec by themselves for at least 95% of it, they aren't qualified to be submitting tickets, IMO. The most efficient way to communicate specs is through a document, so I have something to reference. I'm not going to remember everything said in a meeting unless I immediately start working on it. The spec document should be exhaustive, clear and easy to follow with no dangling questions unanswered. If you can get a spec writer that can do that, you're golden.
potta_coffee 9y ago
You just described my current gig, and I'm in heaven. It's literally the best thing ever. I hope it never ends, I never want to go back to working in an office.
passiveincomelg 9y ago
Maybe you find this talk interesting https://m.youtube.com/watch?v=ZBGalP3jBwU https://m.youtube.com/watch?v=ZBGalP3jBwU

badpun 9y ago

> about whether it should be done this way or that way, by people who have no understanding of the technical realities. This will most likely still happen, just over Jira, chat, and code review comments, making it more painful (as the bandwidth is lower) than in real life.

yoz-y 9y ago
Those are much easier to ignore though.
- badpun 9y ago
  The non-essential stuff (ex. people asking to "take a quick look" at something) yes, but for anything that still pertains to your task at hand you'll still need to respond. You get the benefit of being able to respond asynchronously, but so does everybody else, which can make a simple conversation (on which your task depends) take days.
asdjasldkjkljd 9y ago
I've been working in my career for 20 years and I've literally never thought "I wish more people had immediate access to me constantly" — lower bandwidth is a very good thing.

mason55 9y ago

It seems to me that one reason you are able to sit down and just get shit done on Friday is because you've been in the office Monday - Thursday to get context, discuss implementation strategies, understand the business goals, and ask/answer any questions. Then by the time Friday comes around you're ready to sit down and bang out code. But whether you're in the office or not while writing that code is completely orthogonal to whether you have the context & requirements to do it. A good organization that's built for remote workers can communicate all of that without people having to be together in person. Likewise, a bad organization will have bad development & requirements practices whether you're in the office in person or remote. The big difference is that it's easier to ignore distractions when you're remote so once you have your work (mostly) defined then it's easier to get into flow when you're by yourself.

sheeshkebab 9y ago
Ah, gotta have the requirements to get things done - right, I’m with you on that one. Where would all software dev be if we didn’t have requirements? ideally printed out and distributed in neatly packed binders. </s> Seriously, do you really think that something that cannot be worked out over slack/confluence/phone call can be worked out in person sitting in the busy office with all kinds of distractions and stress caused by commute in/out....
- spdionis 9y ago
  Yes. Get a meeting a room and do a proper meeting. The thought of having a 1 hour long meeting makes me sick. The thought of having a 1.5-2 hours long phone call (adjusted for inefficiency of the phone call) makes me want to kill myself. I will not get anything done ever after that.
  - Clubber 9y ago
    The person writing the spec should actually be able to think it through a few times before needing a developer in the room. If the spec writer can't think through a spec by themselves for at least 95% of it, they aren't qualified to be submitting tickets, IMO. The most efficient way to communicate specs is through a document, so I have something to reference. I'm not going to remember everything said in a meeting unless I immediately start working on it. The spec document should be exhaustive, clear and easy to follow with no dangling questions unanswered. If you can get a spec writer that can do that, you're golden.

potta_coffee 9y ago

You just described my current gig, and I'm in heaven. It's literally the best thing ever. I hope it never ends, I never want to go back to working in an office.

passiveincomelg 9y ago

Maybe you find this talk interesting https://m.youtube.com/watch?v=ZBGalP3jBwU https://m.youtube.com/watch?v=ZBGalP3jBwU