Cultivating your relationships professionally is also "work", as is talking to your customers, reviewing and discussing code, writing about and showing others what you've built, keeping your resume and interview skills sharp, staring up at the ceiling and thinking about work, etc.
Maybe this is an unfair parallel, but I cannot see why.
So even if you find a boss/employer that is supportive of “the fun stuff” for a season, that will eventually come to an end.
Rare? Absolutely, but so is finding good people in general. Gather whatever signal you can, and keep rolling the dice, just as you would with friendships and romantic relationships.
You also should spend a portion time learning as it enables you to create more value over time.
And yes you should take time to get to know your colleagues, take breaks, play ping pong, etc. This helps you refresh yourself and avoid running out of steam.
But the work is meant to create value, hence why you are rewarding with currency you can exchange for things you value.
Manage a positive work life balance and and do the "fun" stuff outside of work. Life is not all work and work is not all of life.
That makes sense as long as it also matches the employee's goal of being paid for the work they do. If you work at a place like my job, you will never be promoted if you do this necessary behind the scenes stuff. It's as if the motto is "if the business user doesn't see it, it never happened". Sucks if you're spending a lot time on things that are supposed to be invisible to a user, like security or availability.
In terms of developer productivity, it all depends on management's assumptions built into their labor model. If you are paying top of market for "A players" who do "10x," the company might need the few engineers it has to do a huge/unsustainable amount of "focused work"
If management's model depends on high-potential team members upskilling on the job, "the fun stuff" might just be priced in.
The above are absolutely reductive and do not cover all cases.
You interview your boss in the interview process and get a feel for what type of preson he is and then go with that gut feeling yes/no
when your current boss leaves and you get a new boss that you don't like. Quit and go back to step 1.
Does anyone operate like this? doesn't seem very practical or foolproof.
If you accept the above as true, then you can start to reach out to team members at the company and ask them what the work environment is like.
If the work environment lines up with your values, then you'll probably be fine, even when the hiring manager moves on to greener pastures.
I've been asked this when i interviewed ppl but i never gave them the truth and I've never gotten any honest truth when i was on the other side also.
People in the interview are under scrutiny and don't want to be responsible for driving away candidates
Really good people are hard to come by in this market (need to be not just smart but also easy to work with, communicate etc), so you better don't express dissatisfaction, otherwise they go to a competitor.
It's really hard to get honest opinions before accepting an offer. You have mostly gut feeling to go by, maybe join a team for a coffee break, this kind of thing. A direct question "what do you like least about your job?" could work too (it's kinda "what's your biggest weakness?" in reverse), but often times that's also just used to upsell or BS you, e.g. "the food here is too good, I'm getting fat". But you can try to read between the lines of course.
It's doubly frustrating because it's always there, and drives so much inefficiency _in the name of_ efficiency.
Were you working at an agency or consultancy that billed hours to clients?
I've never seen a good engineering organization use time tracking software on their engineers.
I'd go so far as to take it as a major negative sign against the company if your time is being tracked like that. Exceptions of course to any business that is billing hours, which obviously must be tracked. However, even those organizations are smart enough to know that writing code isn't the only productive activity.
At least, in Scrum, from my experience so far: pointing is about measuring the uncertainty to delivery, but should healthily include learning, tech debt refactors,testing, q/a, even unexpected stuff like dev churn (i.e shoot under always, over estimate slightly).
But if individual performance is measured by velocity and points, you will just get devs badly cutting corners and gaming it while project & product will never get accurate measurements they can tie time based business outcomes to (especially as you get further out and short term corner cutting starts to rear it's head as brutal Tech Debt and time sinks)
This is an exchange in a market. If Best Buy wants $500 for that new TV, would you go in and offer them $750 for it? If Wal-Mart will sell you the same TV for $400, consider going there isntead.
A fun side story is when I got a new manager a while back. In our first one-on-one, he told me that he has connections through the company and can use them to get me promoted to another team if I make him happy. I get that making the boss happy is part of a job, but that should be accomplished by doing good work. This direct proposition just felt too quid pro quo and had a stink to it, in my opinion.
I think engineers can become obsessed with MinMaxing the wrong, purely local optimum without thinking: "what work-adjacent things might lead to a CTO role in five years?" and this is often quite a different question than "what makes Mr Shankly happy in this quarter's performance review?". Yeah, if your immediate boss thinks you're useless and sacks you then your overall profile might not help much but being an invisible cog in the their team will only improve the esteem that they hold you in and not your larger professional reputation.
Did "the bosses" reach their own positions by closing the most tickets every month? I kind of doubt it and it is worth distinguishing what makes you useful to them vs puts you on the path to join them. If that seems overly careerist, well fire up Jira and get another bug sorted after dinner.