Ask HN: How do you deal with context switches?

2 points by starlord 9 years ago | 0 comments

I searched previous hackernews threads on this, and found a few suggestions I thought looked good: (1). Pair programming. (I am the sole tech cofounder and don't have another guy to work with yet...)

(2). Just saying "NO" till you are done on present task. (Being the cofounder, have to share responsibilities to deal with a bunch of other shit to get money, do legal stuff etc... so can't always just say "NO" for another few months till org grows large & can hire someone to get this done)

(3). Allocate blocks of time on calendar. I am solely developing the web app (usual front-end shit), backend rest api and the android app (android dev build waiting is the worst IMHO) and need to keep switching between these as well through these "blocks" of times I do get alone. I noticed these dev environment switch also slow me down a little even in these "blocks of time". Eventually the product milestones are quite screwed and I am massively depressed and low on confidence.

Really looking for any suggestions that worked for you if any of you have dealt with these things earlier?

(Context if needed/relevant: 29 yr old single guy, not high on energy anymore, no social life distractions either)

brudgers 9 years ago |

My take from hundreds if not thousands of miles away while not knowing any details and reading between the lines and subsequently leaping to massive assumptions:

If there are other founders and they are non-technical then part of one or all of their jobs is to keep you from being interrupted. By extension this means that part of their jobs is not interrupting you themselves.

It also means that there should be a clear strategy based on business needs and part of the implementation is prioritizing the product. Android, API and a web app cannot all be equal priority in the immediate term [personally I'd rank them in reverse order because the web app will determine the priorities of the API and the API will make building an Android app easier and if it works as a web app then native mobile isn't all that important to the core idea...but I digress].

So my advice is to ship a web app. Then the company will 'own' whatever users the app attracts and can communicate with them directly through any channel that might work [email, slack, voice calls, snail mail, conferences, cold calls to the customer's address, etc.].

My first drafting job after vo-tech I felt unproductive so for two days I wrote down every time I switched tasks. I showed my boss and we changed things. I was lowest person in the engineering department so I had to get approval to prioritize. For a cofounder the priorities will arise naturally from the work. Just drop what is not urgent and important.

Good luck.