|
A friend of mine told me that at a very big company, the programmers were told they are expected to actually work about 60% of the time Added: She meant 60% of the time they were at work, they are supposed to work, the rest if spent on surfing the web playing pool or ping pong or whatever, chatting, etc. I think I'm at about 70% How much do you? |
|||||||||||||||||
|
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.
|
I work for a very large company, and I spend nearly 100% of my time working on projects. Most days I even work through my lunch. In my case, it is largely due to my team lead, who is very sharp and has high expectations for all members of his team. I prefer it this way though, I have had jobs where I was working about 60/40, spending a lot of time reading blogs, etc. The day goes by so much slower and is less fulfilling, IMO. |
|||||
|
|
On your first day: 99% |
|||||
|
|
For planning purposes, my team currently assumes 50% of my time will be spent actually working on tasks assigned to me (be it researching on StackOverflow, debugging, or actually typing code directly related to a task). The rest of my time is spent doing things like code reviews, helping others with particularly nasty tasks that are assigned to them, and even socializing with people (in the asker's words: playing pool, ping pong, chatting, etc). All of these things help us, as programmers, to do our actual jobs better. Code reviews familiarize me with sections of code that I might not otherwise have reason to ever see. This pays off six months down the line when I'm writing code that might have a nasty interaction that I hadn't initially considered, and I can check to make sure. Helping others helps the team in the short-term, by helping them get a task done earlier; but it also helps me in the long-term, by giving me a social lubricant ("leverage") in the future to get them to help me on my particularly nasty task. Socializing helps you get to know other people -- what they're good at, what they like to do, what they dislike to do, etc, etc. While this might not seem directly useful, it can give you great insights in to how others think: what to look for the next time you're code reviewing (if they hate SQL, pay particularly close attention to the SQL they're changing!). It also help you know who might be a good resource to get help from (if you're working on a tricky bit of UI, go talk to the best UI guy you know). The most important thing is to make sure you're socializing with a broad set of folks -- don't just restrict yourself to your own team -- hang out with somebody from another team completely separate from yours, make friends with on of the IT guys (he might prioritize unlocking your AD account next time you've forgotten your password!), make friends with the marketing department (they might give you a heads up when they start thinking about promising a feature that isn't in the requirements), etc, etc. |
|||||
|
|
This question came up at a former employer. They figured that they could actually expect 5 hours of development time out of an 8 hour workday. As John MacIntyre puts in it the comments: "if you're not goofing off, you're working." And even some goofing off is worth counting, as our minds need some time to refresh. |
|||||
|
|
60% sounds about right for me. I spend 40% or more of my work time reading blogs, stack overflow and other stackexchange sites, forums and guides that'll help me do my task later. I consider that as slacking off on my part but it helps me relax and do my job effectively later on. |
|||
|
|
|
It depends. I work 32 hours a week. Subtract 2 hours for meetings, leaves 30. 4 hours spend with customers service leaving 26 hours. Another (ok 2) hours for chatting and some internet stuff leaves 24. Subtract another hour for rebooting and compiling the system (23). 1 for interruptions of coworkers (22) and 2 for missing productivity because of blonde moments. Leaving 20 hours of coding,... except. Minus 2 hours of documentation and testing. Minus another hour for personal adminsistration (planning and time records) leaves 17. So about 50% of the time is spend coding. |
|||||||
|
|
I think it could be a misunderstood on a completely different thing. Maybe your friend was referring that, in big companies,usually people only works for up to 70% of their year working hours working directly on "outside" projects. That means time that is directly charged as part of a project that some client(s) has paid in some way. The rest of the time can be things like working for internal projects (projects that the company is not receiving income for), training, mentoring of other programmers, general management, installing their computers or cleaning viruses, filling boring internal forms, analyze and prepare offers or proposals for clients that lead to nowhere, etc. Those are assignments that cannot be directly charged for the company to anyone. There are ways of measuring that overhead, and it's more or less accepted that if the company it's getting more than 70%, people is either really overload with work or not doing homework (like making maintenance) Of course, I'm just somehow guessing ;-) |
||||
|
|
|
I currently work on a project for a large company through University. So instead of classes I go there to work on a project. The project has a deadline, so for the entire 3 months so far my time devoted to work is 100% of the allocated work day time, then even some more after work and on weekends. |
|||
|
|
|
I prefer to work 70% and rest to keep for learning new things. |
|||
|
|
|
I'm currently greatly enjoying the Pomodoro technique. The principle is to work in short atomic periods of time, the pomodoros, separated by small pauses, with a bigger pause each 4 pauses.With the default times, the cycle is as such 25/5/25/5/25/5/25/15 Ultimately, you work approximately 83% of the time. It's a very intense but non-frustrating and non-tiring configuration, BTW. Without the technique, I'd say I tended to get stuck between 40% and 60% when working on pure programming jobs. |
|||
|
|
|
Our team works between 9:30 AM till 8:30PM - 11 hrs, they spend 2 hrs for break. We were able to bill about 7 hrs per day. Their actual working ours is 8 hrs, as per our policy. But billing all the 8 hrs might not be possible. We work on Saturdays. So, total billable hours would be 42 hrs a week. So it comes to 63%. But the company average might be less than than. |
|||
|
|
|
There was a time when I could honestly say about 50%. However now that my career is advanced somewhat, I work (kid you not) absolutely no less than 100%. Why I spend a few minutes on sites like this is beyond me. Some may argue companies do not support learning in 100% expectation environments. Maybe they're right, but on each project (most all in parallel) I oversee 2-10 folks and I simply just don't have the time. Take care of East Coast and overnight work from India in the mornings, my customers for 8am-5pm then back at admin tasks and queuing up the next round for India at night through about 11pm-Midnight. About 15 hour days...so is that actually 180%+? |
|||
|
|
