DEV Community

loading...

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

ben profile image Ben Halpern ・1 min read

Discussion

pic
Editor guide
Collapse
sunnysingh profile image
Sunny Singh

Avoiding clever code.

You feel smart writing clever code, and you may even justify it by saying it's less code. However, code should be explicit and thus be understandable by everyone. Even if that means writing slightly more code.

Collapse
ben profile image
Ben Halpern Author

For juniors who might be reading, can you give an example of clever code and a good alternative?

Collapse
sunnysingh profile image
Sunny Singh

Good idea. Clever code typically comes along with learning intricacies of a language, so in JavaScript it's totally valid to write an if condition like this:

isDataValid && submitData();

This totally works, but with a few more characters, we can make the intention more explicit and clear:

if (isDataValid) submitData();

Here's another example. Let's say we need to set a timeout of 5 seconds. We can use clever code here too:

setTimeout(() => {
 // run this after 5 seconds
}, 5e3);

Woah, what is that 5e3? It's exponential notation, and while it looks cool and is less characters, is totally unnecessary. Just use a regular number:

setTimeout(() => {
 // run this after 5 seconds
}, 5000);

Even better would be to extract to a variable like FIVE_SECONDS so that you don't have to do any conversion between milliseconds to seconds.

Thread Thread
clovis1122 profile image
José Clovis Ramírez de la Rosa

The first example is actually OK in my opinion, short-circuit is a handy feature most of the times, for things such as JSX you don't really have another succinct alternative.

Take a look at this one which I found in an old codebase, back in the days:

var Ticket = function(id, name, autoAssign) {
  this.id = id*1;
  this.name = name;
}

There're a lot of obscure ways to take advantage of JS's type cohesion, but you'll quickly lose track of what this kind of code means. Further, it might even have surprising, unexpected behaviors. There's nothing wrong doing:

this.id = Number(id);
Thread Thread
satansdeer profile image
Maksim Ivanov

Great point! I would add that "clever code" is often is just saving symbols, while sacrificing readability, expressiveness and distorting meaning.

In the example with "&&" we rely on the fact that in JS code on the right part of logical AND won't be executed. So it is sort of a "hack". And I think that majority of such "clever code" examples are in fact hacks.

It's important to understand that when we write code - we have different sorts of stakeholders. And one of important categories of those are developers themselves!

It is important that code not only performs some useful action, but is also convenient to work with and is understandable.

Thread Thread
sunnysingh profile image
Sunny Singh

Maksim nailed it.

Regarding JSX though, it's a totally valid use case for using && and ternary operators since you're conditionally rendering pieces of UI this way. From a declarative perspective, it's fairly clean.

Love the Number(id) example too. Not only does it handle null values, but you can more clearly understand that you're converting to a number.

Thread Thread
mortoray profile image
edA‑qa mort‑ora‑y

I disagree that 5e3 is clever. Exponential notation is something that every coder should learn. It appears in a lot of places and is much clearer that expanded numbers.

I did a lot of work with nanoseconds much, and I would have to see 1500000000 in the code versus 1.5e9. With larger numbers the exponential format is preferred.

Of course, I'd also like a language that allows separators (I did in Leaf, like 5_000.

Thread Thread
mortoray profile image
edA‑qa mort‑ora‑y

Note though, on the second I think any api that accepts something other than seconds for duration by default is broken. Seconds is the natural time, milliseconds is unusual. Thus a conversion function would be nice to see there.

Thread Thread
sunnysingh profile image
Sunny Singh

It's clever in that scenario because seeing the exponential notation for most people will require more brain processing power than simply seeing 5000 milliseconds or 5 seconds.

It also really just depends on what you're building. Web development rarely requires you to use exponential notation, and so declaring it as "something that every coder should learn" is not an absolute that I can get behind.

Collapse
elliot profile image
Elliot

I agree.

But writing clever code for fun can be pretty fun.

As long as other people aren't ever going to be burdened by reading your code-golfed 5 character insertion sort, I think it's fair game :)

Collapse
jsn1nj4 profile image
JSn1nj4‍‍👨‍💻

I was going to mention that. When using something like Codewars, it's really easy to see clever solutions by others and then possibly get into the habit of always trying to be clever too.

