Things Junior Developers Do That Irritate Their Seniors
Senior developers are supposed to be patient with their juniors. If they lose their temper, it’s probably going to be for one of these reasons.
A few weeks ago I asked one of the software engineers I work with if he’d ever lost his temper with a junior developer. “Not over a coding issue,” he replied with a shrug. “When I work with people who are less experienced than I am, I’m expected to be patient and helpful when they make mistakes. There’s almost nothing junior developers do when coding that drives me mad.”
“Almost nothing?” I asked.
I noticed that he pressed his lips for a moment. “Almost.”
The proverbial spark was lit. I had to know: was there anything junior developers did that typically got on the wrong side of their seniors? Over the subsequent two weeks, I asked and read around, and while everyone (really everyone) agreed that it would not be proper to lose one’s temper with a junior over a mistake in their code, I did unearth a handful of recurring quibbles. These were the most common — if you’re a junior, you might want to look out for them!
#1. Assuming code is self-explanatory
The most frequently mentioned case of this consists in inexperienced developers not commenting their code, but really the core mistake is that of assuming that one’s seniors should, as seniors, automatically know what one’s code is doing and how. If a dev gives obscure names to their variables or doesn’t make it clear what sort of input and output they’re expecting, then their code will prove tough for anyone to read.
Write code like it has to be read by a stranger 10 years from now (after all, it probably will). Avoid minifying where possible, at least until you have a little more experience, name your variables and functions clearly, and keep your comments to the point and updated (make sure you delete them whenever you delete any code they refer to). In general, you want to render any mistake you make easier, rather than harder, for your seniors to spot.
#2. Not following established procedures
This one is a bit of a double-edged sword — speaking broadly, it’s fine to stray from the path most traveled. Oftentimes, it may even be beneficial. But it takes experience to know how to do that consistently without causing problems.
A company’s coding standards will be provided to a junior developer at the beginning of their work, and they will have some time to learn them. If two months later they’re still not being followed, fingers will start drumming on desks. All the more so if tools exist in your IDE precisely to standardise your coding style (and they usually do).
#3. Copying from the wrong places
Copying code is a normal part of programming, unless one perversely enjoys duplicating code that already exists or reinventing the wheel any number of times. The key is where you are copying from.
Reusing chunks of code from within your own project, perhaps altering only the name of a variable where necessary, is not just acceptable, it’s smart. Doing the same with code you found on Stack Overflow is passable, as long as you really understand said code — you can’t plug something into your projects if you’re not 100% sure you know what it does.
On the other hand, if you copy code from another product (or anywhere that has copyright) then that could have legal repercussions much more serious than an annoyed project lead. If you’re going to copy, watch your sources.
#4. Not asking for help
The irony of not asking for help, naturally, is that it is usually done by junior developers who are afraid of annoying their seniors. As I mentioned at the beginning of the article, however, senior developers will know that you need help. Moreover, they’ll expect you to ask.
If the work you’re doing is pretty simple, by all means keep at it by yourself. If you want to do something complicated or that you think is especially clever, ask first and make sure it’s compatible with the project. And if somebody else suggests you may need help, keep your pride on the leash — that’s not an insult, it’s an opportunity. Thank them and see what that help can do for you.
#5. …And the final one
This may seem incredible in the age we’re living in, but yes, it did come up among the things that irritate senior developers: code that is not indented! This is a really basic mistake, which every editor can correct for you, no matter what language you’re working in. It’s so basic, it falls squarely into the category of “almost nothing” that my colleague mentioned.
And if “avoid basic mistakes” sounds like advice too obvious to be said out loud, that’s because it is the only kind that an intelligent senior may be irritated to have to dole out. Remember: your seniors are here to help. The best way to make them happy, is to let them do just that.
