
Show HN: v0.1 of my book "Why programmers work at night" - Swizec
https://leanpub.com/nightowls
======
forensic
Since this book will likely be unscientific conjecture backed up by an amateur
conception of psychology and physiology, I hope you will detail as many case
studies as possible to allow readers access to the data on which you are
theorizing.

Providing as much raw data as possible will greatly increase the value of the
book. It could actually be picked up by academics who study these issues.

When programmers attempt to study their own physiology and psychology, they
are leaving their area of expertise. Most blog posts that try to address
programmer productivity are tragically uninformed (and just as often contain
egregious analytical errors).

It's a very interesting topic and programmers have a lot of data to provide.

~~~
scott_w
I read the first chapter and found that his evidence was based on
conversations with other programmers. In this day and age, there's enough
information for the author to collect more empirical evidence in the form of
commits to open source projects.

One could take a sample of GitHub projects and commit times. You would have to
find out the contributors' time zones, and adjust accordingly.

You need to balance the hobby contributors against corporate contributors i.e.
those being paid to contribute.

If you wanted to make things really interesting, you could try and gauge code
quality based on time. Perhaps trying to assign bugs against the commit they
appeared in.

~~~
gbraad
Commit times do not necessarily convey the correct information; in the worst
case i could have worked two days on a commit, or even commit it the following
day. Time zones are also not accurate when travelling is involved for a
developer/engineer or eg. Is it even correctly set. I believe evidence comes
from first hand, conversation or questionaire

~~~
forensic
The social science approach would be to use both. Detailed case studies are
essential and should be the starting point. But hypotheses extrapolated from
those case studies could then be examined with statistical analysis like this.

------
kamaal
Developer productivity is nearly a solved problem. What isn't a solved problem
is to convince the managers about the solution.

Because the solution is radical. Your ordinary corporate manager is made to
believe that, team work + tools + a bit of odd micro management(without a clue
about what he/she is managing) thrown around is what takes to win. The fact is
that team work matters, but make-or-break deal for ambitious projects is
mavericks working full steam for a good amount on project's net demands.This
requires a total distraction free environment, a uninterrupted stretches of
time(tuits), choice of tools(both hardware and software) and many times
managers getting out of the way and letting the actual contributors do their
job in peace.

I have thought this over many time, hacked and tweaked my schedule many times
and this is what I have come to. Recently every time I decide to work from
home. A day before, I write down clearly without any ambiguity the list of
tasks I want to accomplish the next day. I start working insanely early. I
start at around 3 AM in the morning, The energy level are really high in the
morning. I also take in a lot of water. Apart from a break fast break at 8 AM.
I work all the way up to 12 in the after. That's 8 hours of uninterrupted
time.

The remaining day I generally work on a side project, or some thing I love
doing- like play a musical instrument. Or I just continue doing my work. Then
to go back to sleep for 6 hours at least.

The great thing about this schedule is, by the time somebody is up and running
throwing distractions at you, you are done with your work.

Ironically despite manifest benefits of this schedule, management finds it
'not good team work'(Read- your idea is too radical and is a threat to my
designation).

~~~
wpietri
I'm excited to hear that you've found a schedule that works for you, but you
too quickly dismiss teamwork.

There are perfectly fine projects that only take a single developer. There are
some that need a few people working as a loose group. But if you've got
something that actually needs a team, then bad teamwork really is a problem.

~~~
kamaal
I love team work too. Team work means knowing our mutual interests and how we
need to work together to meet our common goal(Which is to make the project
successful).

But once I am done knowing that, I want space for myself to shut down all
distractions and do my job. I believe that is what the managers want too, then
they need to understand as a developer I'm most productive when I get at least
two uninterrupted stretches of time during my work day.

~~~
borski
Perhaps a better term for what the parent may have meant was 'collaboration'
rather than teamwork. There are a lot of projects that truly require
collaboration, and that's hard to do when you're only working when other
people aren't.

------
Swizec
Hey everyone,

I'm looking for some feedback on my yet unfinished book - felt like this was a
good time. The most developed chapter right now is "About flow" so I'd really
love your thoughts on that one.

You can get it for free with this coupon code: HN0.1