It is fun to try to be clever on stuff like that, but it's almost never necessary—at least not to that degree.

Thread Thread
napoleon039 profile image
Nihar Raote

I've been doing that a lot in CodeWars. Putting the entire code in a single return statement. I'm talking about converting a string to an array, running map and reduce on it, then converting it back to a string in a single return statement.

Thread Thread
elliot profile image
Elliot

Yea exactly what I'm talking about :) It's fun right!

Collapse
elmuerte profile image
Michiel Hendriks

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? -- Brian Kernighan

Collapse
sammyisa profile image
Sammy Israwi

I've had to struggle with this myself! I've had the urge to grab an existing, working piece of code and rewrote it to be shorter and sometimes less understandable. It's for sure something I have become more aware of and that I have to think about when refactoring code.

Collapse
jhuebel profile image
Jason Huebel

Unfortunately, there are many frameworks today that suffer from this mentality.

An excellent example would be a framework like Laravel. Certain aspects of it are really nice. Eloquent ORM, for instance. But other aspects create levels of abstraction that make the code difficult to understand. Are some of the ideas clever? Yes. But they make maintaining the code confusing.

Collapse
jdforsythe profile image
Jeremy Forsythe

I totally agree. Writing code is an art and, like painting, there are many styles.

When painting something abstract, the artist surely knows not all viewers will understand the painting. When writing code, you should strive to paint photorealism, where the code can't be misinterpreted.

There are times where obscure code can't be avoided, though. If it's convention in a framework you're using, for instance, then it's okay because later coders should understand the convention. Otherwise, it's a perfect opportunity for an explanatory comment. This also helps you not try to be "clever" because writing the comment nullifies any handful of keystrokes saved by being so.

Collapse
sunnysingh profile image
Sunny Singh

That's a good point. If you must write clever code, then at least provide a comment explaining why that code is there.

Collapse
garrett profile image
Garrett

This, and your examples, were very helpful. Thank you!

Collapse
ben profile image
Ben Halpern Author

One thing that comes to mind for me:

An insecure justification of why you don’t know something (off the top of your head). Some folks lose this habit over time, others only get worse.

It’s okay not to know something, you don’t have to explain the specific reason why you don’t happen to know that. Sometimes you just won’t know a thing and you don’t need to nervously elaborate on why you don’t know.

Collapse
steveblue profile image
Steve Belovarich

😮 I’ve been senior or lead/principal for about a decade and sometimes I think I’m the only one who will say “I don’t know. I’ll do some research and get back to you.” I’m happy there are others who will do the same. I’m an engineer Jim, not an encyclopedia.

Collapse
workingwebsites profile image
Lisa Armstrong

"I don't know everything, if I was that smart, you couldn't afford me. ;-)
However, let me look into it and I'll get back to you. "
... and then get back to them.

Collapse
jrohatiner profile image
Judith

I'm a big proponent of "I don't know" being a safe phrase on my team. I would much rather hear "IDK" than hear (and see) someone grasping for an answer.

That being said, it helps nubies to empathize. Let them know this is very common. When new devs start working, I think they are used to being the smartest person in the room their whole lives. Suddenly, everyone is just like that! It's a shocker for them. Eventually the shock wears off and they become more comfortable being vulnerable.

Wish I had a boatload of humility to pass around. We could save a lot of time getting through this issue!

Collapse
mortoray profile image
edA‑qa mort‑ora‑y

Thinking you're right because of many years of experience.

Collapse
darrenvong profile image
Darren Vong

This! It's so frustrating especially when they are a little bit out of touch on how some things work, due to them taking more responsibility on a managerial role and so have less time to keep up to date with tech at the coding level. But they'll still want to walk over you and dismiss your opinion because you're more junior compared to them 🙄

Collapse
scottishross profile image
Ross Henderson

My new job involves dealing with a 30-year-old Oracle Team. They still code in obsolete ways, that even Oracle advise against. "But it works still!" ? angery

Collapse
kaleigh profile image
kaleigh

This! Also, assuming you have more years of experience. So many people assume I've been doing this for a couple of years, when in reality, it's been 10+ years.

Collapse
gypsydave5 profile image
Collapse
steveblue profile image
Steve Belovarich

☝️ The most important of them all.

