I've started using Friday as a "personal development" day at work.

I do not write any code on Friday (unless it's a severe production level issue). Instead, I spend the mornings reviewing PRs that I wasn't included on (to keep up with whats happening, but also to learn more about how other people write and review code) and the afternoons are spent reading/researching/online classes.

This has really helped me avoid burn out. I go into the weekend less exhausted and more motivated to return on Monday and implement new stuff. It has also helped generate some inspiration for weekend/personal projects.

This sounds like a good idea that I would really like to try, for my own sanity if for nothing else. For me, the issue—imagined or not—would arise in the Friday morning daily stand-up. I’m not sure it would go over well if I said that I intend to spend part of the day doing PRs (this is fine and expected) and the other part learning/researching (likely not).

Oh the joys of the JIRA sweatshop. We have JIRA pulled up on the big screen TV and the product guys cycle through the status of each dev team members’ items during each daily standup. This is my first development job, surely it’s not like this everywhere?

The way we handle this is by padding our sprints enough so that there's always "extra time" at the end.

E.g: If we as engs think we can do 12 tickets in a one-week sprint, we commit to 8. This leaves room to pick up any production issue related work, address tech debt, and have some breathing room so we're not rushing through jira tickets.

It's also workplace specific, but imo product people shouldn't be engaging in daily standups other than passive observation. If they are drilling through the jira board and asking for status updates, they're taking on the role of a micro-manager, not a product owner/manager.

Standups should be engineers talking to eachother and raising blockers/issues that would prevent them from meeting the sprint goal they committed to, not daily check ins with product (again, imo).

How does this fly in an organization where your promotion is based on sprints and not sustainable coding/quality?

If you want to contribute to the value of the organization because you're a substantial equity holder, then talk to the founders. A sweatshop with high turnover should be less valuable to an acquirer than a strong team. Your initiative may be well received as leadership and you can get your promotion that way.

If you want to stay in the organization and get promoted by performance metrics, then figure out what numbers are being evaluated and work to maximize them, so that you appear as the model worker. It's not very hard to stay one step ahead of management if that's the game you're playing. If you have the best relationships and the best metrics, you should be able to get your promotions.

If you want to stay in the organization and coast, then who cares, just do what you want and they're almost certainly not going to fire you without plenty of warning. If you do get put on a PIP, then go find a new job immediately, and repeat. From what I can tell, most of the workforce does something similar to this for 30-40 years.

If you're not a leader, not a model worker, and not on autopilot, then you probably need to find a new organization where you can be one of those things.

You seem to have re-iterated the Gervais principle:

https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...

(although leader, model worker, autopilot are more polite terms than sociopath, clueless, and losers)

Ha, that's fantastic! I didn't know it had a name.

Not just a name, but a whole collection of essays characterizing modern corporate life. And you just managed to summarise its takeaway very eloquently in ordinary, everyday language.

What an interesting read. Thanks!

Eyes opening information. Thanks!

Such organization is begging for a quickly written code full of bugs. Then you do some overtime fixing it, and you are a hero for a moment. But before you get promoted, you get sick because your body cannot handle all that stress anymore.

Sometimes you learn to play around the rules. For example, if you are required to report your progress every day (and "sharpening the axe" is frowned upon), a possible solution is to report on Friday morning only half of what you did yesterday, and keep the rest for the Monday report.

The beauty with imaginary numbers (sometimes known as story points), is that that they are just that — imaginary. And as the dev, you know how to massage them to your liking.

It doesn't; find a better job.

Man, I wish this is how my last place did it. Instead, if we were getting through 12 we'd commit to 14 and then the dev manager would wonder why stuff wasn't getting done.

It's not like that everywhere

> product guys cycle through the status of each dev team members’ items during each daily standup

Something has gone horrible off the rails. Standup is supposed to be a quick time for every team member to raise any blockers primarily, with a quick "here's what I did, here's what I'm doing" type blurb. The benefit of standup is identifying blockers and if engineers are getting mired in problems (so you can fix those issues outside of standup).

A place where I worked got off the rails when standups were used to allow two people to work through a problem while the rest of us sit there patiently. They grew to be 45 minutes long each day.

People brought chairs. To a standup!

That sounds like an opportunity to very politely explain the phrase "take it offline" to everyone. It would be awkward, but probably less awkward than standing there patiently doing nothing for half an hour.

This is where the Scrum Master should step in and move the conversation along.

Agreed. PMs (product or project) should rarely speak during standups; instead, they should be listening for blockers and other action items for them.

I've worked in environments where the PMs micromanage like this. It's both hellish and extremely inefficient.

It's almost like... gasp management always used agile to implement micromanagement all along.

I logged in just to make this same comment but you beat me to it. Agile is micromanagement in disguise, and we fell for it hook, line, and sinker.

To be fair, we were already micromanaged. Then Agile was posited as a solution, so of course we were enthusiastic. Unfortunately the only thing that appeared to change was the name.

So we’re not really any worse off than before.

Are you sure you haven’t just always been micromanaged and this is another way for that to happen? All things can be abused for bad purposes.

I haven’t heard too many examples of “oh man we used to be free and ship great features on time but now that we have a backlog and talk to each other every day it’s a hellscape death march”

I've done my stint in "large enterprise". It's a whole new world there where management believe that if projects aren't on track, then the solution is more meetings, more agile training and in-house "coaches", and even more micromanaging. I'm no longer in that world, and I'll never go back.

As someone that has also worked for large enterprises as well as government, I’d say that using agile can be another way to micromanage, but it can also be used in a way that improves product quality and impact while helping developers.

Generally, I’ve found that the level to which agile approaches make life better depends on how much management is actually willing to let the team do its work and stay empowered. This can happen with trust and top cover in large enterprises, but it takes constant work at the PO / product manager level otherwise regression to the mean takes over. Also hard to avoid the inertia of making successful teams bigger rather than letting them continue small.

I wonder how the Amazons / Facebooks of the world avoid the trap, but then their enabling teams are likely a big percentage of their workforce because they understand how important software is to their business.

By top cover, do you mean managers shielding lower level employees? That was my experience at a mid-size finance firm, it was only possible for my team do to decent work because my team lead was fairly competent at keeping the higher-ups up at bay.

The best managers I've worked for have understood that one of their key roles is to be shit-umbrellas.

Precisely.

I stopped going to my team's standups because of this. For a few weeks I was occasionally asked about what I was doing, I just always said I was busy on whatever I was working on. Now I'm the only member of my team who never joins the standups. I wonder if they resent me for that, but it's not worth going back.

Probably they resent you. What feels like a good solution is discussing this in the retrospective or have an informal discussion about this. Then again, team members need to be open to discussing this and viewing it from another angle.

Also, by discussing the issue you might discover others feel the same way and are open to changing the process.

If this were the case then standups would be totally useless unless the org was so cooked that nothing gets done unless someone is made accountable in front of the entire team.

If I run into a blocker why would I wait until the next morning to try and get it resolved?

Usually the idea is you move onto another task since you have multiple allocated at one time, then ask briefly for guidance during the standup when everyone has put time aside, rather than interrupting everyone throughout the day.

Blockers are not just people and usually it's not done for accountability. They can be undocumented APIs, an unfamiliar requirement ("do we already have a way to extract images from PDFs before I download this new thing?"), etc.

If it is urgent and your only option is to sit there and do nothing then asking the team for help during the day is fine. Just weigh up the cost of interrupting everyone (or that high-performer who has all the answers) against what you gain.

> If it is urgent and your only option is to sit there and do nothing then asking the team for help during the day is fine.

Sit there and do nothing for awhile just may be the right thing to do!

I'm thinking about the Theory of Constraints and optimizing a system versus individual parts. This is a concept you would want your PM to know. So when they are mentally mapping the workflow heard during standups, they can be thinking about optimizing the entire production system.

Next step is the importance of communicating this to everyone on the team, so that they understand that there may be times when the right thing to do is nothing.

"Hey, I spent all yesterday trying to get X to work but I think I'm stuck"

"Hey I was trying to use Mary's api but I couldn't figure it out, can someone help me find who to contact?"

If you ask immediately for help all the time you aren't being self sufficient. At the same time if you are spinning your wheels then just a second pair of eyes can be helpful.

I had a new manager start his first weekly meeting by asking if there was anything on fire. People filled the ensuing silence with recent annoyances. Of course nothing is on fire right now (and I get it’s a metaphor). If something is “on fire”, I’m not waiting till the Monday meeting to bring it up. I’m not even going to attend the mandatory meeting while I put it out, if that’s when it happens. That’s the definition of on fire.

To be fair, your new manager doesn't know that's how you operate. It seems a reasonable question to me, with the expected answer being no. But why not ask just in case? You wouldn't want to be the new manager who just launches into new business not realizing that one of your developers is too timid to interrupt you with the major breaking bug that's currently live, or whatever. Once they get to know the team and can trust that you'd be on top of that kind of thing, it's another story.

Maybe I’m too sensitive to the phrase “on fire”. I can’t imagine someone at a factory starting a meeting the same way.

He was perhaps trying to get a feel for the team?

Yep, that's a way away from ideal.

You're unlucky, there are a lot of software teams out there where the developers are pretty much autonomous. That's not to say they do absolutely whatever they want, but micromanagement is usually out of the question.

A couple of months ago I spent about half my working hours in a week watching everything that happened at .Net Conf. I didn't ask anyone, I just said I was taking training time and since I don't take much no-one cared.

If I was in your position, I'd take this as a sign that there are better places to work. Wait out your current job until it's adding value to your CV (few good projects and contributions you can talk about), then move out. You'll get more money, and you'll probably have a better idea of what to look for.

Any idea what to look for when searching for such a job? I have asked about micromanagement in interviews before but I usually just get bullshit answers.

Brainstorming a bit on this. Curious for other ideas:

Start with asking questions about how work is assigned/doled out. Where does all of their work come from, the Agile board? Someone stopping by and asking "can you do x" or "can you help Jill with Y".

Follow that up by digging into how they then talk to others about their progress on that work. Ask if they're interrupted or allowed to progress independently? How often does someone ask them "Is that done yet?"

Ask about how often they're asked about the status of the same piece of work by different people. Dig into how they keep everyone else apprised of what they're doing.

Ask them about their relationship with their Scrum Master, Project Manager, Product Owner, Dev Manager, etc. Ask what they could change about it if they could.

That line of questions may uncover the micromanagement pattern. Even if it doesn't, it will go a long ways in helping you get a feel for how a team works.

I'm not sure about other places but the teams I've worked on and worked with at Google works like this.

Where I work standups are for devs only. The product guys are involved in planning and reveals, but otherwise they stay out of our hair. We're expected to complete what we've committed to on time or promptly notify the product guys if that's not going to happen for whatever reason.

About once a week (usually Friday) I tell my team I'm going to spend the day researching or exploring some new idea that doesn't have any stories yet. It's never a problem. A decent chunk of our big leaps forward for our projects have come from us working on random stuff nobody told us to work on.

By the way, this is the official SCRUM way. Product people should be there for planning and for demo. If at the end of the sprint they got what they wanted to get, they should be happy and do their own work... or relax if they have nothing else to do.

Micromanaging means you have nothing useful to do, and you are needlessly making other people angry. Such people should be fired first. (Yeah, I know, they are often the last ones to stay, because people who have better options leave first.)

You may want to describe part of your work on a task as reviewing solutions (for a given PR) and then after the standup spend some time learning about related tech to whatever PRs you have assigned.

If the product guys are any good they will care about having 'options' and will therefore welcome devs that are taking a broader look of the solution space.

It isn’t like that everywhere but it’s quite common, especially in companies where development is not the primary focus of the company. You’re more likely to end up in that kind of company than not unless you are in a place like the Bay Area or similar tech hub.

Replying purely for reinforcement of the parent.

This is not just common, but the norm in most organizations. I think the only time in the past 12 years (working with probably 20 organizations) where this didn't occur is the one engagement when I was charged managing the team.

There's far too many places where a team of even just four or five developers will spend 30 minutes (sometimes an hour!) every morning in "standup" being grilled on every single item committed to in the sprint.

I recently had my first experience with "agile" and "scrum", and this was my experience. I left after being there for 6 months for unrelated reasons, but one of things that made it an easy decision was the daily fucking standup.

I convinced the team to do without the standup and just put the status updates in slack for a week. At the end I was the only one who thought it was better. To quote one developer "I don't read it when its in slack". That indicates to me that the information isn't necessary to do your goddamned job.

I dislike agile now as a result of that experience.

It is like this in two out of 4 places that I’ve worked.

Those two were both large corporations. It is my theory that it happens as soon as you have a separate scrum/project manager for the project you work on.

Stand up for what you believe in. Tell them you are spending the day on research.

Better yet, cancel that standup because it's garbage. Only one representative needs to go to the product meeting.

Well, you don't have to mentioned that you are doing your own research...

Do they look over your shoulder every minute?

This is what I encourage my staff to do. We have a company-wide bagel breakfast in the morning, and then no more meetings. We also skip our daily “async slack stand-up” on Fridays. My expectation for the day is that you prioritize personal development, long-term planning, or just “deck clearing” if you’ve had a long week or desire something less mentally demanding for the day. Obviously, thing happen that can interfere with the ideal, but it’s pretty rare and, when it happens, I make it a point to figure out if there’s a way to avoid it going forward.

What we don’t do, is “no deploy Fridays”. We deploy all the time, and maybe somebody wants to do some minor bug or light UI cleanup. I’m certainly not going to stop them. Requiring an “off-day” for deployments is a major red flag for me.

Except when the Friday deployment breaks production and one of your employees needs to fix the issue on Saturday instead of relaxing with their family.

You seem to be getting down voted but this is important. Unless the company is paying staff to be available and on call over the weekend people have lives to be getting on with and wouldn’t be able to respond to an issue as quickly than during the week.

I understand this isn't a perfect world and problems happen but we also shouldn't live in constant fear that a deployment will break production. There should be processes in place that prevent broken code from even getting to the point where it's merged into master.

The biggest extreme that I've faced was a team where there was a 36 hour window between Wednesday and Thursday where deployments to production were allowed and it was a nightmare getting any code out especially with most deployments involving 10-20 new commits so if something did break we had to rollback a lot and rack our heads to figure out what went wrong.

I agree. Employers, teams, and employees need to have clear expectations and communication around availability, including how that is related to compensation, but also how it relates to the design of the systems themselves, the planning that goes into rollouts, and a culture of quality and accountability.

Also, sites "go down" for more reasons than deployments, and often, a deployment is one of the fastest or only ways to fix or work around the issue.

The company I'm at sets aside every other Friday for all engineers to learn, contribute to open source, hack on an idea they may have (that may or may not be related to work), etc.

So far the only problems I've seen is that sometimes it's hard to convince engineers to actually use the time instead of still working on tickets.

very cool. does your company maintain the IP ownership to anything made during these periods?

I would expect so. Doesn't it seem a bit much to expect the company to give you paid time to work on your own personal side projects? They don't own the knowledge and skills you gain doing it though.

My team when I first joined had something like this; we called it a 'spike' day. Basically a full day of time where we could learn about something new, maybe hack on a non-necessary feature or even personal project for a few hours a week.

But sadly over the past few years we've kind of just done away with it. We don't allot time for it specifically anymore. We think about it from time to time and wish we still had the bandwidth for it.

But it just doesn't happen anymore.

It's a tough thing to build into a team's structure, I think, and in such a way that it's sustainable.

Go in tomorrow and tell everyone it's time to start doing spike again.

I run a small consultancy and Development Friday's are almost mandatory for my developers. Everyone is given Friday afternoon to learn new skills or improve existing ones, I even tell my clients that this happens (we charge by the week) and in the last 4 years I've only had one complaint and we quickly cancelled the contract with them after.

I love this, and that a major value in it is feeling refreshed. I think I'm going to try this a bit, time-permitted, and ask for forgiveness later if there's ever an issue. I'm constantly finding gaps in my knowledge that my smarter team members would certainly benefit from me being more on the same page on if I spent more time developing my skills.

'Great Thoughts Friday' from Richard Hamming

https://youtu.be/a1zDuOPkMSw

Slightly better video and sound (from the same source material):

https://www.youtube.com/watch?v=e3msMuwqp-o&list=PLctkxgWNSR...

This is pretty much what I do at the company I work for. We also spend part of that time having roundtable discussions on different topics.

This is a brilliant idea! Hopefully it becomes popular.

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.

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

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

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

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.

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

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?

Procrastination is a powerful motivator

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.

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.

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.

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

What's IC?

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

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

Software Engineer.

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

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.

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

A simpler, more universal word might be grunt.

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

> never asked permission

That's a key thing.

Even in the most high pressure environments, where "project management professionals" are breathing down your neck for "deliverables" it is your responsibility to learn stuff and evolve.

It's nice if there's time and resources for people to better themselves, but these are typically limited to activities which are "related" to one's work function and are subject to "approval" from people whose interest in your career stops hard at what you can do for them in the roles they assume you're best-suited for.

The good news is most places are NOT rank-and-yank hellscapes where every minute you do something that's not on somebody's gantt chart will cause you harm in the long term. In most places you can lift your nose off the grindstone... but you have to be willing to impose your own self-direction and structure.

Same but I've also been in places where they do look over your shoulder and I ended up fighting the tide. Everyone around me was in a constant panic mode, so I slowed my work output for 2 weeks (most I could get away with without ending up in a room talking about my work performance) where I studied and optimized the tasks consuming most of my time. Then automated them (this involved working what felt like two jobs at once pushing well over 80h a week)....

When I finished I had so much free time I could finally start doing the interesting projects and my work output was consistently 2x my co-workers. I considered explaining this to management but they had just admonished a co-worker for not doing the thing they asked and trying to improve process. So I kept it to myself.

Obviously this was a bit of a toxic work environment (early in my career) and I was luckily switched out of this group.

My point is that you can fight bad management to make a better working environment for yourself but it takes a lot of effort and you need to be strategic in what you tell them as it can backfire.

> look over your shoulder

I suspect that one of the drivers behind open offices is to make it easy to “catch” people who are “wasting time” learning on the job.

I used to do this, and then we "switched to be more agile." (This just meant using JIRA and tracking sprint efficiency wrong).

Companies do think "It’s your responsibility to be on top of whatever’s going on in your field" and they might even claim that learning and development on the job is important, but when it comes time to log JIRA hours, they tend to show how much they really believe in this.

If you want to track this through JIRA you need to make time for both learning and teaching. I've found that mgmt is reluctant to allow for "a day of learning", but if the output of that is a document or a small seminar where you can share that knowledge with the team it goes down much more easily.

It also takes all the fun out of it. I can’t properly get my mind in a state to learn if I’m going to be held accountable for how much I pick up.

> I can’t properly get my mind in a state to learn if I’m going to be held accountable for how much I pick up.

That is school and university in a nutshell though.

Maybe make tickets for your learning activities?

Heh, would not go over well. Now that we have JIRA, tickets are not just watched by my boss, but my bosses boss, my bosses bosses boss, and a few dedicated project managers of some kind.

Yuck. When my company started pushing for more "agility" and my team moved to a sprint structure, I was lucky enough to have personal leverage as a senior team member. Early on I made it clear that tickets and sprints exclusively exist for the team to plan and manage expectations, and that I wasn't going to hold with upper management using them as leverage over anybody. To support that, I had to interrupt stand-ups a few times when someone would start iterating through tickets for progress instead of letting people report.

I wish misuse of these tools wasn't so widespread, but it was to be expected.

> ...tickets are not just watched by my boss, but my bosses boss, my bosses bosses boss...

Are all these people really hired for their competency? The amount of wasted time this describes is staggering. Even at the worst of times, ticket interaction by even a skip-level was a sign of mounting org-wide desperation.

Use code words.

We didn't use JIRA (very much a NIH-company with our own job tracker) but we always had a job number to log training/learning hours against.

IIRC, management actually questioned people who didn't log much time on it. There were a lot of problems at this place but I liked that.

“using JIRA and tracking sprint efficiency wrong” is the working definition of agile at most companies AFAICT.

This makes me sad. I had a great experience with what I now think of as “authentic agile” at my second job, now I doubt I’ll ever get to do things that way ever again.

Very much this. If the management culture at your workplace is so sick they feel the need to make this behaviour a problem, there are probably other things wrong with the culture there.

Yes it is a huge red flag in general. If your company discourages learning on the job, you run, cause the company is only heading down hill.

You're correct that it's our own responsibility to be on top of whatever is going on and to train ourselves. However, plenty of companies think that expect for training scheduled and provided by the company, that it's not appropriate to train ourselves on the clock.

Personally I agree with you, and find that discouraging people from training themselves during business hours just results in most employees not fully applying themselves.

Someone who is great with how to develop good processes at work recently said something that made me think a lot about this as well.

Why have WIP limits? Well one of the reasons is to be able to create downtime where you can go watch a video or read a newsletter. So I've been trying to spread this message in my team when someone has asked "The WIP is blocking and I can't really help anywhere at the moment" by answering "Go watch a video or read or take a walk for 10 minutes".

Since you weren't explicit about it, having a PM or manager who a) understands this concept, and b) can communicate it to the team is important and what you did here!

I mentioned in a comment above that with the Theory of Constraints in mind, sometimes the right thing to do for an individual contributor at a point in time is, nothing.

You went ahead and explicitly turned that into time to learn for them. Bravo.

> I subscribe to those weekly emails for the programming languages we use at work

--

Are these an internal thing for your organization? is it Just joining a mailing list for X language? Or is there some aggregation service you could share?

I found this good curated list: https://github.com/zudochkin/awesome-newsletters

Folks over at CooperPress maintain several dev weekly newsletters with pretty good overview of week's news: https://cooperpress.com/publications/

Me too. The company benefits in the long run. I've never had any complaints. In general I've found no one ever complains if you spend time learning.

As a remote company we're dedicating a 1-hour video call every week to learning. On top of that we've 2-3 voluntary video calls that we call MJ Talks (similar to TED Talks) talking about all kinds of topics ranging from technical and software related topics, but also health, fitness, personal finance, etc.

On top of that we dedicate one week every year to something that we call MJ University. We rent a hotel in a location and fly everyone in to that location. If you're interested on all the details, we've written them up here: https://mobilejazz.com/blog/mj-university-staying-ahead-of-t...

I really think this is the way to do it and it's also how I've always approached this. So much so that now the other members of the team I'm on joke about how I'm the guy that likes jumping down rabbit holes - which they're perfectly fine with!

Something very important to this approach IMHO is paying your learning forward. Mentor other devs, write guides for your team/organization, etc. Make the benefit of your learning visible to everyone else.

That means that yes, your learning has to have value to the business and to the team. If that aligns, I can't imagine many problems arising. Your learning becomes an act of giving and taking, rather than just taking, which is a win-win for everyone involved.

What does "learned on the job" mean, though?

Were you reading Stackoverflow? Taking a digital course and watching lecture videos? Reading a textbook with a pencil and paper out? Attending in-person trainings?

All of these things are scrutinized very differently in the workplace.

Exactly. Lots of places will not blink an eye if you are reading a blog post on something you'll be able to apply within a week. Having a textbook with pen and paper out to learn something that may not bring fruit for several months is a different story.

Same here - i keep all the deadlines and use the spare time to better myself. Or even implement new ideas in production code.

Also latter half of Friday is officially, by company policy, set up for such tasks - learning, and finishing internal tasks that always get pushed back.

The more i learn, the better value/cost ratio for my employer.

I would immiedetly change jobs if they didn't challenge me, or at least provide an environment where i can learn.

This over anything else. I wouldn't get to be a CTO multiple times if I wasn't in this mindset.

I sort of felt embarrassed when my manager told me to stop solving so many tickets and spend more time learning and improving my skills. He was so right.

This is research, it's valid part of anyone's job.