
Developer Time - craigkerstiens
http://pydanny.com/developer-time.html
======
willholloway
This is why I created my own alternative to ordinary clocks - Maker Time:
<http://willholloway.net/makertime.html>

Clocks get it wrong because they count up, but one day we will all die, so
from our perspective time is counting down.

I started thinking about alternative calendar systems when I learned about
Post-Revolutionary France's attempt at introducing metric time.

The problem with dividing the year by 1000 is 1000 is divorced from
astronomical reality of life on earth. Swatch internet time is the latest
attempt at this but I think it misses the mark.

I wanted a time keeping system that matched up with our cosmic reality and the
reality of making things vs managing people. We have two important events, the
year (one rotation of the earth around the sun) and the day (one rotation of
the earth). The moon's cycle is only important for tides (and it's close in
duration to the female menstral cycle)

Maker time divides the year into 1095 (or 1098 in a leap year) blocks. Each
block is 8 hours. On January 1st the count resets.

This way I don't have to look at the clock and feel the stress it engenders,
but also I get to mark the passage of time.

There are 82 maker time blocks left this year and I have big plans for those
82 remaining blocks of time. And one 8 hour block for sleep per day is
productive time, thats when my brain encodes the things I learned into long
term memory.

~~~
nileshtrivedi
Nice! I made <http://936months.staticloud.com/> to look at one's life in
blocks of months (936 on average). Seems to work well for inspiring someone!
:)

~~~
willholloway
936 Months is really good. It sounds trite but this really does put things in
perspective.

------
MattRogish
It's up to the entire company to make sure to leave ample time for developers
to enter flow. And to reduce any interruptions that will negatively impact
flow.

I find it really amusing when companies have "no meeting Wednesdays!" - fix
your damn system so that you don't need so many meetings. I know of no actual
programming problem that requires so much coordination that a programmer
actively needs more than two or three meetings a week. My goal is to get every
developer to 1 meeting a week (the weekly 1:1).

Things to remove:

* Meetings

* Interruptions/Noise (this is why open-plan offices are terrible)

* "Can I ask you a quick question?" questions

* High-bandwidth communication for anything that isn't life-or-death emergency

* Fire-drills/"emergencies"

* Fixed work schedule

Things to do instead:

