The Senior Engineer’s Guide to Helping Others Make Decisions • Hacker News Board

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

#51

Post by avleenvig » Sun, Nov 12, 2017, 11:07 PM UTC

taneq wrote: post #30

aequitas wrote: post #11

Earlier quoted context omitted.

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

As long as you do explain later ;-)

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

#52

Post by avleenvig » Sun, Nov 12, 2017, 11:10 PM UTC

shados wrote: post #47

The article is excellent, and the way it suggests to communicate is great. I'm certainly taking notes. As a team lead myself, I've screwed up on this more than my share of times. Within a team, these advises are gold. At a higher level though, I can't help but feel our industry is taking so long to mature because everyone has to keep making the same mistakes over and over and we don't learn from history. Conversation…

Thanks, glad you liked it :-)

There's definitely a strong bias in our industry towards "greenfield" things - everyone wants to do the fun, exciting, initial work. But once the new shiny coating has worn off there's a ton of really hard work to do with resilience, robustness, scaling, etc. Too many people just give up at that point, get bored, and do something else.

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

#53

Post by avleenvig » Sun, Nov 12, 2017, 11:16 PM UTC

tboyd47 wrote: post #42

luckydude wrote: post #39

This article works in theory, not so much in practice. The theory is fine, it's the reality of working in the real world where it is less fine. I think the author needs to rethink his approach in the context of a limited budget. If your goal is to grow your junior engineers at any cost, great article. If your goal is to balance the benefit to the company/project with growing a junior engineer, less great. And perl? F…

It takes creativity to carve junior-level tasks out of a real backlog. But it can be done. You just need to have buy-in from your manager. They hired the junior not expecting them to be productive right away. What they usually don't realize is that they need the seniors to spend time mentoring them in order for them to ever be productive. If they can't allow time for that then it's just not a good place for juniors.

Indeed. As your business grows (it is growing, right - that's why you hired more engineers?) you need to scale yourself. If you don't, eventually you'll become the bottleneck.

Following this process has a definite cost up front. You have to give up doing some work in order to help someone else grow and learn the system. But once they do, your business now has an extra version of you. Not as experienced, but hopefully still pretty good. Let that person handle more work, trust them, and hire another person. Rinse and repeat.

The truth is that when you get more senior, you almost have to stop focusing solely on knocking out code or fixing problems yourself, and commit to helping others learn how to do it.

If you become the bottleneck, the business will start to work around you and then you will become irrelevant.

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

#54

Post by avleenvig » Sun, Nov 12, 2017, 11:20 PM UTC

quickthrower2 wrote: post #7

Nice this is just what I need, as I am being asked to take on more senior responsibility

You should definitely make sure this - the teaching and growing of other engineers - is part of your responsibility. It's the only way to scale yourself up.

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

#55

Post by dennisgorelik » Sun, Nov 12, 2017, 11:58 PM UTC

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…

> Junior engineers should feel welcome to suggest work.

Of course. Senior developer should welcome Junior's feedback and then deliver detailed critique on the suggestion.

Junior developer should learn from it and try to make his future suggestions better.

Rinse and repeat until Junior would come up with something useful.

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

#56

Post by cema » Mon, Nov 13, 2017, 9:45 AM UTC

aequitas wrote: post #32

jdmichal wrote: post #26

Earlier quoted context omitted.

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.

However on the other end of the spectrum you have The monkey experiment, where you end up with 5 monkeys that don't climb the ladder for the banana reward, but none of them knows why not to. I sometimes still find it a challenge to walk the line between sticking to a principle and letting it go. But it's my opinion you should always stay open to let any of your principles be challenged (by someone else or yourself).…

Document your decisions, explain assumptions, limitations, and reasoning. It helps immensely.

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

#57

Post by avh02 » Mon, Nov 13, 2017, 2:22 PM UTC

nkjoep wrote: post #21

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…

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

I agree but have to be careful with this one. I'm relatively junior and we had a lot of "it's not the time for this right now" when I believed it was... You have to win somebody over with your arguments rather than a unilateral explanation IMO. (edit: what I'm saying is - prove your explanation and convince the person of the business priorities, you can't say "it's confidential" or "we can't talk about why" or "the decision was made above our head".)

Also when your team has many priorities and are tackling many fronts and one of your frustrations - as a team - is your rarely addressed tech debt (due to business/monetisation priorities), then the team is up for demotivation.

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

#58

Post by aequitas » Mon, Nov 13, 2017, 2:45 PM UTC

cema wrote: post #56

aequitas wrote: post #32

Earlier quoted context omitted.

However on the other end of the spectrum you have The monkey experiment, where you end up with 5 monkeys that don't climb the ladder for the banana reward, but none of them knows why not to. I sometimes still find it a challenge to walk the line between sticking to a principle and letting it go. But it's my opinion you should always stay open to let any of your principles be challenged (by someone else or yourself).…

Document your decisions, explain assumptions, limitations, and reasoning. It helps immensely.

Indeed, I also started moving from documenting what code does to explain what I intend the code to accomplish (because code already explains clearly find what it does by itself). By communicating at this level the overarching idea does not get lost and allows for much better refactoring or debugging.

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

#59

Post by aequitas » Mon, Nov 13, 2017, 3:02 PM UTC

avleenvig wrote: post #51

taneq wrote: post #30

Earlier quoted context omitted.

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

As long as you do explain later ;-)

Not necessarily. Someone might be to young to understand no matter how you explain. Like I said above when looking back on my career, I see things now in a way I could explain to myself a few months/years back. And some people might never be open for some idea's at all.

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

#60

Post by sprafa » Mon, Nov 13, 2017, 5:18 PM UTC

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…

Feel like I struggle with exactly this - I had to get fired to get my attitude to change and I'm still working hard at it. Would definitely benefit from mentorship.