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

361–370 of 467 posts

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

#361

Post by katrotz »

jimbokun wrote: post #319
anon9001 wrote: post #296

Earlier quoted context omitted.

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

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)

Eyes opening information. Thanks!

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

#362

Post by Aeolun »

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

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

#363

Post by ShroudedNight »

uxp100 wrote: post #315
hamandcheese wrote: post #242

Earlier quoted context omitted.

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.

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

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

#365

Post by arminiusreturns »

One caution though; learn how to limit the learning part, it can become a trap. I have often in the past fallen victim to the pitfall of spending too much time researching tooling and not enough time jumping in.

My methods for avoiding this are to have a core set of criteria that is minimalized. It widens the possible tool list and makes it harder to get caught up in minutiae. Then, I have found that actually just spinning up each set of tooling in testing to find real world implementation issues first-hand is a great first-gate narrower.

This is just a particular subset of learning at work though, so in general what I would say is learn how to get better at learning in general. Learning at work and elsewhere will get better if you do.

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

#366

Post by Ragib_Zaman »

oarabbus_ wrote: post #243
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.

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.

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

#367

Post by coffeefirst »

ACow_Adonis wrote: post #364
sasper wrote: post #309

Earlier quoted context omitted.

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.

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

#368

Post by Aeolun »

alfiedotwtf wrote: post #321
puPoh wrote: post #300

Earlier quoted context omitted.

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.

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

#369

Post by Aeolun »

percentcer wrote: post #245
uxp100 wrote: post #239

Earlier quoted context omitted.

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.

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

#370

Post by ShroudedNight »

WhiskeyJack55 wrote: post #170
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…

Several companies that friends of mine work at institute a 10% personal project time policy. Where 10% of their week is devoted to personal projects. They pick any topic of interest related to programing, learn something new, and when they are done they show the project to the team to present what they've learned. I don't think they have a time limit per se. Some people I know have done work with the raspberry pi, or…

> ...might be arguably less directly applicable to work.

Why is this a problem?

IC continuing education isn't (primarily) about having them finish reading the RFC even though they've already gleaned what they needed for their immediate problem. Rather, it's about drawing in whole new areas of knowledge. It's about keeping your deck stacked with wildcards so when you get blocked by something hard, not covered by your standard 'best-practices' you have enough diversity of experience to actually have a hope in hell of having something to draw upon for inspiration on how to solve it.

Post reply on HN