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

291–300 of 467 posts

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

#291

Post by MrFoof »

sidlls wrote: post #280
paracyst wrote: post #240

Earlier quoted context omitted.

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

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

#293

Post by habnds »

8ytecoder wrote: post #278
habnds wrote: post #20

Earlier quoted context omitted.

It's because when annual reviews happen they aren't talking about the books they read they're talking about a project that they contributed to. In my experience formalizing "learning" in the work place doesn't work because it requires the performance of learning for management types rather than real learning which involves working through real new problems over an extended period of time. The real way to get employee…

At least one big company I know of, learning is part of performance reviews - agreed upon in advance by the manager and engineer. It didn't usually help (at least AFAIK). Part the fault of the engineers and rest the culture of the team to always be fighting fires.

I don't know the exact situation you're talking about, but my guess is that this is exactly the type of formal "learning" I would argue does not work.

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

#294

Post by holmboy_ »

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.

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

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

#295

Post by totalperspectiv »

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…

'Great Thoughts Friday' from Richard Hamming

https://youtu.be/a1zDuOPkMSw

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

#296

Post by anon9001 »

r00fus wrote: post #287
protonimitate wrote: post #250

Earlier quoted context omitted.

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…

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.

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

#297

Post by hysan »

One of the big reasons I left my last job was because management talked a lot about PD (professional development). However, the approval process for learning resources was vague and long. On top of that, we were told to learn on our own time and that at work, you were to work. I realized that to them, PD was something they encouraged but did not support. I eventually found out that the avg tenure was much shorter than the number I was told during interviews. I wonder why...

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

#298

Post by 6gvONxR4sf7o »

tarellel wrote: post #10

My employer encourages using around 20% of our time learning. Lower level developers can manage this pretty easily. But most of the level 3’s are kind of expected to just know stuff, plus the heavy work load. We still manage about 10% of our time to learn. But if we want to take Udemy classes, paid tutorials, or something else they’ll gladly reimburse us for the costs. They prefer their developers to “be on point”.

20% time is a day of the week. Why not just say "Wednesdays are learning and development day" or something?

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

#299

Post by lycidas »

The thing that annoys me the most is that tech companies, mine included, will reimburse gladly books, but no one is ever allowed to be seen reading books at their desk on company time. Whereas being on hacker news, reddit, NYT visibly is okay. I've just started reading PDF's on my computer screen but I'd prefer a real book of the same thing most of the time.

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

#300

Post by puPoh »

organsnyder wrote: post #288
vorpalhex wrote: post #247

Earlier quoted context omitted.

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

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.
Post reply on HN