What habit do many senior engineers have that juniors should try to avoid adopting?

Comments

[Tamara Temple]

Forgetting they have survivorship bias

[ca55idy]

Arrogance

[Judith]

Bad posture. If you don't sit up straight you will regret it.

[Tamara Temple]

we have been ground down by the trials and tribulations of software dev :D

[jibbi]

Cynicism >.>

[Bryan Robinson]

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

[Afif Sohaili]

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.

[Wes Souza]

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.

[bleskop stevens]

Needlessly using anything from the System.Linq namespace when a for loop would work fine. Those extension methods are hard to read and debug.

[James McPherson]

A few things:

• taking a moment (or 10) to understand the whole problem being addressed
• xkcd.com/1205/
• taking the "you" out of code review
• ask about intended side effects
• ask about *un*intended side effects
• (with very few exceptions) make your code understandable by anybody who comes along afterwards to maintain it.
• make your block scope explicit (see github.com/illumos/illumos-gate/bl... for a historical example)
• DO NOT IGNORE ERRORS -- but know when it's actually safe to do so
• extend the scope of your fix -- ask "what else could go wrong that is related to what I'm fixing?"

[James McPherson]

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?

[Safder Iqbal]

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.

[Jonathan]

Undervaluing and under-monetising their work!

I’m thinking here of people like Ryan Dahl, the creator of NodeJS, who built a product used by hundreds of Fortune 500 companies and millions of developers world-wide, but made only a fraction of the profits that the VCs behind Nodejitsu made.

This is not to slight investors – I’m an investor myself (on a vastly smaller scale). Just to warn my future senior developer self to be on the lookout for monetisation opportunities, and not let them slip away into the hands of those who are more aware of the financial and business side of things.

[Matteo Joliveau]

Thinking that known solutions to known problems are the best, if not the only, solutions.

Computer science evolves every day, and new solutions might be more efficient, or simpler, or just worth checking out.

[Joshua Mervine]

What a co-worker of mine refers to as "licking the cookie", which is to say getting attached to, or feeling ownership of, a code base. This is especially true in highly collaborative environments. I've seen this in two ways, the first is folks getting frustrated when a project dies on the vine, or is sunsetted. Priorities change, technologies shift. This is part of business. The second is harder. When someone rewrites parts of or takes over anothers code base. This can cause feels, and while understandable, again it happens.

Conversely (and ironically perhaps) is, taking over or rewriting anothers codebase with out direction to or having a conversation about doing so. Too many times I've seen (and done it myself) a more senior level engineer come in and bowl over a more junior engineers work. Even when necessary, there is a lost teaching moment here and it's bad form.

[Henry Williams]

Becoming complacent with your job or knowledge. I've seen many senior developers that get comfortable maintaining some system they built. Software development and technologies are constantly evolving, don't get left behind!

With that said, that doesn't mean you should learn every shiny technology that comes out. But it does mean that you should aim to learn the fundamentals and pick up the latest tools at least every couple of years to stay relevant.

[scottshipp]

Juniors should avoid adopting the gatekeeping behavior a lot of seniors adopt. No developer should think themself superior just because they work for a large tech company, write in a certain language, use a particular framework, went to a certain school, or any of another umpteen things.

Related to this are dogmatic behaviors like one line absolutist comments on code reviews without justification (like “Never return null”) or believing in one right tool for a given job (“I’d only use Spring to write web services and anyone who does something else is an idiot”).