The truth is that "programming & solving problems" is only ever a fraction of a programmer's job even at the coolest company. You'll always end up having to fir

The truth is that "programming & solving problems" is only ever a fraction of a programmer's job even at the coolest company. You'll always end up having to first figure out other people's code and data, coordinate teamwork, support production environments, refine expectations (a.k.a. finding out what "the real problem" is), document critical procedures, improve tooling, and so much other _stuff_. And it's totally ok, because these things can be fun too! And because when you finally get to write code, if you're just a bit smart, you'll consider these other aspects and give them appropriate care in the way you code, so that maybe things are easier for everyone in the long run. What steals the fun out of the profession is the process, whether it's agile or lean or whatever. Having someone breathing down your neck for every bit of work you do, trying to categorize and measure every activity into a rigid grid to try and demonstrate a form of control over a process that we all know is essentially organic, if not chaotic. Smaller workplaces generally have much less decorum but given enough time all will grow their own process. At some point you figure out that the ultimate "problem" is always of human nature. The code you are paid to write and the problems you are paid to solve are _not_ yours. And that's precisely why you're getting paid.