Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learning at work is work, and we must make space for it

sloanreview.mit.edu

Post reply on HN
Print view View original

241–250 of 467 posts

Re: Learning at work is work, and we must make space for it

#241

Post by fhennig »

yters wrote: post #86
Braggadocious wrote: post #82

Earlier quoted context omitted.

You ever think about how much we subsidize businesses by paying for college ourselves? The older I get the more I think the university to corporation pipeline is a fucking racket. It also sucks for employees because here comes these kids who were allowed to learn about all the new technologies you wish you knew with zero distractions and other obligations, now comin' in hot on your heels to take yer jobs en masse, an…

University is a total racket. We pay these institutions to be treated like their low level employees to provide job training for companies. Corporations have successfully offloaded their training responsibilities onto a process that used to be much broader than vocational training.

Yes, paying so much money is absurd. At least in many European countries higher level education is free.

Re: Learning at work is work, and we must make space for it

#242

Post by hamandcheese »

uxp100 wrote: post #239
aczerepinski wrote: post #83

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. I subscribe to those weekly emails for the programming languages we use at work and I read them when they com…

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.

Maybe make tickets for your learning activities?

Re: Learning at work is work, and we must make space for it

#243

Post by oarabbus_ »

aczerepinski wrote: post #83

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. I subscribe to those weekly emails for the programming languages we use at work and I read them when they com…

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.

Re: Learning at work is work, and we must make space for it

#244

Post by vorpalhex »

protonimitate wrote: post #227
aczerepinski wrote: post #83

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. I subscribe to those weekly emails for the programming languages we use at work and I read them when they com…

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 bu…

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.

Re: Learning at work is work, and we must make space for it

#245

Post by percentcer »

uxp100 wrote: post #239
aczerepinski wrote: post #83

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. I subscribe to those weekly emails for the programming languages we use at work and I read them when they com…

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.

Re: Learning at work is work, and we must make space for it

#247

Post by vorpalhex »

paracyst wrote: post #240
protonimitate wrote: post #227

Earlier quoted context omitted.

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 bu…

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 o…

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

Re: Learning at work is work, and we must make space for it

#248

Post by mulmen »

cushychicken wrote: post #22
ChuckMcM wrote: post #3

That you should “always be learning” is absolutely true. It helps with neuro-plasticity and keeps you engaged. That said, as a manager I find it hard to get direct reports to accept sometimes that it is not only okay, but required, by me that they learn new things. I do what I can to encourage it, offer to buy books for people, give time to do online course work, etc. They often complain that they don’t feel like the…

>I find it hard to get direct reports to accept sometimes that it is not only okay, but required, by me that they learn new things Does this apply to skills that might be more applicable to another team? My current manager encourages learning, but shoos me away from topics that are handled by other managers. Frustratingly, he's blocked transitions of mine to other teams with work that I've found interesting and educa…

The second a manager blocks a transition it’s time to leave the company.

Re: Learning at work is work, and we must make space for it

#249

Post by koheripbal »

sasper wrote: post #101
aczerepinski wrote: post #83

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. I subscribe to those weekly emails for the programming languages we use at work and I read them when they com…

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.

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

Re: Learning at work is work, and we must make space for it

#250

Post by protonimitate »

paracyst wrote: post #240
protonimitate wrote: post #227

Earlier quoted context omitted.

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 bu…

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 o…

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

Post reply on HN