Vrftjkry

The main question is why they (or anyone) should be in the office at 9:30. Do you (or the customer) need to contact the developers in the morning?

Fixed schedules are mostly to make sure that people can be contacted or can meet each other and so closed groups only need to find a time that works for them.

I also don't think they have fewer constraints. They just have different constraints. You could also formulate your questions as "Why do developers have to stay so late in the evening when everyone is allowed to leave earlier"?

Might be multiple factors, including:

1. They work later in the evening.


2. Development is creative and mentally exhausting work so efficiency typically start to go down somewhere around 4-6 hours. By having more time to rest they might actually be more effective by working fewer hours.


3. If they get paid enough they might accept a pay cut to work less hours, getting more time to ... not work.


4. Some devs (usually contractors) get paid for finishing their tasks on time. Why then stay in the office longer than necessary?


5. In some circles this is part of the culture, I have definitely heard it from multiple people. Usually revolving around my points 2 and 3.

My company is similar, we have a dev team that can show up between 7am and 10am and leave between 2pm and 6pm, roughly. Our CTO focuses on accomplished tasks not really hours worked. That's not to say hours don't matter, but the key metric revolved on product completion, not time spent on product. The time spent metrics are typically used to deciding how much more work we can take on as a firm. But outside that, we're expected to just do our work. The sales / marketing / management side of the office are in at more stable times because their jobs requires them to be in during business hours.

Keep in mind, sometimes developers need to "percolate" their solutions. When it looks like their doing nothing or if their not in, it doesn't mean the problem isn't being worked on. I can't tell you how many times I've worked through a problem while in the shower in the evening... But that's sort of the nature of the beast.

The point here, is the development position has a lot more flexibility because software construction allows for the flexibility. Also, because that's the case, it allows firms to offer flex hours which is always welcome. Since the knowledge economy is about autonomy, mastery and purpose. The more autonomy someone has in doing their work the better and since software is the product, then making sure the people who build it have the flexibility (in terms of time) to think about it, the more likely you'll be able to deliver something worth selling.

Depends on the company. Dev work in general can be done remotely - it isn't unheard of for people to start the day at home, then drive in to the office and finish the day there or vice versa. In the company I'm currently working in, this is actually quite common.

It isn't unusual for devs to have to work late - I've been in the office from 9am until 3am and back in again at 9am when there was a critical issue which needed to be fixed to get the company back on its feet. Similarly I've also worked 70+ hour weeks for fairly short stretches when something had gone terribly wrong.

Lastly, it could be that customers or team members could be operating in a different timezone and so the dev team is synching with those working hours - for instance I'm in Europe and work with people in both India and the US. The Americans are in early, and the Indians are in late so we can have a team meeting together.

The above can lead to management taking a more relaxed attitude to hours in office.

Developers tend to prefer to come in late and work late. We tend to be an independent, introverted bunch. Things that a normal person would prefer to do face-to-face, we often prefer to do via email.

Personally, I have found that if I get in to the office mid-morning, I do what interaction is necessary (meetings, dealing with email, etc.) before I eat lunch and then get down to the actual work by getting into deep hack. Much of my best work has been done well after 5 when the office is quiet.

It often starts unintentionally. When you become very absorbed in a problem and suddenly look up from your computer to find that it's 10PM, you're not terribly motivated to be in the office early the next morning. You get to work later and find yourself still at the office at 10PM again the next night.

Managers accept this from developers who deliver the goods. You can get a measure of how good a developer is by how flexible his schedule is.

The Tao of Programming has an illustrative passage:

A manager went to his programmers and told them: ``As regards to your work hours: you are going to have to come in at nine in the morning and leave at five in the afternoon.'' At this, all of them became angry and several resigned on the spot.

So the manager said: ``All right, in that case you may set your own working hours, as long as you finish your projects on schedule.'' The programmers, now satisfied, began to come in at noon and work to the wee hours of the morning.

The Tao of Programming 6.4

Also may depend on the local.
For example, in the Los Angeles, CA city, traffic is horrendous. Developers came in anywhere from 6:00 a.m. to Noon; to avoid the traffic.

I remember the manager calling all of us to a meeting and basically said he didn't mind us coming in at different times, but wanted to know a time when we would all be in so he could schedule meetings.

The answers above are excellent. I am just adding my own observationnal experience.
This tendency is not only found in the software industry. When working temporarilly in an industrial company (metal coating), the technicians in charge of production chains (who were basically self-reliant) came in at 5-6AM and left in the early afternoon if all went well.

The main points for why this arrangement worked are:

• They were always there for at least some of the normal office hours.


• They were output oriented, although there was a system of punching in and out.


• There was enough direct communication so that everything ran smoothly (just 1 small site)

As a dev myself, if I can't think, I can't code. Sleep is vital; being "on time" could mean wasting a work day. Some devs can show up at 7; I wake up at 5; it depends on many things. The question should be whether they work late in order to finish and if they get the work done on time.

Also, about your request for "study on this managerial issue", this may relate to the academic topic "Working with Talent"; search Google and Amazon.

And, thanks for asking about this, also everyone for great answers. Lots of good value here! This Question can help many, many people get along better

[Some teams]

arrive between 9:30am and 10am.

[other teams]

arrive between 11:30 and 12pm

The constraint in both cases is "30 minutes". All teams obey precisely same constraint.

Do dev teams put less constraints on themselves or have they less constraints in terms of work hours?

The example you've brought proves they don't.

As a developer who works very irregular hours, the reasonings are numerous, but all of them are valid:

Long commute times

Arriving later avoids major traffic jams. Example: Spending 30 minutes in traffic vs. 30 minutes at home then leaving later avoiding traffic jam means I can spend 30 minutes at home productively.

Poor office environment

Noise disrupts development work badly. Arriving later and staying later means you can catch a quiet period as people start to leave.

Lack of reasonable justification

Not attending on time is more beneficial, and most 'on time' arguments are 'because I said so'. I'd attend emergency meetings, but if it's more productive to be late or flexible, then I should be.

Developers already 'works' outside of hours

Managers might feel 'ripped off' by late arriving devs, but developers are still thinking of the problems and solving them outside of hours. In one case I came up with a solution in a dream at night - do I bill you the 8 hours? Being reciprocal in flexibility works both ways.

Majority of development work (for me) is mental

Externally, I might look like I'm procrastinating (videos, Stack Exchange, irregular hours, etc.), but I'm giving my brain fuel (external input) for creativity and keeping it in good condition (lowering stress).

Before writing any code you have to design it first. Any stressed mind is not going to work ('Ugh, they're still playing that awful music!').

It's no different to how I'd normally work (as a hobbyist)

Tackling my own development problems, I behave the same way. I don't force strict times, nor force myself to keep hammering away at a problem. Going away, destressing, and talking about it, gives me the room to think of solutions.

Externally, it looks unprofessional in a work environment. But it's always gotten me results.