* All meetings (with the exception of 1:1's) are optional

* Async communication wherever possible (chat rooms, email)

* Assume that any person, at any time, can be remote (this changes everything and makes sure that folks prepare ahead of time)

* 100% flexibility in work schedule to allow for folks to find their productive peaks, whether that's at 4am or 4pm

~~~
agrona
Fire drills strike me as an infrequent yet important safety measure. Unless
it's some management term I don't understand?

~~~
MattRogish
When someone else's lack of preparation or planning makes it your last-minute
problem. NOT the life-saving kind.

~~~
meej
I have long wondered how the phrase came to mean this, because when it
happens, it's never a drill.

~~~
jaggederest
The vast majority of business firedrills are arbitrarily caused by someone
wanting a deadline met for no particular reason.

Everyone does crunch time not because there is actually a pressing emergency,
but because the company wishes to extract additional effort for no additional
pay.

~~~
meej
Hm, ok. That's not been my experience. For example, I have definitely heard it
used in Operations contexts to describe broken shit that needs fixing now --
things that are real problems and not drills. "Drill" to me implies
preparation for an event in the future like a test or an emergency.

------
pygorex
As a developer I schedule "surgery time" to avoid distractions. Blocks of 2-4
hours during the day where I go dark - no phone, no email, no chat/IM. The
surgery analogy is apt. A good surgeon is amicable, knowledgeable, listens to
patients and applies a deft touch to fix problems. But when he's elbow deep
inside a patient he sure as hell isn't going to be taking any phone calls.

------
briancurtin
Working from home changed the game for me. I used to sit outside of the
busiest conference room on the floor and not only did it affect me, but it
opened my eyes to how many meetings people were going to.

I understand PMs being in a bunch of meetings, but I'd see devs and testers in
that room multiple times a day. The worst would be how many 3 minute meetings
would go on there that started 2 minutes late. People would show up a minute
early, leave a few minutes later, then be back to their desk a minute later.
They probably tuned out of work five minutes before that, wasted five or so
minutes with this "meeting", then weren't back in the flow for another 10
minutes after that. Some useless or empty "status update" cost 25 minutes, and
I think that's being pretty generous.

------
tommccabe
Everyone gets interrupted. Why do we (developers) think that we're unique and
should be the only ones immune to interruptions in the workplace?

Nearly everyone is going to work better with blocks of time dedicated to their
task(s). How about we all (developers + non-tech people) work together to
reduce the amount of noise that our companies generate so that everyone can be
more efficient?

~~~
gte910h
Developers have to have a lot more in working memory than many other types of
position.

~~~
riazrizvi
Though the better you get at organizing your code, the less you need to push
your working memory. In the first decade of my coding life, it took me a while
to 'warm up' and 'cool down', distractions were _extremely_ irritating. In the
second decade I started to find it easier to jump in and out of the coding
state, by maintaining a more focused problem-space.

~~~
gte910h
I am of a similar age to you I am guessing. I think many people have a
mythical view of their own ability to escape the typical human experience.

Perhaps distractions don't damage your productivity, but I am guessing you're
merely more productive now, so the short bursts you make are more productive
than your old longer bursts, therefore your 'Warm up and cool down' periods
FEEL shorter. It's not like people do nothing when not in flow, they just do
less.

------
moocow01
The fix: work remotely.

Besides call in meetings you can filter all your communications through
electronic means. I check my email only every 4 hours. When I need to not be
distracted I turn off my IM. It can be kind of lonely but Im overall much much
happier.

------
tomasien
I wrote about this morning actually! Realized that hating being interrupted by
meetings made me feel like a programmer for the first time.
[http://tommy.authpad.com/i-apologize-for-every-
unnecessary-s...](http://tommy.authpad.com/i-apologize-for-every-unnecessary-
second-a-programmer-has-spent-in-a-meeting-because-of-me)

~~~
tomasien
My apologies to everyone who read this from this thread, I'm going to put this
on HN tomorrow morning. Meant to do it this morning.

------
chewxy
Headphones, and a reflexive action to punch anyone who touches you when you
have your headphones on is a very good way to dissuade people from distracting
you and pulling you into meetings.

source: I do this :P

~~~
gurkendoktor
Doing this (well not punching people, just saying "not now" and putting the
music back on :)) I think it works because there is such a need for
programmers. Otherwise, I would probably come across as a candidate with
terrible communication skills.

~~~
nicholassmith
I do that, but I always follow it with "sorry I was in the zone", which
everyone instinctively gets and understands.

~~~
TeMPOraL
Higlight the _was_ part strong enough, and maybe you'll make them feel a bit
of healthy guilt about interrupting you.

------
jschuur
I'm a developer turned product manager, and from first hand experience, I can
tell you that distraction is one concern, but easy access to chat with the
devs also runs the risk of 'just one more feature', or constantly revising the
scope of previously discussed work too. That doesn't just get them out of the
zone, it confuses them about what they're meant to build.

Sometimes, it's best to just complete a user story as it was logged and then
see where we go from there (or even, shudder, after it's been deployed, and
actual users have gotten their hands on it).

------
imgabe
I'm going to propose a somewhat radical solution: secretaries (or
administrative assistants if you prefer).

Seriously, give developers and engineers secretaries/assistants. Even one
assistant per 3-5 engineers would be a huge benefit. A good secretary will run
interference with people who are coming to provide a distraction, and in many
cases will probably be able to answer any questions necessary without
bothering the engineer.

It could also provide a good entry level position for someone to get some
experience and move up to coding.

~~~
mgkimsal
goodness, the social signals implication that sends would never fly in any
company I've ever worked at. You're elevating the developers to the status of
"rock stars!". Now, many companies _say_ they want rock star developers, they
just don't want to treat them as such.

------
ww520
That's why coding at night works so well. No one will bother you at night.

------
tobyjsullivan
I agree that a complete fix is unrealistic; however, identification of the
problem certainly leads to potential for mitigation.

My personal favourite was the idea of a day of no interuptions. I think this
would be relatively easy to implement and one day of high productivity is
still an improvement over zero days of high productivity.

A further solution might be good old fashioned office hours. You have a
question for that requires my personal advisement? Great! I'm happy to answer!
Anytime between 4:00 pm and 5:30 pm. If it really can't wait, email me and
hopefully I lose my flow and check my email in time.

------
thaumaturgy
Also: build better tools (and get better at using the ones you have).

If you can squirrel away a little bit of time here and there to make hard
things easier, then you can eventually start breaking tasks down into chunks
that fit better into a day of interruptions.

