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

The Senior Engineer’s Guide to Helping Others Make Decisions

silverwraith.com

Post reply on HN
Print view View original

21–30 of 63 posts

Re: The Senior Engineer’s Guide to Helping Others Make Decisions

#21

Post by nkjoep »

kelnos wrote: post #18
duncanawoods wrote: post #13

The real way a senior engineer trains juniors is by selecting appropriate work. They thread the needle of a number of factors: it needs to be done, its within reach, will build their skills, will educate them on product/business/process, they will find rewarding, will give ownership, relevant staff can support them etc. These factors are so important that the senior engineer might need to negotiate with the product m…

> What can't really happen is for a junior to suggest work. Junior engineers should feel welcome to suggest work. They should also be ok with having that suggestion rejected or put on the back burner because it's not pertinent to the current product/business goals. Depending on how the company is run, the senior can make the call, or involve a product owner, as to whether the junior's suggestion is something that the…

> They should also be ok with having that suggestion rejected

I agree at one condition: explain them why their suggestions are not appropriate (out of context, lack of resources, not a priority etc...).

That way you simply teach them more about the team/company business and will help them to step up their decisional skills.

Re: The Senior Engineer’s Guide to Helping Others Make Decisions

#23

Post by photonios »

Consultant32452 wrote: post #4
photonios wrote: post #2

Excellent points. I'd like to think my job is making sure everyone around me ends up better than me.

I have landed on the phrases rising tide vs shooting star. Early in my career I wanted to be the shooting star, the bestest most productive person there. Now that I'm older I want to be a rising tide that raises all ships. Did you experience a similar transition, or were you always a rising tide type?

Yeap. I was the most productive in the room and it was becoming a problem. Others simply couldn't keep up and it was slowing us down on the long run rather than making it go faster and better. I was disappointed with the improvements others in my team were making and started wondering what I could do to make that go better.

I realised that one of the freedoms I had early in the career was the freedom to experiment and fail. This taught me a lot and turned me into the software engineer I am today. I realised was robbing them of that valuable experience. I am more ok now with letting them pick a sub-optimal solution, as long as it doesn't directly affect the business.

I like the term. I am going note that down. Thanks!

Re: The Senior Engineer’s Guide to Helping Others Make Decisions

#24

Post by duncanawoods »

kelnos wrote: post #18
duncanawoods wrote: post #13

The real way a senior engineer trains juniors is by selecting appropriate work. They thread the needle of a number of factors: it needs to be done, its within reach, will build their skills, will educate them on product/business/process, they will find rewarding, will give ownership, relevant staff can support them etc. These factors are so important that the senior engineer might need to negotiate with the product m…

> What can't really happen is for a junior to suggest work. Junior engineers should feel welcome to suggest work. They should also be ok with having that suggestion rejected or put on the back burner because it's not pertinent to the current product/business goals. Depending on how the company is run, the senior can make the call, or involve a product owner, as to whether the junior's suggestion is something that the…

Yep, poorly expressed on my part. I meant it more that we can't really expect juniors to choose their own work and work off the own view of priorities. The discussion itself can be valuable but more often than not can't happen.

The pathological case is the newbie who fights every request to complete high priority work in preference to their own ideas when they don't have enough understanding of the business to have such strong opinions. They slow everything down and the continuous resistance can make them toxic to work with.

Re: The Senior Engineer’s Guide to Helping Others Make Decisions

#25

Post by PakG1 »

duncanawoods wrote: post #24
kelnos wrote: post #18

Earlier quoted context omitted.

> What can't really happen is for a junior to suggest work. Junior engineers should feel welcome to suggest work. They should also be ok with having that suggestion rejected or put on the back burner because it's not pertinent to the current product/business goals. Depending on how the company is run, the senior can make the call, or involve a product owner, as to whether the junior's suggestion is something that the…

Yep, poorly expressed on my part. I meant it more that we can't really expect juniors to choose their own work and work off the own view of priorities. The discussion itself can be valuable but more often than not can't happen. The pathological case is the newbie who fights every request to complete high priority work in preference to their own ideas when they don't have enough understanding of the business to have s…

These are excellent opportunities to sit down with the junior engineer and explain how organizations are complex, incomprehensible decisions are often made from a birds eye view with a longer-term view (in good organizations), and that we all need to be patient and teachable to grow. I've seen too many older people who have never gone through this mentorship, and they still can't understand why nobody listens to them or promotes them. They just become very angry toxic people. Nip it in the bud when they're young to help them get the right attitude of wanting to learn and wanting to collaborate with others; that could be the difference between someone becoming a productive and successful person later in life and someone becoming a bitter and unsuccessful person.

Yes, there are some young people who can't be helped. But I imagine most can be helped. I used to be young and arrogant too.

Re: The Senior Engineer’s Guide to Helping Others Make Decisions

