|
At my company, I find that there are some days that there are very few tasks to do. I make it a point to do research to learn new things about my craft on these days. I would say that on average, I have about one day per week that there is not much to do (or some combination of time over the week). I would like to know if this is a common situation in software development environments, and does the answer to this question vary between full-time and contract work. |
|||||||||||||
|
|
Yeah i would say that there can be alot of downtime if you end up in a situation where you are waiting on a response from a client or manager about how to proceed when you come across a design issue. Another instance is when a server crashes in your dev env and you can't continue development until it has been resolved. One last situation i've experienced downtime (as a consultant) when there was a weird gap between when one project ended and the next began. That being said, I also believe it is a sign of bad management when your workers are not fully utilized. You should have other tasks that should be able to work on in case the server crashes. Typically at my company if we hit a roadblock with something we go an update the project wiki and or go and do assigned learning (everyone has a specific topic they are suppose to be learning in downtime). In regards to the contract and salaried employees, I find that the salaried employees have more downtime and contract/consultant workers, but that is merely the case of contract workers having a higher cost to the company and only bringing them in when you have need for more/specific programmers. From what you are saying, it looks like you have 20% downtime, which is a lot and would hint at poor management. |
|||
|
|
|
In my experience, it depends entirely on the industry and who is leading the project. Something tells me that the answers to this question will be strongly biased since the only people with the time to read and comment on this site are those without much work to do. In my past job, there was NEVER downtime. It had a lot to do with how well projects were decoupled and organized. If not well organized, working multiple projects at the same time can lead to problems when trying to merge changes and it's actually more cost effective to do nothing for a bit than to overcomplicate matters. |
|||
|
|
|
In my company I get a couple of weeks like that(yes weeks) for every two months or so. I am not sure if being weeks without work is common, but yes, you could always improve yourself during free time. |
|||
|
|
|
In my workplace we get downtime when:
When downtime is shared, which for me is about 5% of the time, I usually go talk to people, get my head off things, hear some jokes. When I find myself with nothing important to do, I have a directory with tons of books, which I read when I'm allowed, or in between long compile (or something equivalent) sessions, etc. But even though I do this, I have to acknowledge something (which does make me a sinner myself): It's our job as programmers to develop our careers at home so that our boss wouldn't fire us or something like that. It's not the boss' job to let you improve yourself with his money (time he's paying you for). But anyway, as an alternative, sometimes instead of reading I do some other stuff,such as come up with some useful scripts or ideas, write documents and presentations about methodology improvements, etc. That also counts as self improvement because it makes you think, and makes you useful to other developers, who might even remember you for that some day, when it counts. But the important thing is that it's worth the money you're paid better than reading books... |
|||
|
|
|
Most downtime I've encountered is usually on Financial year-end and/or end of the year (December season, as most customers goes on holiday). Company "closes" for various reasons and IT has no deployments for 2 to 3 months. Therefore, there is no changes. It does happen: During this time, we evaluate all the changes/projects undergone in the year, find out where we improved or lacked and find a solution to improve better for the next season/term. Don't feel worried. |
|||
|
|
It is common in industry, but if a team is managed well, then the managers should have a readily available 'pipeline' of in house and/or lower priority projects that can be assigned on demand. These will ideally involve newer technologies and/or libraries. In my experience assigning people to work on code documentation or updating wikis is not well received by developers, who by nature are normally happier when actually developing something. Another approach I've seen is to send people on full-time training courses of up to two weeks at a time, for upskilling the development team with knowledge that will be needed in the future. Generally if you're a contractor and find yourself without active work at a company then you'd better start looking around for another position, because you will probably be the first one to be let go if the company hits a downturn. |
|||||
|
|
From my experience, it is relatively common. Although we used to have - free with nothing to do - days usually after the completion of some phase of the project, when it is being evaluated ... it would usually last up to a week or so even, before we got an answer from them, and then continued our work on the project. Can't say whether this is a practice in the whole industry, though. |
|||
|
|