~~~
nacs
Why is the price capped at $10? I'm sure there are people who'd be willing to
pay more.

~~~
spatten
That's our fault, not Swizec's. We cap it at 10x the minimum price (I think
that's how we coded it, anyways).

We're thinking of making the slider exponential (or something with an
increasing slope, anyways) instead, which would help.

------
Zenst
Main reasons programmer work at night would be some or all of the following:

1) Access to resources - be that free internet, the home computer or faster
internet. 2) TZ, its the internet and opearates on all TimeZones and with that
people interact across timezones and with that night seems to always cover
many cross-over times. 3) Distractions, there are less distractions, less
noise and with that easier to focus. 4) Coffee overshoots, with that the late
hours make productive time. 5) Whatever reason they want, code knows nothing
about daylight.

As for the sample of your book I glanced upon I would wonder if any programmer
would want to read it, and any manager who would gain from even a hint of
insight into programmers, would not be motivated to pick such a title.

If anything it is more a chapter subject for a larger book on how to deal with
modern persona's in a work enviroment.

That would be my approach, but my main reason for coding late at night is
covered in all the above though less distractions being the primary. Now if
you had a chapter on how to justify too your boss that you will be working
weird hours, that would be something a programmer would be interested in.

~~~
seyfarth
Coffee overshoot?

~~~
Zenst
Coffee overshoot = overspeccing the coffee requirements thruout the day
causing you to stay awake longer than you had planned.

------
sdfjkl
I used to work an 8 hour day, then go home, have dinner and go to bed
immediately after. I then got a few hours sleep and woke up refreshed and with
a clear brain between midnight and 2am. I then coded for a few hours until I
started feeling tired again, went to bed, caught an hour or three of sleep and
went to work. This had the benefit of me being better rested for my nightly
hacking than for my daytime job, which didn't require my full alertness (I was
stuck in a dull job at the time). The downside was that I had no social
interaction with people in my timezone (other than at work).

~~~
alanctgardner2
Sorry I can't do better than Wikipedia; apparently this is 'segmented sleep'
[1], and before electric light it was entirely natural. Apparently the extra
hours were used almost exclusively for sex, since there was no electric light.

[1] <http://en.wikipedia.org/wiki/Segmented_sleep>

~~~
jpsierens
Interestingly, was reading this and saw:

"This was also a favorite time for scholars and poets to write uninterrupted,
whereas still others visited neighbors, or engaged in petty crime."

Scholars and poets, programmers could fit into this category

------
nadaviv
I'm definitely a night person. I feel like I can turn on a switch on go on
turbo mode, hacking away and easily translating my thoughts to code. It
definitely agree that being slightly sleepy helps keep the focus, but it
doesn't seem to get in the way of accomplishing complex tasks.

I used to wake up at ~7PM and go to sleep at ~12AM for a couple years, which
worked out great for me - but unfortunately I couldn't keep up with it, as I
got recruited to the IDF (mandatory service in Israel) and than started a
business with a co-founder that has "normal people" hours :)

I only do it nowadays when I really feel like I need the extra boost (like
when I start working on a new complex project or component - I prefer to do it
on nights, and usually have a working prototype with most of the complex logic
after a couple "night sessions" that I finish off during daytime).

Great idea for a book, I'll definitely buy it when its ready. Wish you much
success!

------
smoyer
I'm one of "those morning programmers" who likes to get up before the rest of
the world. It's great to be well-rested and it's also quiet enough to work. I
guess the what I have in common with the vampire programmers is that caffeine
is most definitely involved.

~~~
smartial_arts
It's interesting how much more productive and motivated one is when working
early in the morning, versus just dragging through the night, when most of the
time only passive consumption of information/news is possible.

I guess this has something to do with our willpower depletion - see here for
more [http://blog.bufferapp.com/what-the-research-on-habit-
formati...](http://blog.bufferapp.com/what-the-research-on-habit-formation-
reveals-about-willpower-and-overall-well-being)

~~~
SoftwareMaven
The "one" who is more productive and motivated in the morning does not
describe me in any way. As much as I love mornings, when I wake up early, I am
fairly useless the rest of the day. On the other hand, I can start coding at
10pm and have 3am show up without realizing there was anything in between.

