Ben Halpern

Posted on Jun 8, 2019

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

#discuss #career

Oldest comments (55)

TJ Fogarty • Jun 8 '19

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

Sam Ringleman • Jun 8 '19

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.

Sunny Singh • Jun 8 '19

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.

Ben Halpern • Jun 8 '19

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

Sunny Singh • Jun 8 '19

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.

José Clovis Ramírez de la Rosa • Jun 8 '19

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);

Maksim Ivanov • Jun 8 '19

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.

Sunny Singh • Jun 8 '19 • Edited

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.

edA‑qa mort‑ora‑y • Jun 9 '19

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.

edA‑qa mort‑ora‑y • Jun 9 '19

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.

Sunny Singh • Jun 9 '19

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.

Elliot • Jun 8 '19

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 :)

Elliot Derhay • Jun 9 '19 • Edited

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.

Nihar Raote • Jun 12 '19

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.

Elliot • Jun 13 '19

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

Sammy Israwi • Jun 8 '19

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.

Michiel Hendriks • Jun 9 '19

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

Jeremy Forsythe • Jun 9 '19

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.

Sunny Singh • Jun 9 '19

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

Garrett / G66 • Jun 9 '19

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

Jason Huebel • Jun 9 '19

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.

Rob Porter • Jun 8 '19

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.

edA‑qa mort‑ora‑y • Jun 8 '19

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

Darren Vong • Jun 9 '19

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 🙄

kaleigh • Jun 9 '19

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.

Ross Henderson • Jun 10 '19

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

Ben Halpern • Jun 8 '19

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.

Stephen Belovarich • Jun 9 '19 • Edited

😮 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.

Lisa Armstrong • Jun 9 '19 • Edited

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

Judith • Jun 12 '19

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!

Elliot • Jun 8 '19 • Edited

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.

George • Jun 10 '19

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.

Chad Smith • Jun 8 '19

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.

Casey Brooks • Jun 8 '19

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.

Levi Velázquez • Jun 9 '19 • Edited

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.

David Wickes • Jun 9 '19

Sexism

Stephen Belovarich • Jun 9 '19 • Edited

☝️ 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.

Ben Halpern • Jun 9 '19

Absolutely.

scottshipp • Jun 9 '19

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”).

Henry Williams • Jun 9 '19

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.

Joshua Mervine • Jun 9 '19 • Edited

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.