[sasper]

As an engineering manager, this is what I expect my top performers to do and encourage my junior folks to do the same. It benefits the IC, the delivery team, and the company at large.

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.

[holmboy_]

Continuing education in software engineering has always been a challenge for me. While my current employer allows for 20% time to learn new things, I find that I'm just unable to. Many employers (not all) place constraints on what one can do with that time. Typically the biggest constraint is that it must relate to the business in some way. As such, it can be hard to justify why you're spending your 20% time learning how load balancers work in nitty-gritty details since it's unlikely you'll be writing one from scratch or helping the company with it.

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.

[1] https://www.dailyswe.com

[Viliam1234]

> Typically the biggest constraint is that it must relate to the business in some way.

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).

[jimbokun]

"As such, it can be hard to justify why you're spending your 20% time learning how load balancers work in nitty-gritty details since it's unlikely you'll be writing one from scratch or helping the company with it."

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.

[commandlinefan]

Well, you know that, and I know that, and OP knows that. But it’s likely that OP’s boss not only doesn’t know that, but is mentally incapable of comprehending it. And even if he does (my boss is actually a sharp developer who does understand what’s going on), remember that we all have 8 bosses at any time.

[ClumsyPilot]

You can't generally predict how that knowledge will be useful, load balances don't exist in a vacuum, he might learn about packet structure, fail over and all kind of other stuff directly applicable

[lonelappde]

You don't have time to learn, but you have time to build an app backed by a service?

Or was that a faux story for your sales pitch?

[haihaibye]

Procrastination is a powerful motivator

[philjr]

110% agreed

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.

[hkmurakami]

I think we're lucky that many companies have this attitude.

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.

[ddek]

Friend of mine is a senior exec for the Fujitsu Europe. I met him doing the Haute Route, a two-week ski tour in the Alps.

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.

[koheripbal]

To be honest, it's impossible to survive in tech if you are not constantly keeping up to date.

[tobych]

What's IC?

[sasper]

Individual contributor. It's a fancy management word for SWE or anyone else in a non-management role.

[ACow_Adonis]

Ug...ok, I'll be that guy: what's an SWE?

[coffeefirst]

Software Engineer.

I have no idea who started using these acronyms but they definitely forgot they're new and not universal.

[SenHeng]

I guess the W is to differentiate it from Systems Engineer?

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.

[pjscott]

I haven't heard SE outside of a Japanese context, so this may just be a case of different countries randomly picking different acronyms.

[SenHeng]

A simpler, more universal word might be grunt.

[pjscott]

The higher levels of IC are usually more noncom than grunt.