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.
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.
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.
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".
> 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.
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.