7 ms·

The Senior Engineer’s Guide to Helping Others Make Decisions

315 points by Nycto 9y ago

photonios 9y ago
Excellent points. I'd like to think my job is making sure everyone around me ends up better than me.
- Consultant32452 9y ago
  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?
  - photonios 9y ago
    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!
    - Consultant32452 9y ago
      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.
sb8244 9y ago
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?"
nullymcnull 9y ago
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).
asadjb 9y ago
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.
- aequitas 9y ago
  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.
quickthrower2 9y ago
Nice this is just what I need, as I am being asked to take on more senior responsibility
- avleenvig 9y ago
  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.
thisisit 9y ago
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.
aequitas 9y ago
"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?).
- dogruck 9y ago
  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.
partycoder 9y ago
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.
duncanawoods 9y ago
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.
- kelnos 9y ago
  > 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.
  - duncanawoods 9y ago
    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.
psyklic 9y ago
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.
- psyklic 9y ago
  Of course, I'm sure this highly depends on the individual person, the type of work, and the project itself.
pugworthy 9y ago
> 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.
- kelnos 9y ago
  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.
amq 9y ago
Next level: look into ways of doing hot backups.
thinkersilver 9y ago
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.
z3t4 9y ago
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.
- PretzelPirate 9y ago
  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.
- throwanem 9y ago
  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.
OliverJones 9y ago
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."
- nyc111 9y ago
  "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.
v4tab 9y ago
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.
wallflower 9y ago
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 https://news.ycombinator.com/item?id=8649415
- Terr_ 9y ago
  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.
- humanrebar 9y ago
  Agreed. The really hard part, to me, is to get people to stay out of each others' way.
bpicolo 9y ago
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.
luckydude 9y ago
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.
- tboyd47 9y ago
  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.
  - avleenvig 9y ago
    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.
avleenvig 9y ago
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 :-)
shados 9y ago
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.
- avleenvig 9y ago
  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.
ilaksh 9y ago
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.
- avleenvig 9y ago
  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.

315 points by Nycto 9y ago

photonios 9y ago

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

Consultant32452 9y ago
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?
- photonios 9y ago
  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!
  - Consultant32452 9y ago
    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.

sb8244 9y ago

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

nullymcnull 9y ago

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

asadjb 9y ago

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.

aequitas 9y ago
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.

quickthrower2 9y ago

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

avleenvig 9y ago
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.

thisisit 9y ago

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.

aequitas 9y ago

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

dogruck 9y ago
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.

partycoder 9y ago

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.

duncanawoods 9y ago

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.

kelnos 9y ago
> 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.
- duncanawoods 9y ago
  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.

psyklic 9y ago

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.

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

pugworthy 9y ago

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

kelnos 9y ago
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.

amq 9y ago

Next level: look into ways of doing hot backups.

thinkersilver 9y ago

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.

z3t4 9y ago

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.

PretzelPirate 9y ago
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.
throwanem 9y ago
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.

OliverJones 9y ago

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

nyc111 9y ago
"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.

v4tab 9y ago

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.

wallflower 9y ago

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 https://news.ycombinator.com/item?id=8649415

Terr_ 9y ago
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.
humanrebar 9y ago
Agreed. The really hard part, to me, is to get people to stay out of each others' way.

bpicolo 9y ago

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.

luckydude 9y ago

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.

tboyd47 9y ago
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.
- avleenvig 9y ago
  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.

avleenvig 9y ago

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

shados 9y ago

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.

avleenvig 9y ago
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.

ilaksh 9y ago

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.

avleenvig 9y ago
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.