4 ms·
To the OP, you are definitely not alone. PG had a good article on the difference between a managers schedule and a programmers schedule [1] (Interrupt driven vs
by kabouseng 11y ago
To the OP, you are definitely not alone. PG had a good article on the difference between a managers schedule and a programmers schedule [1] (Interrupt driven vs Focus driven).
Unfortunately as you become more responsible for the management of your peers and projects, you will experience this problem more and more. Some people cope by having a context switching role during office hours and after hours get a good 1 or 2 hours of solid dev work in, others book their own time out, and close their door signaling they are unavailable. Unfortunately this isn't always possible, you'll always get colleagues / clients that still bash your door to get some time with you.
But being in this transition phase between the two worlds is definitely one of the biggest challenges every dev faces. Best of luck.
One thing though, having more personnel will not solve this problem, only make it worse, as you now will have even more people reporting to you and which you have to keep busy.
[1] http://www.paulgraham.com/makersschedule.html http://www.paulgraham.com/makersschedule.html
- kreeben 11y agoA good desription of my working situation is that I'm somewhere in-between the two worlds you describe. Thx.
- erikb 11y agoI don't know. Even since I was a student developer for companies there were always at least three topics at any given focus that needed at least some share of my attention. PG's suggested stretches of time where I could just do one thing are very small and very small to realise. In a great world one would have such a schedule, but if you don't code alone you will always be interrupted. At least that's my experience up to now.
- aidenn0 11y agoIt really depends on where you work. I worked one place where communication was biased heavily in favor of e-mail, with the understanding that it was less intrusive than other forms of communication. There was not exactly a ban on interrupting developers, but there was a culture against it (and there were things that were explicitly always okay to interrupt a developer for; e.g. a bug found by a customer).