I really wish I was a morning person, but I'm not. I'm tired of "normal" being
dictated by those same people under the guise of, "you'll be a better person
for it" (note: please don't read this as me thinking you are saying that!). I
know myself well enough to know that is false.

At this point, I am _so_ happy to be working at home full time, where I can
wake up and start working at the time that works for me, whatever time that
happens to be that day.

~~~
e12e
My brother found the explanation for this: While those of us that are more
active at night were still sleeping, the morning people decided what the
proper schedule should be.

On a more serious note, there is a big difference between "A" and "B" people
(sometimes tied to A and B blood types -- I've not really tested this -- I'm
definitively not much of a "morning" person -- but I am flexible -- I can get
up at 2-3 am and work, or sleep until noon -- normally I prefer to be up for
5-8 hours _before_ I do any "work" -- and I am always more productive in the
afternoon (as defined by how many hours it has been since I got up). My blood
type is AB -- so maybe there is a correlation there.

I have some friends I've worked with that are absolutely useless after around
10 pm -- and others that are absolutely useless before 10 am. And a few that
are more like me -- they adapt easily to either way -- and also function quite
well even when under severe sleep deprivation -- or on an irregular sleep
schedule.

------
dageshi
Of interest perhaps is that personally I find that as winter rolls around my
sleep patterns get later and later. In the summer I'd guess I sleep 2am-10am
in winter it's more like 4am-12noon and I can't for the life of my shift this.
Every year as winter rolls in almost like clockwork it changes.

~~~
epiccodez
I have also noticed this, but maybe it's because in the summer we are more
likely to get outside and do something physical which makes you more tired and
thus more inclined to sleep earlier.

------
jph
Great idea. I'm often coding at 5 a.m. and that time is magically good for
flow.

Have you investigated the history of "second sleep" for clues?

Also try looking at polyphasic sleep, software like RedShift, and products
like the Zeo for ideas and people who like night/morning work.

------
anonymouz
Just pointing it out a little trivia:

"Programmers are machines that turn caffeine into code."

was probably derived from

"A mathematician is a device for turning coffee into theorems." (Attributed to
both Alfréd Rényi and Paul Erdős).

I believe it is one of the most famous quotes about mathematics (I hadn't
heard it's programming variant so far).

------
rytis
I wonder how this maps (if at all) to Ayurvedic cycles [1]? This one is quite
curiuos:

    
    
        Mid-night – 10pm-2am is again pitta time. 
        The fire element is strong, and the stars shine brightly. 
        Although pitta will give a spurt of energy and creativity one must avoid staying up into the late hours. 
        If one stays awake until after after 10 pm, the 
        active nature of pitta can prevent sleep. 
        It is the hours of sleep that one gets before 
        midnight that are the most rejuvenating.
    

[1] [http://flowingfree.org/using-ayurvedic-principles-to-live-
in...](http://flowingfree.org/using-ayurvedic-principles-to-live-in-harmony-
with-the-daily-cycles/)

~~~
fullmoon
I think that’s pretty obvious, the people that wrote that passage down, I
assume some time ago, were also of the same species and as such experienced
the same circadian rhythms.

~~~
rytis
If everything is so obvious then why the discussion here? Why the book?
Everyone here (I hope) is a human, so they must know their cycles, why the
talk then?

------
adrianhoward
More talking about the comments here than the book - but I'm seeing lots of
repetitions of the working-alone-vital and teleworking-vital anecdotes.

The thing is - I don't care about individual productivity. I care about
productivity of the business as a whole.

And on that point pretty much all the evidence I can find shows that co-
located teams in a war-room like environment are the most productive.

(And I'm saying this as somebody who spends a lot of their time working from
home, and talking to other folk over Skype, etc. There are reasons for
telecommuting - personal preference, getting access to people who cannot co-
locate, etc. But for business productivity I'm not seeing much, if any,
evidence).

Please not that I am not saying:

* Telecommuting is bad (I do it - I like it)

* Telecommuting projects will fail (D'oh - of course not)

* You shouldn't telecommute (of course you should if you want to - but bear in mind that the business may have good reasons to disagree with that decision)

* That telecommuting makes you individually less productive (I'm personally unsure about this. I feel more productive when working by myself, but I know that personal perceptions of productivity can be false. Measuring personal vs team/company productivity becomes hard in anything less than the short term)

* That co-location is always the best solution (it isn't - other factors like team location and skills come into play)

What I am saying is that there is a lot of research showing that co-located
teams in war-room like settings are _much_ more productive. This runs counter
to many developers preferences (mine too ;-) so it tends to get ignored.

So much more productive that solutions like 'Let's fly everybody to the same
place and pay their room and board for a month' can be cost effective.

Here are some references to the research (If anybody has any research that
contradicts this I'd love to hear about it. Especially if it talks about
actual measured metrics of productivity - rather that self-reported 'I felt
just as productive at home' ones.)

\----

"It doesn't take much distance before a team feels the negative effects of
distribution - the effectiveness of collaboration degrades rapidly with
physical distance. People located closer in a building are more likely to
collaborate (Kraut, Egido & Galegher 1990). Even at short distances, 3 feet
vs. 20 feet, there is an effect (Sensenig & Reed 1972). A distance of 100 feet
may be no better than several miles (Allen 1977). A field study of radically
collocated software development teams,[...], showed significantly higher
productivity and satisfaction than industry benchmarks and past projects
within the firm (Teasley et al., 2002). Another field study compared
interruptions in paired, radically-collocated and traditional, cube-dwelling
software development teams, and found that in the former interruptions were
greater in number but shorter in duration and more on-task (Chong and Siino
2006). Close proximity improves productivity in all cases." \--
[https://docs.google.com/a/quietstars.com/document/pub?id=1Jq...](https://docs.google.com/a/quietstars.com/document/pub?id=1JqRuCbjWs44SWCRzUhCDepc_dOr7BJG307dFe6Vn3-o)

"Based on the empirical evidence, we have constructed a model of how remote
communication and knowledge management, cultural diversity and time
differences negatively impact requirements gathering, negotiations and
specifications. Findings reveal that aspects such as a lack of a common
understanding of requirements, together with a reduced awareness of a working
local context, a trust level and an ability to share work artefacts
significantly challenge the effective collaboration of remote stakeholders in
negotiating a set of requirements that satisfies geographically distributed
customers" \-- <http://www.springerlink.com/content/0137yud7c3k8xryw/>

"Our results show that, compared to same-site work, cross-site work takes much
longer and requires more people for work of equal size and complexity. We also
report a strong relationship between delay in cross-site work and the degree
to which remote colleagues are perceived to help out when workloads are heavy"
\--
[http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?reload=true&#...](http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?reload=true&tp=&arnumber=919083&isnumber=19875)

"Our findings reveal that: software developers have different types of
coordination needs; coordination across sites is more challenging than within
a site; team knowledge helps members coordinate, but more so when they are
separated by geographic distance; and the effect of different types of team
knowledge on coordination effectiveness differs between co-located and
geographically dispersed collaborators." \--
[http://kraut.hciresearch.org/sites/kraut.hciresearch.org/fil...](http://kraut.hciresearch.org/sites/kraut.hciresearch.org/files/articles/Espinosa07-CoordinationInGlobalSWDevelopment.pdf)

"One key finding is that distributed work items appear to take about two and
one-half times as long to complete as similar items where all the work is
colocated" \--
[http://www.computer.org/portal/web/csdl/doi?doc=doi/10.1109/...](http://www.computer.org/portal/web/csdl/doi?doc=doi/10.1109/TSE.2003.1205177)

"Our study of six teams that experienced radical collocation showed that in
this setting they produced remarkable productivity improvements. Although the
teammates were not looking forward to working in close quarters, over time
they realized the benefits of having people at hand, both for coordination,
problem solving and learning.Teams in these warrooms showed a doubling of
productivity" \-- <http://possibility.com/Misc/p339-teasley.pdf>

"Despite the positive impact of emerging communication technologies on
scientific research, our results provide striking evidence for the role of
physical proximity as a predictor of the impact of collaborations." \--
[http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjourna...](http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0014279)

"Groups with high common ground and loosely coupled work, with readiness both
for collaboration and collaboration technology, have a chance at succeeding
with remote work. Deviations from each of these create strain on the
relationships among teammates and require changes in the work or processes of
collaboration to succeed. Often they do not succeed because distance still
matters" \-- <http://dl.acm.org/citation.cfm?id=1463019>

~~~
kamaal
>> I don't care about individual productivity. I care about productivity of
the business as a whole.

What follows from individual productivity is productivity of the business.
Unproductive people don't make a productive business.

>>And on that point pretty much all the evidence I can find shows that co-
located teams in a war-room like environment are the most productive.

Sure, but only as long 'collaboration' and 'communication' is what occupies
most part of the work. Which in the case it makes perfect sense. But if you
have all what you need, and you are sitting with 20 other people, working
alone at that point makes more sense.

War room teams work when a high degree of collaboration or 'piecing together
work inputs' is what matters.

If you are solving a tough problem. Or dodging a bullet, you will be
productive doing it alone.

~~~
adrianhoward
_What follows from individual productivity is productivity of the business.
Unproductive people don't make a productive business._

It's not about having unproductive people. It's about optimising the
productivity of the team/business as a whole rather than the individual. It
doesn't matter if I'm my most productive sitting in a dark room by myself at
3am if, by doing that, the rest of the team is blocked or going down the wrong
route because they need to talk to me.

 _War room teams work when a high degree of collaboration or 'piecing together
work inputs' is what matters._

So most software development then ;-)

 _If you are solving a tough problem. Or dodging a bullet, you will be
productive doing it alone._

Evidence?

------
shortlived
I was a midnight programmer until I had a family and more importantly kids.
I've always been a somewhat nocturnal person even before I programmed. Now
with a family I'm more of the early bird programmer, who starts working at
6am. You get the same peace and quit,,, but there is still something
different. Maybe it's that with mignight programming, you really can have a
long stretch and with early bird, you are limited to a relatively short period
before others start showing up on the radar. I think the pitch black of night
also helps.

~~~
gaoshan
I have always been a night person and in my case having kids did not change
that. I have a teen and a tween and still crank out the most code in the late,
late night. In fact, I probably get up later than ever (having a wife that is
an early morning person is, obviously, a prerequisite).

------
daurnimator
Hmm, I just used his punchcard thing @ <http://nightowls.swizec.com/>

And apparently I do 60% of my work on wednesdays.... wtf.

------
smallegan
I find that I am usually able to do the best critical thinking when I am more
awake but I can be the most productive in terms of cranking out code when I am
just tired enough that my mind stops racing. For me this period happens
between 11pm and 2am and it usually ends with me nodding off and holding down
a key or two. Undo is super important at that point!

------
JonnieCache
Very nice indeed. Looking forward to the finished product. However,

 _"Perhaps there’s just some worrying stuff going on and you aren’t Irish
enough not to worry about it."_

What does this mean? Never heard that expression. Anyway, aren't the irish
traditionally meant to be neurotic and guilt-ridden?

~~~
teh_klev
No, quite the opposite. Nothing is rushed in Ireland and there's a general
attitude of not really spending any effort worrying too much about things that
might be important to non-Irish folks.

------
DustinCalim
If you enjoy working at night and use Chrome, this extension has been a huge
help for me(and my eyes):

[https://chrome.google.com/webstore/detail/hacker-
vision/fomm...](https://chrome.google.com/webstore/detail/hacker-
vision/fommidcneendjonelhhhkmoekeicedej)

~~~
whimsy
Check out f.lux

<http://stereopsis.com/flux/>

~~~
DustinCalim
I tried f.lux and do not like it at all; I don't think color temperature is
the problem and my MacBook Air seems cheapened when it has a 1970s red tint to
the display.

Since using Hacker Vision, I notice that I can turn my display brightness down
to 2-3(again, a MacBook Air) which has the added benefit of giving me an extra
~40 minutes of battery life - very cool!

------
Joe_Pineapples
Personally I tend to get headaches when programming during the day. At night I
just feel more relaxed and able to think more clearly.

------
Ziomislaw
its because the black spots on the sun lower your skill in programming due to
cosmic radiation, so everybody program when the sun is on the other side of
the earth! easy =^,^=

------
batgaijin
"Because my brain is hemorrhaging during my day job."