There are absolutely brilliant women in STEM and they deserve equity.

There is a problem though in the calculus for placing more women in positions in tech related fields. The men are the people who need to change, not the women. It’s not that women need to be interested in STEM. Plenty of them are. The men need to be prepared to treat the women equally. That isn’t the case in so many places I’ve worked.

Collapse
ben profile image
Collapse
rgeraldporter profile image
Rob Porter

Being insulted if someone tries to explain to them something they already know. It enforces the (bad) idea that everyone should know everything, and shuts down devs who preface a conversation with some required information just in case the other party isn't at the same level or might think they're talking about something else.

Collapse
teej profile image
TJ Fogarty

Checking emails after hours. I used to be a fiend for it, but I've come to realise my time is worth more.

Collapse
scottshipp profile image
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”).

Collapse
henryjw profile image
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.

Collapse
twigman08 profile image
Chad Smith

Saying "it's simple, I don't know what you're missing" to people when explaining something.

Just saying it's simple most of time when explaining things can make someone feel dumb if they don't get it. Adding the "I don't know what you're missing" part just makes them feel worse. Trying to sound "elite" isn't helping anyone and is not needed.

Collapse
elliot profile image
Elliot

I think many engineer's passion for programming and creating tend to decline as they spend time in industry. They may look back at their old hobby projects and remember the nights they stayed up fueled by their desire to make something with a sort of nostalgia. They remember these as the good times when they really cared and were excited about what they were doing.

Although I'm not a senior engineer by any means, I think it's important to allow your passions to change along with you. I want to remember what I love about programming and engineering, find new things to love, and let some things I love go. That way I can allow myself to find the things that make every single day of my career enjoyable.

Collapse
georgecoldham profile image
George

To add to this, its okay if your passion isn't coding. Trying to pretend it is and burning out isnt good for you, your employer or your long term health.

Collapse
cjbrooks12 profile image
Casey Brooks

Not being offended when someone comments on a PR, files a bug report, asks you to refactor something you wrote, etc.

It's not personal, and they're not saying you're a bad developer.

Let me say that again (in large part to myself, because I was really bad about this): it's not personal.

In time you'll learn that you're not a perfect developer, and all these things are actually trying to help you get better at your craft. They just want to help you improve the product, the codebase, and yourself.

Collapse
safderiqbal_ profile image
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.

Collapse
theringleman profile image
Sam Ringleman

Assuming that people know the systems architecture, and underlying infrastructure. It is very important to get a high level overview of how a system works, even if you don't fully understand how it all works. At least it will help you in understanding the flow of data.

Collapse
afifsohaili profile image
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.

Collapse
levivm profile image
Levi Velázquez

Try to understand the whole thing before implementing.

When we are junior, most of the times, in order to resolve an issue we look up just for the code, do a kind of copy/paste and continue, because the topic seems pretty hard at first glance, when we are senior we believe that it would be easy task and we don't investigate, read properly, etc and start implementing things, some hours later, we ended up deleting the code because it wouldn't work and start trying to understand the topic from scratch.

Collapse
wes profile image
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.

Collapse
matteojoliveau profile image
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.

Collapse
mkimont profile image
Matt Kimek

As I understand topic asking what juniors shouldn't do what engineers seniors do:

  • using new vendors/mods/libs/languages
  • writing script for backups/updates/disaster recovery/deployments etc
  • working on live servers
  • reading blogs/news at work
  • talking a lot about anything with colleagues at work and 'do nothing'
  • writing clever code
Collapse
conw_y profile image
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.

Collapse
jmervine profile image
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.

Collapse
brob profile image
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!"

Collapse
jmcp profile image
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?"
Collapse
jmcp profile image
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?

Collapse
jibbi profile image
jibbi

Cynicism >.>

Collapse
plasticruler profile image
David

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

Collapse
monkin profile image
MONKIN

Not being a dick on any position, e.g. "You don't know nothing, you just started working here!", "Juniors can't speak", "I know better, rewrite everything as I want or I will fire you!". :)

Collapse
jrohatiner profile image
Judith

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

Collapse
tamouse profile image
Tamara Temple

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

Collapse
tamouse profile image
Tamara Temple

Forgetting they have survivorship bias

Collapse
ca55idy profile image
ca55idy

Arrogance