> completed all tasks assigned to them for the week by noon or so on Monday and spent the rest of the time writing libraries to abstract away the "rough edges"

> completed all tasks assigned to them for the week by noon or so on Monday and spent the rest of the time writing libraries to abstract away the "rough edges" This doesn't sound all that productive to me, but it's understandable someone would think this is wanted early in their career. It does vary from place to place depending on how much legacy code there is. It sounds like the kind of code everyone else would complain endlessly about and label as technical debt. They left a mess for others to clean up on the implementation side (the part bad managers care about; getting things "done") and preferred writing libraries they can wield for clout (the part that looks "smart" to their boss's boss). This is the impression they will leave with other junior devs. It's just the way it is. In my opinion a good manager would prefer the developer to pick one: either focus on the implementation side or on the architecture side, but not both. These tasks need to be separate so that the abstractions aren't so... worthless... to every other project. Abstraction for the sake of it is so much harder to read than just writing the code the "naive" way. You can't really know how general you need to be unless you're truly spending all your time looking at everything else as an architect.