This has been the only way that I've found to _consistently_ increase my
productivity no matter how much I'm procrastinating or being distracted at the
time.

~~~
rhizome
So when you're deep in focus, or trying to be, and there's an interruption or
ad-hoc open-floor brainstorming meeting right next to you, you just blink once
or twice and shift over to some easy-pickup task you already have waiting in
the back of your brain? Add a zero to your rate.

------
jkbyc
I think this concept is much better described here via a dream analogy:

<http://alexthunder.livejournal.com/309815.html>

(DON'T WAKE UP THE PROGRAMMER!)

~~~
jkbyc
and also by pg: <http://www.paulgraham.com/makersschedule.html>

------
corwinstephen
Headphones: the ultimate "don't talk to me, I'm working" sign.

------
laquan_is_great
The post is right on, but I also have to repost what laquan jackson said in
the comments:

"Programming is for weak and effeminate men. Try carrying bricks up flights of
stairs, or collecting rent checks in the inner city. And on top of all this
you complain about "being interrupted"? Oh, how awful it must be for you. You
need to check to see if you have a vagina down there."

Sure it may be controversial, but it's funny.

------
koz_
Meditation is a great way to train one's attention and focus.

A lot of ink is spilled describing what companies and bosses could do to
enable programmers to get or stay in the zone, but all of that is immaterial
compared to one's intrinsic ability to focus, which is a skill that can be
developed.

------
logn
Just get to work early. I used to work on the east coast alone and the rest of
the team was west coast which was great since I got about 4 hours every day of
being alone. You could do the same thing by switching your start time from say
10:30am to 7am.

------
wglb
When I need to be in the zone, knowing that there is a fixed end time can be
an obstacle.

~~~
aleprok
Why to set a fixed end time for your zone? Your zone will end when you have
finished your task and start to look for the next task.

~~~
j-kidd
If you do not telecommute, you may want to set an end time to beat the rush
hours traffic. One of the many reasons why it is unproductive to work in an
office.

------
diminoten
As a guy in QA, what should I do? I can't ever tell if it's just the developer
being nice when they say they want me to tell them about bugs before filing
them, or if they actually want me to.

How would you want your QA people to deal with this problem?

~~~
pydanny
See, that's part of the problem. We need to interact with you. Do we skip
meetings and go to tickets? Except that tickets are often ignored or are
misunderstood. Then comes the need for discussion. Of course, interrupting a
developer is bad, so you have to schedule a discussion - A.K.A a meeting.

There is no magical solution to this problem. :P

~~~
meej
Agreed.

What I notice at my current employer is that trying to avoid pulling people
into meetings results in what I call "Development by game of Telephone", where
software requirements become rumors passed between employees. (Even when
requirements are documented -- because the documentation is vague.)

------
3rd3
Not related to the article but the CSS text selection color is really bad.

~~~
pydanny
Ouch. And I just started the css/design refactor today. :P

------
michaelochurch
I'm going to inflict some blistering cynicism on this thread.

You don't succeed in most environments based on whether or not you're
_productive_ , competent, or expert at what you do. None of that _really_
matters once a company gets to the point where decisions are no longer being
made by technical people.

So, you have to suffer. You have to deal with the meetings and the social
expectations. Most developers work in an environment where availability
matters more than excellence. In at 9:45, when the boss is in at 9:30? Stee-
rike one! Miss the daily standup? Stee-rike two!

There is a positive spin you can put on it. Most companies won't actually
_fire_ you for skipping those meetings. They're mandatory, but not _that_
mandatory. However, you'll just end up increasingly out of the loop and with a
negative reputation... and eventually lose your job, but it will take a long
time-- possibly 6 to 12 months, and certainly long enough to get another one.
Attending that 15-minute status meeting rather than skipping it probably has
as much of an impact on your political standing (and, thus, career) as a
2-hour swing in the overall length of your day. So the efficiency ratio of
that meeting to normal ass-in-chair time is 8-to-1. No, it's not what you'd
like to be doing with your time, but it's work, and most people deal with a
lot worse than status meetings.

The game in most places isn't about getting the most done, or getting into
flow and building great software. It's about creating an image so that
managerial types, many of whom operate on antiquated emotional metrics of
availability and subordination, feel confident in you. It's a game to be
played, not a meritocracy.

~~~
zacharydanger
This is excellent advice for when one wants to advance their career working
for "the man."

