The Senior Engineer’s Guide to Helping Others Make Decisions
silverwraith.com
silverwraith.com
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
"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."
> 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.
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.
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.
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."
> 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.
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.
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.
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.
- "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.
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?).
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.
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?"
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.
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.
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."
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.
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 interact with people daily who are far more "senior" to me on specific topics, and I to them on other topics.
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).
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!
>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.
A real corollary is, you really don't know as much as you think you do sometimes.
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.
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.
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.
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.
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.
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.
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.