Show HN: v0.1 of my book "Why programmers work at night"
leanpub.com
leanpub.com
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.
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.
Don't know why he hasn't mentioned this, maybe he just hasn't come around to writing about it yet.
disclaimer: I'm one of the guys he interviewed.
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).
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.
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.
What contributes to these highly productive periods? How do you consistently get yourself "in the mood" to be productive? Do you find yourself getting distracted at all (i.e. the internet, music, news, etc.)?
> Apart from a breakfast break at 8 AM. What do you eat for breakfast? What does your breakfast period look like?
Avoiding distractions really is a matter of self discipline. I think the best time to check HN/twitter/FB is when you totally tired, not when you are fresh and full of energy.
I generally eat fruit + milk + cereal for breakfast.
However, I dispute that it's the best way to work. It puts a larger overhead on communication. I've noticed that extended periods of working alone cause development to drift away from the core requirements because of this.
I find what works for me is being in the office most of the time. It allows you to pick up on a lot of stuff that you just can't do when you're not there.
If the rare occasion comes where I need no distractions to blitz out a ton of code, then I arrange a day to work from home.
You must have super levels of concentration and be able to quickly recover from my context switches.
In my case, Meetings fundamentally imply a good chunk of the day goes into doing nothing.
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
We're thinking of making the slider exponential (or something with an increasing slope, anyways) instead, which would help.
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.
"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
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!
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...
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.
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.
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.
"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).
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.
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...
"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&#...
"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...
"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/...
"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...
"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
That said, the "war-room environment" is fraught with connotations that just scream "inept management" to me. If your developers are under that kind of stress for long periods of time, you're doing it wrong, and you're deleteriously affecting not only their personal productivity, but the team productivity as well.
If your developers are under that kind of stress for long periods of time
In these papers 'war room' is just shorthand for 'people working together on a project in the same room'. Also called 'team rooms' and 'radical colocation'. Not meant to imply stress in any way. Quite the opposite if anything. Would have used another term if I'd though about it.
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.
You are still able to be productive, you just might not feel like you are as productive as you could be. But as a whole, the producitivity of the team increases, while individual productiviy may decrease. Just my experience for what it's worth
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?
If you're building a product, that's a different kind of job and needs a different environment.
This isn't about emergency situations. It isn't about burning resources. It's about normal sustainable work.
I'd encourage you to dig into some of the references and see what you think.
If you're building a product, that's a different kind of job and needs a different environment.
The evidence from pretty much all the research that has been done would seem to differ. My personal experience has also been that the best products are built by teams working that way - so I have some anecdotes too ;-)
Pretty much all the evidence to date says development work is most productively done when each developer has a private room (whether office or at home) with a door he can close, and when face-to-face interaction is something that can be done as appropriate instead of being forced all the time. See 'Joel on Software' for more extensive discussion, references etc.
Can you please point me to the evidence that this set up beats team rooms? I would, quite seriously, love to see it.
I've seen Joel talking about it. I've seen lots of anecdotes. I've seen evidence that it works better than, for example, cubicle farms and other non-team-room types of work environment.
But I've not seen anything past anecdote that it beats team rooms.
I was more or less automatically combining that with the observation that I personally would have a better chance of getting programming work done even in a cubicle farm than in a war room
Out of curiosity - have you ever spent any significant time (more than a couple of works) working in one?
I ask because that was exactly what I thought I would be like. Instead I found it to be very productive and enjoyable. It also seems to be a common reaction from developers who've not tried it. It's mentioned in one of the papers:
"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." - http://possibility.com/Misc/p339-teasley.pdf
Of course this kind of thing is also complicated by reactions varying greatly with where you are on the introversion-extroversion axis; programmers are on average more introverted than the general population, but still vary all over the scale.
Kind of... a period of adjustment certainly. Switching from 'me metrics' to 'team metrics' for success took a little time to internally grok.
Of course this kind of thing is also complicated by reactions varying greatly with where you are on the introversion-extroversion axis; programmers are on average more introverted than the general population, but still vary all over the scale.
If you're the sort of person who takes MBTIs seriously (I'm not ;-) I'm INFJ - and pretty far into the "I" as I recall.
And apparently I do 60% of my work on wednesdays.... wtf.
"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?
https://chrome.google.com/webstore/detail/hacker-vision/fomm...
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!