In one of the YC videos someone says that in Silicon Valley when you suggest an idea people think about what would happen if it did work rather than all the possible failure modes. From that perspective, the article starts with failure modes and ends up with success modes. YC startups tend to be young people, I suspect because they don't have "experience." While the junior/senior dichotomy is one aspect, the article is even more interesting when framed in the context of success-mode thinking versus failure-mode thinking and how to take effective action.
The Senior Engineer’s Guide to Helping Others Make Decisions
31–40 of 63 posts
Re: The Senior Engineer’s Guide to Helping Others Make Decisions
#32I 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.
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). And it still surprises me how I can shatter some of my deep rooted principles because of a new/different look on things.
Re: The Senior Engineer’s Guide to Helping Others Make Decisions
#33The 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…
Agreed. When I first started at my company, our graduate programme involved a ‘showcase project’ where we had to think up a problem to solve within the business.
It certainly wasn’t effective in allocating effort - most groups did a month of research only to find out why it wouldn’t work, and those ideas that were pursued were 90% dropped after the showcase presentation. However, failure had important lessons in learning about the business (10k+ people on size) and how to explore it for info.
In a few specific cases, they became genuinely useful ideas that were implemented. Mine, for example, was because it involved us as grads identifying a missing capability in one arm of the business that had been solved elsewhere, however the two arms never talked. The net result was a significant safety mechanism improvement.
In the overwhelming majority of cases, juniors lack the business understanding to vet ideas for those that may work. But I genuinely believe that giving them some rope to go and find out why their ideas don’t work, as opposed to just saying so, can be very valuable for a variety of reasons beyond just learning to logic through problems.
Re: The Senior Engineer’s Guide to Helping Others Make Decisions
#34I saved this comment from jlcfly from an AskHN that was answered a long time ago and have reposted it many times, as I feel it is an excellent philosophy for making your team better.
"Teach them to be better than you. That may seem counterproductive. I have a type A personality, and I have decent coding skills. I've been in your situation a number of times. I also know there's these mythical expert developers out there that I can't seem to find (or afford). So, what to do? A few years ago I realized that if I continue down this path, I'll end up with some serious health issues due to the stresses that come along with having a reputation for being a really good developer. So, I decided that instead of searching for developers better than me, I would teach developers I work with how to BE better. It's taken a lot of patience. And it's taken me quite a bit to LET GO of my way of doing things. I had to take my ego out of the picture. (VERY hard to do.) Nowadays, I realize that developers don't have to BE better than me. I simply have to ALLOW them to do what they do without being so obsessive about it. Turns out, even junior developers really CAN do good work. They just need a little guidance that only comes with experience, and then they need me to get out of their way."
Re: The Senior Engineer’s Guide to Helping Others Make Decisions
#35I saved this comment from jlcfly from an AskHN that was answered a long time ago and have reposted it many times, as I feel it is an excellent philosophy for making your team better. "Teach them to be better than you. That may seem counterproductive. I have a type A personality, and I have decent coding skills. I've been in your situation a number of times. I also know there's these mythical expert developers out the…
Agreed. The really hard part, to me, is to get people to stay out of each others' way.
Re: The Senior Engineer’s Guide to Helping Others Make Decisions
#36This feels like fundamentally the same problem as the whole big company inertia/innovator's dilemma situation. There's value in known-entities, but also a lot of value in trying to reinvent the wheel now and again.
Another problem is it doesn't leave as much room for people to learn from mistakes as companies grow larger and larger. You need wiggle room to get dirty for that to happen.
Re: The Senior Engineer’s Guide to Helping Others Make Decisions
#37I 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.
[deleted]
Re: The Senior Engineer’s Guide to Helping Others Make Decisions
#38With the landscape constantly changing you could argue if we take too much weight on senior perception. For example: "Those 10GB of data would take up too much space, it's BIG DATA, we can't afford that!" ... Junior: We could use my laptop, it has 2 TB.
I don't think any competent senior engineer would say that backups are too expensive without looking at the actual cost first.
Your example doesn't work though - using someone's laptop is likely not secure, reliable, and definitely not appropriate for any compliant data. It really doesn't meet the actual requirements of a true backup.
My backups sit on disks that supports disaster recovery, are proven to be reliable, and meet all compliance requirements for the data we store.
Re: The Senior Engineer’s Guide to Helping Others Make Decisions
#39This 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? For production code? I love me some perl, I really do, and I've written production code in perl (but it took 2 complete rewrites before I figured out how to do maintainable code in perl). I would not let a junior engineer anywhere near perl for production code.
Re: The Senior Engineer’s Guide to Helping Others Make Decisions
#40As the author of this blog post I'd just like to say:
1. Thank you everyone for the positive tone of comments
2. Thank you for the feedback and perspectives :-)