Hacker News Reader

Comment by mason55 | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com