5 ms·

It's a problem that's hard to solve: since the amount of work ebbs and flows, how do you keep your staff busy for 40 hours a week? Some companies drastically o

by IvyMike 12y ago

It's a problem that's hard to solve: since the amount of work ebbs and flows, how do you keep your staff busy for 40 hours a week? Some companies drastically overcommit on a permanent basis, so that 40 hours is the minimum anyone's ever scheduled for, and when there's a lot of work, everyone's on massive overtime. These jobs can suck--these are the ones where you can end up working 100+ hour weeks on occasion, and 80+ hour weeks for months on end. Ironically, I find these are also the places where people are most likely to "look busy" in an attempt to protect themselves. Some companies overcommit on a short-term basis, but make an attempt to average 40 hours in the long term. A lot better, and way less likely to burn people out, but still periods of suckiness. But there's a lot less need to look busy--and there will be periods of undertime, where people are just kind of dicking around. The best job I ever had, the manager attempted to commit to 40 hours of work during peak times. But during down times, instead of letting us idle, he had us actively work on infrastructure and self-improvement. Build better tools, evaluate new tools, benchmark things, upgrade things, document things, etc. He was good at making this productive, and not "busy-work" (which is the pitfall). As time went on, these investments paid off, and we got faster and better and our 40 hours of work went a long way. And as far as I can tell, nobody ever attempted to "look busy", as the actual job was enjoyable. Sadly, this could not last, and when the dotcom crash took us down the group was dissolved. :(

ma2rten 12y ago
I don't understand this post. Either you work for a consultency-type company that develops products for customers, but those don't really have infrastructure, right? OR you work for a company that has it's own product, in that case, you can always work on more features or there are more bugs to fix.
- IvyMike 12y ago
  Think of "work on infrastructure" as "work on developer-centric features" and maybe you'll be happier? Also: "Always work on more features" can be a pitfall, and it's why Zawinski's law of software envelopment exists. Any feature you add can end up costing in future maintenance and difficulty in making future changes. Another thing we did during the "work on infrastructure" times was delete unused features. I was working on a 12 year old code base so there were actually a lot of those.
- ddoolin 12y ago
  Just because there's work to be done within the company, though, doesn't mean every worker has related tasks assigned to them. In that case, they end up on someone else's desk. Happens at most of the places I've worked as well...work comes across my desk a few months out of the year. The rest is "easy going".
- deleted 12y ago
  [deleted]
- nilkn 12y ago
  In a company of any complexity there are going to be projects that can't really be tackled by one person in total isolation. Whenever explicit teamwork and collaboration are required, scheduling conflicts become possible.
  - neolefty 12y ago
    > The best job I ever had, the manager ... during down times ... had us actively work on infrastructure and self-improvement. It sounds like there was some coordination & direction going on -- it didn't just happen automatically.
- mvc 12y ago
  > Either you work for a consultency-type company that develops products for customers, but those don't really have infrastructure, right? Thoughtbot strikes me as a "consultancy-type" company that has taken time out of billable hours to build infrastructure in the form of a bunch of open source libraries.
- antimagic 12y ago
  Here's an example scenario - you work in a product company, but the company lives and dies by big, custom contracts. My personal field of experience is set top boxes. Typically you sell big orders to a telco. When one of those contracts is rolling out, it's all hands on deck. Engineering, obviously, but also marketing and design. The problem arrives when you deliver. The product goes out the door after a crunch, and then... crickets. Marketing doesn't have any new direction that they want to take the product - they've been so busy holding the big client's hand. Design doesn't have any tweaks that they want made to the base system - they too have been deep in the design language of the big client, and haven't yet started to think about where they want to go next. The result is that Engineering find themselves with nothing to do, at least as directed by management. In the better-run companies, this is the moment when the line managers start pushing out improvements to tools, cleaning up technical debt and so on. In the less well-run companies, each engineer is left to their own devices. Unfortunately you probably can't do any of those technical-debt type problems. Most of them are large jobs - that's why they weren't done in the push to get the product out the door. And nobody wants to waste time doing half of a non-sanctioned task, just to get dragged off to do something else when an urgent bug pops up, or marketing and design wake up from their post-crunch torpor. So you see a lot of fiddling around - unimportant re-factoring of code, some half-hearted doc work etc.
seivan 12y ago
Software Engineering is one of those jobs. "Lets set a Deadline at X"
DanBC 12y ago
Recent ruling in England makes asking your non-salaried staff to routinely do overtime a bit more tricky: businesses now have to include that overtime when they calculate holiday pay. My work experience pretty much was the opposite of yours. During quiet time I was not allowed to help anyone else (I would be un-busy while they'd be overflowing with work, for which I was qualified and experienced). I was to sit at my desk and look as if I was working, even though everyone knew and accepted that I wasn't. It was v. frustrating.
nraynaud 12y ago
there is a whole fascinating theory around that in E. Goldratt books. Basically the maximum output of a system is never when every component is at its max output, but when its constraining component is at its max output capacity, all the rest needs extra capacity around to pick any slack in the system to try to keep the constraining component at its maximum. If the constraining component itself has a hiccup, you're still trying to get the surrounding components not to add their own hiccup in the output, they have to pick their own slack.

by IvyMike 12y ago

ma2rten 12y ago

I don't understand this post. Either you work for a consultency-type company that develops products for customers, but those don't really have infrastructure, right? OR you work for a company that has it's own product, in that case, you can always work on more features or there are more bugs to fix.

IvyMike 12y ago
Think of "work on infrastructure" as "work on developer-centric features" and maybe you'll be happier? Also: "Always work on more features" can be a pitfall, and it's why Zawinski's law of software envelopment exists. Any feature you add can end up costing in future maintenance and difficulty in making future changes. Another thing we did during the "work on infrastructure" times was delete unused features. I was working on a 12 year old code base so there were actually a lot of those.
ddoolin 12y ago
Just because there's work to be done within the company, though, doesn't mean every worker has related tasks assigned to them. In that case, they end up on someone else's desk. Happens at most of the places I've worked as well...work comes across my desk a few months out of the year. The rest is "easy going".
deleted 12y ago
[deleted]
nilkn 12y ago
In a company of any complexity there are going to be projects that can't really be tackled by one person in total isolation. Whenever explicit teamwork and collaboration are required, scheduling conflicts become possible.
- neolefty 12y ago
  > The best job I ever had, the manager ... during down times ... had us actively work on infrastructure and self-improvement. It sounds like there was some coordination & direction going on -- it didn't just happen automatically.
mvc 12y ago
> Either you work for a consultency-type company that develops products for customers, but those don't really have infrastructure, right? Thoughtbot strikes me as a "consultancy-type" company that has taken time out of billable hours to build infrastructure in the form of a bunch of open source libraries.
antimagic 12y ago
Here's an example scenario - you work in a product company, but the company lives and dies by big, custom contracts. My personal field of experience is set top boxes. Typically you sell big orders to a telco. When one of those contracts is rolling out, it's all hands on deck. Engineering, obviously, but also marketing and design. The problem arrives when you deliver. The product goes out the door after a crunch, and then... crickets. Marketing doesn't have any new direction that they want to take the product - they've been so busy holding the big client's hand. Design doesn't have any tweaks that they want made to the base system - they too have been deep in the design language of the big client, and haven't yet started to think about where they want to go next. The result is that Engineering find themselves with nothing to do, at least as directed by management. In the better-run companies, this is the moment when the line managers start pushing out improvements to tools, cleaning up technical debt and so on. In the less well-run companies, each engineer is left to their own devices. Unfortunately you probably can't do any of those technical-debt type problems. Most of them are large jobs - that's why they weren't done in the push to get the product out the door. And nobody wants to waste time doing half of a non-sanctioned task, just to get dragged off to do something else when an urgent bug pops up, or marketing and design wake up from their post-crunch torpor. So you see a lot of fiddling around - unimportant re-factoring of code, some half-hearted doc work etc.

seivan 12y ago

Software Engineering is one of those jobs. "Lets set a Deadline at X"

DanBC 12y ago

Recent ruling in England makes asking your non-salaried staff to routinely do overtime a bit more tricky: businesses now have to include that overtime when they calculate holiday pay. My work experience pretty much was the opposite of yours. During quiet time I was not allowed to help anyone else (I would be un-busy while they'd be overflowing with work, for which I was qualified and experienced). I was to sit at my desk and look as if I was working, even though everyone knew and accepted that I wasn't. It was v. frustrating.

nraynaud 12y ago

there is a whole fascinating theory around that in E. Goldratt books. Basically the maximum output of a system is never when every component is at its max output, but when its constraining component is at its max output capacity, all the rest needs extra capacity around to pick any slack in the system to try to keep the constraining component at its maximum. If the constraining component itself has a hiccup, you're still trying to get the surrounding components not to add their own hiccup in the output, they have to pick their own slack.