Learning at work is work, and we must make space for it • Hacker News Board

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

#321

Post by alfiedotwtf » Wed, Dec 11, 2019, 9:55 PM UTC

puPoh wrote: post #300

organsnyder wrote: post #288

Earlier quoted context omitted.

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.

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.

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

#322

Post by jimbokun » Wed, Dec 11, 2019, 9:55 PM UTC

holmboy_ wrote: post #294

sasper wrote: post #101

Earlier quoted context omitted.

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…

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

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

#323

Post by rajesh-s » Wed, Dec 11, 2019, 10:11 PM UTC

I've worked at a few places. Something that I wished existed in all those places is a library. It need not be filled with books. Just reserved room space for people to come and read without interruption. I really wish someday people give this a thought.

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

#324

Post by Consultant32452 » Wed, Dec 11, 2019, 10:13 PM UTC

puPoh wrote: post #300

organsnyder wrote: post #288

Earlier quoted context omitted.

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.

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.

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

#325

Post by kedean » Wed, Dec 11, 2019, 10:18 PM UTC

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.

Yuck. When my company started pushing for more "agility" and my team moved to a sprint structure, I was lucky enough to have personal leverage as a senior team member. Early on I made it clear that tickets and sprints exclusively exist for the team to plan and manage expectations, and that I wasn't going to hold with upper management using them as leverage over anybody. To support that, I had to interrupt stand-ups a few times when someone would start iterating through tickets for progress instead of letting people report.

I wish misuse of these tools wasn't so widespread, but it was to be expected.

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

#326

Post by Viliam1234 » Wed, Dec 11, 2019, 10:18 PM UTC

holmboy_ wrote: post #294

sasper wrote: post #101

Earlier quoted context omitted.

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…

> Typically the biggest constraint is that it must relate to the business in some way.

This is so short-sighted, because it means you can't learn anything unless your boss is 100% sure it will be immediately useful (at which moment, someone else is probably already assigned to do it). Most things I learned in my life were not immediately useful when I learned them, but many became useful later. Programming itself is a good example of this; when I was a kid, computers were considered just an expensive toy. By this logic, I should have never learned programming in the first place.

These constraints do not allow you to explore. If there is a new framework or a new programming language which MIGHT improve your productivity, but also MIGHT be a useless fad, you are not allowed to find out which one it is. No one in your team is. Thus you get stuck with the old technologies forever (or someone breaks the rules, or someone studies the new technology in their free time).

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

#327

Post by TeMPOraL » Wed, Dec 11, 2019, 10:29 PM UTC

hinkley wrote: post #274

TeMPOraL wrote: post #269

Earlier quoted context omitted.

Until suddenly the requirement to support older browsers is dropped, or you get shifted to another project, and then these ES2018 features would come in handy. Learning only the stuff that covers your immediate working needs isn't a winning strategy, neither for you nor for the company.

If you are 'learning' stuff open-loop (with no feedback from users or peers), then you are deluding yourself about how much you've actually learned. You're one important but terribly insufficient step above book learning. No battle plan survives contact with the enemy. There are tons of strategies I know to solve problems that I never use because it confuses other people (and some of them confuse me too when I look a…

> If you are 'learning' stuff open-loop (with no feedback from users or peers), then you are deluding yourself about how much you've actually learned. You're one important but terribly insufficient step above book learning.

Book learning ain't bad; in my experience, most of the developers I know would do well if they picked an actual book every now and then. It's not as good as hands-on experience, but still miles ahead of "learning" by StackOverflow-driven development. Experience is an important piece of the puzzle of wisdom, but it's not the whole thing. You need to also have understanding, and reading (and thinking about what you read) is a good way to acquire insight.

WRT. closing the loop, your users and peers aren't the only way to close a loop (and arguably, they can only provide certain kinds of feedback that are very context-specific). Trying things out for yourself is also a good way to close the loop through feedback from reality itself (e.g. whether something works, or how difficult you find it, are such pieces of feedback). On top of that, peer/customer feedback makes no sense for a lot of useful knowledge - for instance the new ES2018 and CSS features you've mentioned upthread.

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

#328

Post by ravenstine » Wed, Dec 11, 2019, 10:33 PM UTC

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…

This is pretty much what I do at the company I work for. We also spend part of that time having roundtable discussions on different topics.

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

#329

Post by TeMPOraL » Wed, Dec 11, 2019, 10:38 PM UTC

knightofmars wrote: post #126

rvense wrote: post #28

Earlier quoted context omitted.

Your lead made a mistake there. Someone with understanding of both FE and BE is worth as much as one of each, especially when they have intimate knowledge of your actual code.

>Someone with understanding of both FE and BE is worth as much as one of each... Someone with understanding of both FE and BE is valuable in certain situations. Companies love the idea of a "full stack engineer" because they believe they are getting two for the price of one. But in practice, and accounting for exceptions, that's not necessarily the case. A full-time FE with equal experience will be better at the fron…

> As an attempt at an example, if you went to college and got an English minor and a CompSci minor you'd be capable in both areas but you would likely not be as knowledgeable as an English major nor a CompSci major within the respective domain.

I don't think this analogy works, because CompSci and English are pretty unrelated to each other as fields, whereas frontend and backend by definition work together to create a product. That makes a person experienced in both worth more when working on either, because they're more likely to have in mind the entire system when they do design decisions pertaining to their side of the network.

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

#330

Post by artsyca » Wed, Dec 11, 2019, 10:39 PM UTC

We are "Knowledge Workers" for crying out loud our role is to create knowledge and spread it that's all we're supposed to be doing all the issues that arise are based on people not knowing what learning really is and not understanding the value of the knowledge being created