Hacker News new | past | comments | ask | show | jobs | submit login
The Senior Engineer’s Guide to Helping Others Make Decisions (silverwraith.com)
315 points by Nycto on Nov 12, 2017 | hide | past | favorite | 60 comments



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.


> 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 they should be working on or not. But I think the OP's point about tone is important: being dismissive about it is demoralizing and isn't helping the junior grow. Explaining why (to borrow the example from the article) it might be ok to lose a week's worth of data, or even why they just currently have bigger fish to fry, but will revisit the idea later... that shows respect for the junior's desire to grow and establish ownership while giving them a taste of knowledge and experience that you have but they don't.


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.


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.


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.


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.


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.


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


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

Yes and no. I think the best kind of rejection is the kind that convinces the rejectee that the rejection is well and proper, certainly. But at the end of the day I want to see some measure of humility in a junior engineer. Blind trust is a bit much, to be sure, but the junior should have some grasp on the idea that they don't know everything, can't know everything, may not have all the context (context which they do not always need to do their job), and they should just accept it and move on. Some battles are worth fighting, but many are not.

Put another way: a company is not a democracy. Consensus is nice, but if we had to build consensus around literally everything we did, we'd get a lot less done. Sometimes it's absolutely fine and proper to say "we're not doing that right now, and I don't have the time to get into the nuts and bolts of why".

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

Agreed, those are crappy, insulting, disrespectful explanations.


oh yeah, i'm definitely not expecting an on the spot explanations of every single thing, but eventually i'd like an insight in to why something was rejected (if it's a major thing), 'tis all. That can be later on in the week or when appropriate, or after fires are out or whatever.

Not saying there needs to be consensus (i.e: I agree), I don't necessarily have to agree with every single thing I've been asked to do in order to do it, sometimes a job's a job.

When I was composing that post I was thinking at a relatively coarse level of a previous experience (which to be fair is at a different level to the original article).


Yes, did you miss where I flat-out say that you have to do that in my post?


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


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

https://news.ycombinator.com/item?id=8649415


I'm not sure I'd be comfortable calling myself "senior" in job titles, but I often end up saying:

> I know this is a "do what I say not do what I do" situation, but please X because we've had problems with Y.


Agreed. The really hard part, to me, is to get people to stay out of each others' way.


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.


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.

There are so many events in life that shape us, looking back at myself at my earlier career I can't understand how I got where I am now with how stupid I was then and the opinions I held.

I think it has a great deal to do with being able to see things in a different way and having the experience to be open for certain ideas. But I currently still have a hard time at recognising this in myself or others. And allow to know when you can go for the next step.


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


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

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

Not everyone learns the same. Some people may learn significantly faster and/or more effectively if they are allowed to make mistakes - to see/experience the difference. I think this a good approach for simple problems. However, if the problem is highly complex and time consuming, its not as practical as the time cost to redo, as the work is too high. Thats where you do the research and reading. It requires a balance.


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.


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.


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


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 unproductive

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


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


That’s a good observation. I’ve also worked at organizations where the policy pendulum swings.

For example, “Gotta release code quickly” to “quick is good, but all code must have unit tests and rigorous code reviews” to “gotta be quicker, can’t always be holding things up because of a rejected code review!”

I’ve also worked places where that didn’t happen because management, and the engineering culture, were strong.


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


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 problems

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


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.


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


"Help them use their fresh-out-of-school knowledge to solve real problems in sustainable ways."

I always wonder why waste the best and most creative years of young people at school teaching them things that they will not use in real world work environment. Is it not much better if the novice programmer enters the work environment without going to school first and learns the job by doing?

I especially object to the academic way of teaching a subject which requires the student to learn the whole field before issuing him a license to practice. This is like teaching someone who wants to tend to his small garden the entire science of botanics and require him to know all the plants in the world before allowing to play in his backyard garden.

Sorry for off-topic comment.


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.


I completely agree, and in writing this post it was one of the pieces of feedback that came up. Ultimately we decided to go ahead with the verbiage because it would be the most easily understood, but the _message_ here is not about junior vs senior or organisational hierarchies. It's about peers and interactions between more and less experienced persons.

I interact with people daily who are far more "senior" to me on specific topics, and I to them on other topics.


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


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


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!


Apologies, this kind of became a novella.

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

It was a problem for me too, but in a different way. I feel like I was resented by my teammates for being a shooting star. I was younger then so there's a strong possibility I was hot-dogging it a bit unintentionally. I was definitely getting first pick at all the coolest projects, which of course I enjoyed.

I'm not entirely confident that more is being accomplished now that I'm a rising tide. Statistically I think there's some evidence that isn't the case. For example, there's Price's Law which states that half the productivity is completed by the square root of the people in the domain. The following is really rough math just to put some plausible numbers on it... So if there's 9 people on the team, I was one of the 3 people doing half the work, and the other 6 did the other half of the work. That means I was individually accomplishing 16.6% of the work, and the 6 were each accomplishing 8%. If by being a rising tide my individual productivity is cut in half, then the other 6 people have to improve their individual productivity by nearly 3% of the total work, or 35% over what they were doing before. I have no confidence that the other people have improved their productivity by 35%. If I could reliably improve worker productivity by 35%+ I'd be a lot wealthier. However, I do believe people enjoy working with me more, and consequently I have a better experience at work.


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


I think the point (something I struggle with personally) is more that even if you do happen to know the ideal way to do something, it doesn't need to be done that way, and letting someone junior figure out how to do it their own way can still be sufficient. That has the added bonus that the junior will learn much better than if you were to dictate their path exactly.

Of course, sometimes letting a junior engineer do something their own way can fail to be sufficient entirely; knowing your junior engineers and their capabilities well enough to know how much rope to give them on a particular task is yet another skill to be honed.


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.


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.


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.


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.


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.


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.


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.


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.


Of course, I'm sure this highly depends on the individual person, the type of work, and the project itself.


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.


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.


I think we may be using different definitions of "senior" here - to wit, the thread is about senior engineers, and you're talking about senior citizens.


Next level: look into ways of doing hot backups.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: