The Senior Engineer’s Guide to Helping Others Make Decisions

315 点作者 Nycto超过 7 年前

22 条评论

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 manager to bring appropriate work forward to avoid failure or killing the enthusiasm of the junior.What can't really happen is for a junior to suggest work. The experience and context they lack is for the business, the user and the strategy. The junior's biases for what they think matters are usually much worse that the senior's for what works e.g. they want to improve cosmetic factors or add cool features. Its not that they are wrong, the product might be offensively ugly and the cool features might be game changers, but professional development is a parade of gut wrenching compromises because the constraint is time and resources not imagination and ambition.That said, I agree with the thrust of the article - the risk of senior engineers "fighting the last war" and accruing a set of limiting beliefs is very real and the naive optimism of a junior challenging them is part of the value they bring.

评论 #15680408 未加载

评论 #15681576 未加载

wallflower超过 7 年前

I 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."<a href="https://news.ycombinator.com/item?id=8649415" rel="nofollow">https://news.ycombinator.com/item?id=8649415</a>

评论 #15681641 未加载

评论 #15680948 未加载

asadjb超过 7 年前

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 experience without needing to make those same mistakes again.We don't go about individually discovering why modular design is a good thing, or why at certain scales microservices are a better option. We do the research, talk to others, and figure out that the general consensus is a reasonable one that we can use.There are many learning opportunities even once you implement the currently best known solution. You'll eventually grow beyond what the best solution can achieve, and I feel it's a better use of our times to try to push the boundaries of knowledge at the edge, rather than making junior developers learn the same things over again. As they say, learn the rules before trying to break them.--I do agree that senior developers need to do a better job at communicating with junior developers. I think that in the transition between junior and senior developer, there comes a time when you just start assuming that everyone has the same context and knowledge that you do.When you say "it won't scale" to a junior developer, you might believe that they understand all the subtle connotations that phrase holds. But from the perspective of the junior developer, it feels like an arrogant know it all trying to run from an argument.I think we need to do a better job at explaining why something is a bad idea to junior developers. Learn to see things from their perspective, and communicate in a way that relates to their experience rather than ours.But that's just good advice for life, not just development.

评论 #15680186 未加载

评论 #15680188 未加载

评论 #15680568 未加载

评论 #15680724 未加载

partycoder超过 7 年前

The problems here, to start with, are:- "senior" means a wide range of things to different people.- "engineer" means a wide range of things to different people.Some people are senior because they have technical skills, some are good with processes, some have years of experience, and others due to superficial traits associated with dominance (e.g: posture, voice pitch/amplitude/speech rate, verbosity, being good at interrupting others), some due to interviewing skills... or anything to be honest.This gives origin to a wide range of decision making processes:- from pragmatic to unpractical- from rational to dogmatic- from collaborative to competitive- from respectful to antagonistic- from constructive to unproductiveIf your discussions look like the "Argument clinic" from Monty Python, you've got a problem. If your discussions are toned down because noone wants to sound negative, you've got a problem. If all discussions end up with someone pulling rank, you've got a problem. Try to have: pragmatic, rational, collaborative, respectful, constructive discussions. And focus on the problem at hand, not the person.

aequitas超过 7 年前

"Being a senior engineer means realising not everything should be done the way you want it to be."I think it's funny how these opinions can completely flip over or oscillate over time. In this case:As junior you known nothing so not everything can be done the way you want, then later you think you know a lot more and everything should be done your way, after that you really know a lot more and realise not everything should be done the way you want it to be.Same like Friday deployments. First time you always deploy on Friday until you deploy that bug and you weekend gets destroyed. You never deploy on a Friday again. Until you discover testing and CI which makes Friday deploys trivial again. (maybe until the next time it breaks?).

评论 #15680345 未加载

sb8244超过 7 年前

Language is basic stuff, but hard to do well all of the time. This is a great reminder for the way our language and questions can affect the outcome of work.The only thing that I couldn't help thinking, at the end, is that the senior engineer gives up potential conflict around the language (which it seems to be known may be difficult to maintain) in order to empower the junior engineer to own the decision. However, I get the feeling that this wouldn't be best for the business/team in the real world. In the real world, the question might be posed "What would the perl language give you that language X wouldn't, for this problem?"

shados超过 7 年前

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.Conversations often go like:Engineer A: "I'm going to do XYZ".Engineer B: "Hmm, we've tried XYZ, it exploded in our face"Engineer A: "I've had experience with XYZ on my side project/little startup, it works fine!"Engineer B: "Yeah, it works at first but eventually problems arise and it will blow up"Engineer A: "Whatever, I'm doing it anyway"<6 months later>Engineer A: "See, it worked fine!"Engineer B points at the beggining of some problemsEngineer A: "That's normal!"<6 months later>Engineer B: "Welp, as expected, it all went to hell. Where's Engineer A?"Engineer C: "Oh, Engineer A got bored and quit/joined another company. Looks like you're inheriting it, Engineer A!"Repeat...hundreds of times...for everything.

评论 #15683074 未加载

OliverJones超过 7 年前

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

评论 #15681880 未加载

ilaksh超过 7 年前

My thought is that really good juniors need to be treated as less experienced peers in most (but not all) interactions. A smart, hard working, capable programmer is going to need to feel respected. So the number of times 'junior' and 'senior' get thrown around here is problematic.Which is not to say that there shouldn't be clarity in terms of who gets final decision making or that there is no hierarchy at all. But in most discussions you should treat them as a smart person who probably has good ideas that should be respected. Otherwise why did you hire them? I'm not _quite_ getting that tone from this article.

评论 #15683063 未加载

avleenvig超过 7 年前

As 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 :-)

nullymcnull超过 7 年前

There are some very good points here, but letting the junior go ahead and use Perl (or any language / platform that the company doesn't generally use or support, and that there's no overwhelming benefit to taking on for one small improvement), just to avoid discouraging them and helping them grow? Definitely not.I do realize that part of becoming a senior engineer is being able to make and learn from mistakes like this - that sometimes loose/absent leadership is the crucible that makes them. But at this point the hypothetical senior is allowing unnecessary complexity into things, it's verging on outright dereliction of their bigger picture duty to keep things reasonably homogenous and maintainable. Mentoring juniors into seniors is something that a good senior engineer should spend quality time on, no doubt, but it's far from their primary function - and you certainly don't let your system descend into unmaintainable multiplatform anarchy for the sake of doing so in an optimally non-discouraging way. There's still always going to be a lot of blocking of dumb ideas - it comes with the territory, and not all ideas are salvageable - it's harsh but sometimes you need to hear that to grow, too.Not every junior is a senior waiting to blossom, either - some are just solidly junior and not really equipped with the curiosity or drive to progress no matter what you do. Yes, there's room for bias to seep in here, but still, there's little sense in trying to make seniors out of devs who just aren't cut out for it (some of whom are still solidly dependable pairs of hands for day to day code slinging).

photonios超过 7 年前

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

评论 #15680013 未加载

pugworthy超过 7 年前

> Being a senior engineer means realizing not everything should be done the way you want it to be.A real corollary is, you really don't know as much as you think you do sometimes.

评论 #15680422 未加载

thisisit超过 7 年前

I normally use the - Half way there approach, trying to explain in detail as to why - realizing well that there are my biases at play but in the world of agile and fast moving changes, it is difficult to justify time for experiment and see what happens.But then I look at author's claimed non-bias approach. The perl conversation is still the "half way approach". If a particular language is not used frequently it is easy to lose track of changes and new features/issues popping in.Then there are company coding standards. Sometimes I look at a project where majority of the stuff is written in Java while a particular component is in C++. A lot of time the answer is, it was "easy to do". Even with documentation, it only leads to issues.

thinkersilver超过 7 年前

This methodology is an effective way to leverage the developers in your team. It does rely on a certain discipline that juniours often don't have to drive and refine an exploratory solution into production code.It requires curiosity, an openness to measuring and validating an idea and then driving it home. This sounds a lot like what I'd want from a team lead; but as someone pointed out some juniors aren't destined for leadership either.I love the idea and have made it work, a lot less though than desirable.

luckydude超过 7 年前

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

评论 #15681624 未加载

quickthrower2超过 7 年前

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

评论 #15683113 未加载

v4tab超过 7 年前

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.

bpicolo超过 7 年前

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

psyklic超过 7 年前

In my experience, typically the junior's suggestion can possibly be done. However it often would be complicated to implement well, and I would be concerned how long it would take the junior to complete (if they would complete it satisfactorily at all). So, I agree with the suggestions that it is often more productive if a senior engineer suggests appropriate work.

评论 #15682691 未加载

z3t4超过 7 年前

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

评论 #15681395 未加载

评论 #15682388 未加载

amq超过 7 年前

Next level: look into ways of doing hot backups.