Hacker News Reader

Comment by megaman22 | Hacker News Reader

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

View on HN

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.

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

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.

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.

You have never written a spec have you?

Not only is the 5% important, as every "only 5% left" tends to be, you are completely ignoring possible developer questions.

I've read my take of shit ones. Most of the time, the writer hasn't bothered to think about it past the initial idea and needs the developer to help them understand what they want. That's not the developer's job.

Remember this when you'll write your first spec one day.

We're Agile, why do we need spend time on requirements and architecture? That's so Waterfall </s>

You do realise you do actualy need some form of requirements, otherwise what are you doing, just writing code with no goal?

Granted it doesn't need to be a big up front document, but some of those slack/confluence/in person meetings will ultimately be around "so, guys/gals for this next proposed , feature, story (requirement), w/e, this is how I'm achieving it". Oh, and as for non functionals..

Having spent years working remotely with office focused teams, the nuances of these discussions are the ones that get missed by the remote attendee unless everything is set up correctly.

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

Those are much easier to ignore though.

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.

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

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.

Reply on news.ycombinator.com