#26

Post by jdmichal »

asadjb wrote: post #6

I agree with the core premise of this post; you shouldn't put down ideas by junior developers by just flatly saying no. But we can't just go around letting junior developers do whatever they feel is a good idea because "it's a learning opportunity". I get that the most direct way of learning is to make mistakes and learn from those. But there's an easier way too. Read books, talk to people, get the benefit of others…

I use a "touching a hot stove" analogy:

There's a hot stove in the room. Do you want every engineer to touch the hot stove to find out it's hot? Or do you want to take one engineer who's well equipped to find out how hot the stove it, find out it's hot, then notify everyone that it's hot?

I don't usually use the analogy for this particular argument, but it works here also.

Re: The Senior Engineer’s Guide to Helping Others Make Decisions

#27

Post by duncanawoods »

PakG1 wrote: post #25
duncanawoods wrote: post #24

Earlier quoted context omitted.

Yep, poorly expressed on my part. I meant it more that we can't really expect juniors to choose their own work and work off the own view of priorities. The discussion itself can be valuable but more often than not can't happen. The pathological case is the newbie who fights every request to complete high priority work in preference to their own ideas when they don't have enough understanding of the business to have s…

These are excellent opportunities to sit down with the junior engineer and explain how organizations are complex, incomprehensible decisions are often made from a birds eye view with a longer-term view (in good organizations), and that we all need to be patient and teachable to grow. I've seen too many older people who have never gone through this mentorship, and they still can't understand why nobody listens to them…

I think quite a few successful founders fit in the "can't be helped" category so its not the end of the road. Those born to be the tip of a spear can be nearly unemployable as juniors.

Re: The Senior Engineer’s Guide to Helping Others Make Decisions

#28

Post by OliverJones »

Senior engineers are, by definition, survivors in the engineering trade. We weren't driven out to open pizza shops or become midlevel product managers.

Most of us senior engineers have made our share of mistakes. We've had people help us understand and correct our mistakes. "rollback!"

The job of any engineer is to work ourselves out of every job, so we can do other jobs.

Our job as senior engineers is this: give junior engineers the power to become senior engineers. Help them use their fresh-out-of-school knowledge to solve real problems in sustainable ways. When they make mistakes, don't punish them. Instead help them correct the mistakes, learn from them, and move on. They will have to live with the consequences of their decisions

Help them gain perspective on broad systems and industry issues. In this article's example, that might be by asking the question "PERL, huh? Maybe you should take a quick look at job openings for PERL folks. When your system becomes totally mission critical you'll want to hire somebody to help you." You could say the truth: "PERL sucks, I know because I hacked PERL for three years when I was a wee little lad." But saying that doesn't help somebody beccome a senior engineer.

This all is especially true when we have the privilege of following the rule, "never hire anybody unless they're smarter than you."

Re: The Senior Engineer’s Guide to Helping Others Make Decisions

#29

Post by humanrebar »

asadjb wrote: post #6

I agree with the core premise of this post; you shouldn't put down ideas by junior developers by just flatly saying no. But we can't just go around letting junior developers do whatever they feel is a good idea because "it's a learning opportunity". I get that the most direct way of learning is to make mistakes and learn from those. But there's an easier way too. Read books, talk to people, get the benefit of others…

> But we can't just go around letting junior developers do whatever they feel is a good idea because "it's a learning opportunity".

I don't think anyone wants junior developers to do "whatever they want". That's not really what's being said, so refuting it doesn't mean much.

But these days, with deterministic deployments, virtualization, and containerization, there's a heck of a lot a junior developer can do in a harmless way. If they want to try applying a consensus algorithm instead of locking a database record, give them some VMs, express your concerns, and wish them luck. Most importantly, let them know what would make the project successful and what would make it a waste of their time.

Re: The Senior Engineer’s Guide to Helping Others Make Decisions

#30

Post by taneq »

aequitas wrote: post #11
asadjb wrote: post #6

I agree with the core premise of this post; you shouldn't put down ideas by junior developers by just flatly saying no. But we can't just go around letting junior developers do whatever they feel is a good idea because "it's a learning opportunity". I get that the most direct way of learning is to make mistakes and learn from those. But there's an easier way too. Read books, talk to people, get the benefit of others…

Totally agree there, sometimes there is room for learning and mistakes but not everything must become a learning opportunity otherwise nothing will get done. I'm currently raising a toddler and find great parallels there compared to coaching a junior. It's always good to explain why something is bad/wrong to my kids and allow them to learn. But if w're in the middle of crossing the road that's not the time and place.…

> But if w're in the middle of crossing the road that's not the time and place.

I'm facing the same thing right now and I keep thinking back to what my mum did: It's always OK to ask why, and this question always deserves an answer, but you need to accept that sometimes the answer is "just trust me, I'll explain later."

Post reply on HN