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.
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.
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
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.
Agree 100%. We assume as programmers that because we learned something that is intellectually challenging, that means we have a license to explore other areas of science. Sometimes that works, but sometimes it simply doesn't.
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).
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.
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.
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.
> 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.
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?
Basically no external distractions is what contributes to scoring most productivity points at that time. I also pick and do the most interesting pieces of work first in the morning.
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.
I agree that working from home requires you to have a clear list of tasks to complete.
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.
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
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.
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).
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.
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!
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.
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.
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.
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.
I wasn't disparaging the "better at night" programmers ... why should you switch if your work habits are right for you? In fact, I'd rather not talk anyone into switching as that would mean more people up early and less quiet for me.
Sorry to follow-up a day later, but another HN post seems very relevant ... the article linked to this post describes a gene that determines whether you're an early-riser or not. Perhaps not to the extent of the difference between morning and night programmers but with at least an hour of variance.
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.
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.
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.
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.
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?
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...
"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...
"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
This is quite sensible; if my manager is leaning over my desk asking for that TPS report, I'm more likely to drop what I'm doing and give it to him than if he's asking from 20 miles away. In the latter case, I can tell him I'll e-mail it to him, and buy myself time to get to a natural breaking point. Multiply that by however many people are on your development team, and the manager has to wait all day to get his TPS reports. There is a significant distinction between personal productivity and team productivity, and the wise manager knows how to leverage the former to increase the latter. It bears repeating that the wise programmer knows that he must occasionally sacrifice the former to enhance the latter as well, if he hopes his employer will continue to give him lots of money for having fun with computers.
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.
It's not just about management either. It's about the whole team. It's about fixing that problem your teammate has. It's about noticing that person who's been looking puzzled and them being to make eye contact for immediate help. It's about avoiding miscommunication. It's about spotting problems before they get serious.
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.
>> 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.
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.
>> What follows from individual productivity is productivity of the business. Unproductive people don't make a productive business.
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
'War room' is a good description - that kind of environment is designed, and well suited, for 'all hands on deck' crisis management where everything has to be thrown into dealing with the current emergency; you don't care about burning tomorrow's resources today because if the emergency isn't dealt with, there won't be any tomorrow. If that's the kind of job you're doing, then yes, that's the most productive environment for it.
If you're building a product, that's a different kind of job and needs a different environment.
I think you're misunderstanding what people mean when they're talking about 'war room' environments. It's just about having everybody related to a project working together in the same room. The sort of thing agile folk talk about as 'team rooms' and what the CSCW folk call 'radical colocation'.
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 ;-)
No, I understand perfectly well what you mean, and I'm disagreeing. I'm pointing out that a war room environment works well for an emergency situation where you don't care about burning resources, and very badly for normal sustainable work.
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.
Pretty much all the evidence to date says development work is most productively done when each developer has a private room
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.
That is a fair point. The statistical data I've come across compares private offices with cubicle farms, and 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, but I don't remember offhand having seen actual studies comparing private offices with war rooms.
Darn. Some counter examples would have been interesting.
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
... actually my last comment isn't true, thinking back, yes I did work in a war room setup for a couple of summers back in the eighties, though it wasn't called by any particular name back then, nor had I started thinking about working environments as a topic at all, so I hadn't really connected it with this discussion. It was suboptimal but tolerable because I was a teenager with lots of energy to spare, and honestly the code I was writing was bread-and-butter stuff that was far enough within my capabilities that it didn't need absolute concentration.
I'll admit I haven't. Are you saying you found it sucked for the first couple of weeks but after that you adapted to it?
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.
I'll admit I haven't. Are you saying you found it sucked for the first couple of weeks but after that you adapted to it?
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.
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.
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).
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!
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.
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!
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 =^,^=
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.