Live data from Hacker News

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

sloanreview.mit.edu

401–410 of 467 posts

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

#401
I've noticed that some companies implicitly do this. Instead of hiring from the pool of people with the skill they need, they hire someone else with potential and whom they like better.

Then when it comes to the job, they don't tell you to learn specifically, but subconsciously they do know this and as a consequence rather judge on the quality of your work than "looking over your shoulder".

Of course, it's also cheaper to hire younger people.

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

#402

Earlier quoted context omitted.

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.

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.

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

#403

Earlier quoted context omitted.

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…

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

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

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

#404
post #339

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…

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.

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

#405
post #309

Earlier quoted context omitted.

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

A simpler, more universal word might be grunt.

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

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

#406

Earlier quoted context omitted.

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.

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

#408
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…

If you want your reports to learn on the job:

1. Make it part of their annual goals (e.g. attend a conference, get a certification, compete in a competition).

2. Throw them in the deep end, a little beyond their edge, and be okay if they fumble around a bit.

3. Make them teach. Give them stuff to understand and present to your team or other teams. That forcing function will give them a mechanism to immediately exercise their newfound knowledge/skill.

4. Make room in your project schedules for it. They'll learn on their own if they have the time, or they'll invent something. The ones that don't are your bottom tier.

My first boss sent me to Siggraph my first year to drink from the fire hose. He also asked me, on my first day, what I was worst at of all the areas of programming I was aware of (Windows UI) and assigned me three months of work writing custom controls... I did it in six months, and I've never been able to thank him enough for teaching me, right off the bat, that your people are your greatest investment, that optimizing for the project is rarely the right choice.

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

#409
post #300

Earlier quoted context omitted.

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

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.

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

#410

Earlier quoted context omitted.

Are there still places left that don't do scrum? Hopeless to put "I am working for a workplace that does not practice scrum/sprints" in my cover letter?

Actually almost nobody does Scrum. They use some artifacts from Scrum but leave out the important parts.

It’s actually way, way worse than that. Nobody does Scrum and everybody seems to be getting into SAFe.

https://www.scaledagile.com/safe-5-preview/

Post reply on HN