What habit do many senior engineers have that juniors should try to avoid adopting?
For further actions, you may consider blocking this person and/or reporting abuse
For further actions, you may consider blocking this person and/or reporting abuse
Latest comments (55)
Forgetting they have survivorship bias
Arrogance
Bad posture. If you don't sit up straight you will regret it.
we have been ground down by the trials and tribulations of software dev :D
Cynicism >.>
For my money, a knee-jerk reaction of "we can't do that" is something to avoid.
I've worked with many brilliant devs. Once they get a certain level of knowledge and experience, often there's a knee-jerk to a client or stakeholder request that it's not easily possible in whatever platform or code base we're working in. I'd say 75%-90% of the time after that, they usually come back on their own and say "oh, we could do it one of these ways with these trade-offs." But that initial knee-jerk can be disheartening.
I'd like to see more devs say "I'm not sure" before saying "no." A lot of seniors think saying "I don't know" is a bad thing. It's only bad if it's not followed by "But I'll find out!"
Suggesting before listening. It's easy to do this when you have a lot of experience to draw from, but it makes less sense to people since they don't have the same experience. Take a step back, listen, choose your words carefully so that the point is delivered across more effectively.
Trying to solve all issues that are identified in the software themselves. Most times we end up piling up fixes we know how to solve, just because we think we’re the ones that should be solving them.
Let your team deal with them, teach them, and let them solve those issues their way.
Needlessly using anything from the System.Linq namespace when a
forloop would work fine. Those extension methods are hard to read and debug.A few things:
Sigh ... I was sure that when I responded to Ben's post this morning it was about habits that juniors should adopt, rather than should not.
The worst habit I've come across from senior engineers has been the tendency (based on their experience in the past) to shut down a request to consider either a new feature or a new way of doing something - and do so without explaining why.
How are more junior engineers (let alone management!) supposed to understand the problem better if you do not explain things (carefully and without rancour or attitude) to them?
Having strong opinions, weakly held.
It's a fundamental in having a constructive discussion, technical or otherwise. It's also an excellent way to "absorb" knowledge from other developers.
The strong opinions aspect means that you know and put across a compelling argument for the topic of conversation. This doesn't mean that you must be a subject matter expert, only that you can advocate for the topic.
The key is only weakly holding it, and this is something I have been guilty of in the past.
Weakly holding the opinion means you are still open to have your opinion changed based on the discussion. It doesn't equate yourself to "losing" the argument, it just means that you have considered the merits of both arguments and now see the benefits of the apposing opinion.
Not taking this approach can lead to something that Eric Dietrich has blogged about; the expert beginner.
There's also many articles on this principle out there, but I would recommend reading the post by Jeff Atwood.