<story><title>Learning at work is work, and we must make space for it</title><url>https://sloanreview.mit.edu/article/learning-for-a-living/</url></story><parent_chain><item><author>paracyst</author><text>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&amp;#x2F;researching (likely not).&lt;p&gt;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?</text></item><item><author>protonimitate</author><text>I&amp;#x27;ve started using Friday as a &amp;quot;personal development&amp;quot; day at work.&lt;p&gt;I do not write any code on Friday (unless it&amp;#x27;s a severe production level issue). Instead, I spend the mornings reviewing PRs that I wasn&amp;#x27;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&amp;#x2F;researching&amp;#x2F;online classes.&lt;p&gt;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&amp;#x2F;personal projects.</text></item><item><author>aczerepinski</author><text>I’ve always learned on the job and have never asked permission. I guess I’m lucky that I haven’t worked in the type of places where somebody’s looking over my shoulder every minute of the day. Somewhere around an hour a day every day and I’ve been doing it for years and nobody has ever said anything about it.&lt;p&gt;I subscribe to those weekly emails for the programming languages we use at work and I read them when they come in. I sometimes watch a conference talk about implementing something similar to whatever I’m scheduled to do next.&lt;p&gt;If I were running a company I’d expect this of all high level employees. It’s your responsibility to be on top of whatever’s going on in your field.</text></item></parent_chain><comment><author>protonimitate</author><text>The way we handle this is by padding our sprints enough so that there&amp;#x27;s always &amp;quot;extra time&amp;quot; at the end.&lt;p&gt;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&amp;#x27;re not rushing through jira tickets.&lt;p&gt;It&amp;#x27;s also workplace specific, but imo product people shouldn&amp;#x27;t be engaging in daily standups other than passive observation. If they are drilling through the jira board and asking for status updates, they&amp;#x27;re taking on the role of a micro-manager, not a product owner&amp;#x2F;manager.&lt;p&gt;Standups should be engineers talking to eachother and raising blockers&amp;#x2F;issues that would prevent them from meeting the sprint goal they committed to, not daily check ins with product (again, imo).</text></comment>
<story><title>Learning at work is work, and we must make space for it</title><url>https://sloanreview.mit.edu/article/learning-for-a-living/</url></story><parent_chain><item><author>paracyst</author><text>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&amp;#x2F;researching (likely not).&lt;p&gt;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?</text></item><item><author>protonimitate</author><text>I&amp;#x27;ve started using Friday as a &amp;quot;personal development&amp;quot; day at work.&lt;p&gt;I do not write any code on Friday (unless it&amp;#x27;s a severe production level issue). Instead, I spend the mornings reviewing PRs that I wasn&amp;#x27;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&amp;#x2F;researching&amp;#x2F;online classes.&lt;p&gt;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&amp;#x2F;personal projects.</text></item><item><author>aczerepinski</author><text>I’ve always learned on the job and have never asked permission. I guess I’m lucky that I haven’t worked in the type of places where somebody’s looking over my shoulder every minute of the day. Somewhere around an hour a day every day and I’ve been doing it for years and nobody has ever said anything about it.&lt;p&gt;I subscribe to those weekly emails for the programming languages we use at work and I read them when they come in. I sometimes watch a conference talk about implementing something similar to whatever I’m scheduled to do next.&lt;p&gt;If I were running a company I’d expect this of all high level employees. It’s your responsibility to be on top of whatever’s going on in your field.</text></item></parent_chain><comment><author>vorpalhex</author><text>It&amp;#x27;s not like that everywhere&lt;p&gt;&amp;gt; product guys cycle through the status of each dev team members’ items during each daily standup&lt;p&gt;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 &amp;quot;here&amp;#x27;s what I did, here&amp;#x27;s what I&amp;#x27;m doing&amp;quot; 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).</text></comment>