The Senior Engineer’s Guide to Helping Others Make Decisions
silverwraith.com
The Senior Engineer’s Guide to Helping Others Make Decisions
1–10 of 63 posts
Re: The Senior Engineer’s Guide to Helping Others Make Decisions
#2Excellent points. I'd like to think my job is making sure everyone around me ends up better than me.
Re: The Senior Engineer’s Guide to Helping Others Make Decisions
#3Language 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?"
Re: The Senior Engineer’s Guide to Helping Others Make Decisions
#4Excellent 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?
Re: The Senior Engineer’s Guide to Helping Others Make Decisions
#5There 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).
Re: The Senior Engineer’s Guide to Helping Others Make Decisions
#6I 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.
Re: The Senior Engineer’s Guide to Helping Others Make Decisions
#7Nice this is just what I need, as I am being asked to take on more senior responsibility
Re: The Senior Engineer’s Guide to Helping Others Make Decisions
#8I 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.
Re: The Senior Engineer’s Guide to Helping Others Make Decisions
#9"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?).
Re: The Senior Engineer’s Guide to Helping Others Make Decisions
#10The 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.