Inventor, Technology Consultant, Developer. Working on the fuller stack (from hard technology development to software). Software Engineer at FileCloud.
Great piece! Being in a position that I can say something about this issue, I think that even if you design and architect the solution before coding, the bits, pieces, bolts and straight up duct tape to make it work is a focus-oriented task. Interruptions should be minimized.
A proper architecture, that is obvious and simple to all parties in a company/team (PMs, devs, devops, testers, content), makes it easier to re-focus, though.
Several issues in projects I worked on came from the fact that the business architecture never got reflected in the technology. If you are working on a business-first case, grill your PM, do small drafts, do delivery dates on small issues, keep track of the development and, last but not least, explain what is necessary in terms of time and manpower to deliver a solution.
I'm also guilty of "coding away", so to speak - tinkering requires focus. That is why my personal solution to the interruptions and constant iterating over business ideas is drawing stuff down and coding until another meeting. Those are not standups or briefs - since I do remote, so it's in both mine and my client's best interest to not waste our mutual time talking about the weather. I usually schedule an hour meeting for about two to three weeks of development.
Thus, TLDR;
Draft Everything.
Keep your work tracked. Track the work of your client
Make sure your client/boss is on the same page as you are (that means you also need to be on the same page as they are).
That should let you get back on track easily whenever unwanted human interaction happens :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great piece! Being in a position that I can say something about this issue, I think that even if you design and architect the solution before coding, the bits, pieces, bolts and straight up duct tape to make it work is a focus-oriented task. Interruptions should be minimized.
A proper architecture, that is obvious and simple to all parties in a company/team (PMs, devs, devops, testers, content), makes it easier to re-focus, though.
Several issues in projects I worked on came from the fact that the business architecture never got reflected in the technology. If you are working on a business-first case, grill your PM, do small drafts, do delivery dates on small issues, keep track of the development and, last but not least, explain what is necessary in terms of time and manpower to deliver a solution.
I'm also guilty of "coding away", so to speak - tinkering requires focus. That is why my personal solution to the interruptions and constant iterating over business ideas is drawing stuff down and coding until another meeting. Those are not standups or briefs - since I do remote, so it's in both mine and my client's best interest to not waste our mutual time talking about the weather. I usually schedule an hour meeting for about two to three weeks of development.
Thus, TLDR;
That should let you get back on track easily whenever unwanted human interaction happens :)