You can't heads-down slam out code for 8 hours a day 5 days a week. Be responsible with your time and use it to push forward the vision & mission of the company by taking your professional development into your own hands.
Not only that, but if you choose to learn on your own time, finding a lesson to fit in your daily routine is also tricky, especially if you're caring for a family or have other commitments. Couple that with uncertainty about what to learn next, it can become overwhelming just to get started.
Very recently, I started working on a project[1] to address this exact issue. The project is to help established software engineers progress their careers, learn new concepts, and refresh their existing knowledge with daily bite-size software engineering lessons designed to fit in their daily routines.
Unless you use load balancers in non-trivial ways at scale and really need to understand the ins and outs of how they work to utilize them effectively.
This is so short-sighted, because it means you can't learn anything unless your boss is 100% sure it will be immediately useful (at which moment, someone else is probably already assigned to do it). Most things I learned in my life were not immediately useful when I learned them, but many became useful later. Programming itself is a good example of this; when I was a kid, computers were considered just an expensive toy. By this logic, I should have never learned programming in the first place.
These constraints do not allow you to explore. If there is a new framework or a new programming language which MIGHT improve your productivity, but also MIGHT be a useless fad, you are not allowed to find out which one it is. No one in your team is. Thus you get stuck with the old technologies forever (or someone breaks the rules, or someone studies the new technology in their free time).
Or was that a faux story for your sales pitch?
I've always felt a level of entitlement around that. You (the business) want me to learn and get better. You get more value over time that way.
I've experienced the polar opposite in a Japanese bigco where we were given extensive material to learn (generally about the industry, or certifications), and it was very clearly understood that we were to learn the material off company time. As an American naturally I had an allergic reaction to this culture.
He says the amount of persuading he had to do to the global execs that being off-grid for two weeks might have it's benefits almost made it futile.
I can't help but wonder if this attitude has inhibited japanese progress.
I have no idea who started using these acronyms but they definitely forgot they're new and not universal.
We use SE here in Japan for both software engineers and system engineers. How are they difference? The latter is older and seems to have originated from people doing architectural, consulting type of work.
Fun fact, consulting/contracting businesses here and also known as SES, System Engineer (as a) Service.