eh, that's not really the case in a lot of developer jobs these days. A lot of agile/scrum adoption/bastardization has meant that all work done has to be decided by the team and pretty much every piece of work has to be approved by a product manager. This can often lead to some demoralising meetings where you can either lie about the effort/risk/goal or you can give a true value estimate that gets shot down. If you lie, you can end up spending your own free time working on that refactor or documentation etc. For most devs working on a codebase, its not theirs, and they don't determine what has priority.
In reality, for a lot of people, if you start refactoring the codebase while waiting for a new task you are likely to break something and its just not worth the hassle for the developer or the company.
Learning new tools is always great ofc but it can be very hard to find the motivation in such a role, where unless you are a senior developer, you probably won't have much say on adoption, and you will likley just develop a half baked understanding of a new library that you will never get to use in production. Its much better to have some real free time where you can focus on your own projects and learn that way.
So in short, maybe it should never be the case that devs are in that position, but it often is. Especially for devs with less experience
That’s pretty sad and disempowering. For what it’s worth at companies like Facebook it’s completely the opposite. If you aren’t taking any initiative you will not meet expectations at performance review.
I just had a good chuckle at this. I’m skeptical, to say the least. I don’t have direct experience. But I do work at a company that has poached several FAANG employees this past year and whose thoughts...differ from yours.
I can second dkasper's observations -- the PSC cycle is engineered to reward initiative. That said, depending on the team, the practice does not always follow the theory, so it makes sense that the FB employees your company could poach may have been the ones unsatisfied with the way their team rewarded initiative.
Kent Beck became a former Facebook employee because he wasn't in to proving he was moving the needle on Facebook's key metrics. He was only giving world class mentoring to young Facebook engineers and improving the development culture.
Likely you were able to poach them since they didn't thrive in that environment. Or you got them from the more traditional top-down Microsoft, Apple or Amazon.
That sounds like academia, where people are also expected to be constantly innovative on demand and, when the majority just can't pull it off, they invent BS research and produce worthless papers which clog the system.
> if you start refactoring the codebase while waiting for a new task you are likely to break something
The risk of this is in proportion to the lack of test coverage. If you are afraid to refactor, this should be an indication that you need to apply more test coverage, so do that first.
In reality, for a lot of people, if you start refactoring the codebase while waiting for a new task you are likely to break something and its just not worth the hassle for the developer or the company.
Learning new tools is always great ofc but it can be very hard to find the motivation in such a role, where unless you are a senior developer, you probably won't have much say on adoption, and you will likley just develop a half baked understanding of a new library that you will never get to use in production. Its much better to have some real free time where you can focus on your own projects and learn that way.
So in short, maybe it should never be the case that devs are in that position, but it often is. Especially for devs with less experience