A few weeks ago I asked one of the software engineers I work with if he\u2019d ever lost his temper with a junior developer. \u201cNot over a coding issue,\u201d he replied with a shrug. \u201cWhen I work with people who are less experienced than I am, I\u2019m expected to be patient and helpful when they make mistakes. There\u2019s almost nothing junior developers do when coding that drives me mad.\u201d<\/p>\n\n\n\n
\u201cAlmost<\/em> nothing?\u201d I asked.<\/p>\n\n\n\n I noticed that he pressed his lips for a moment. \u201cAlmost.\u201d<\/p>\n\n\n\n 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\u2019s temper with a junior over a mistake in their code, I did unearth a handful of recurring quibbles. These were the most common \u2013 if you\u2019re a junior, you might want to look out for them!<\/p>\n\n\n\n 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\u2019s seniors should, as seniors, automatically know what one\u2019s code is doing and how. If a dev gives obscure names to their variables or doesn\u2019t make it clear what sort of input and output they\u2019re expecting, then their code will prove tough for anyone to read.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n This one is a bit of a double-edged sword \u2013 speaking broadly, it\u2019s 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.<\/p>\n\n\n\n A company\u2019s 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\u2019re 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).<\/p>\n\n\n\n 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<\/em> you are copying from.<\/p>\n\n\n\n Reusing chunks of code from within your own project, perhaps altering only the name of a variable where necessary, is not just acceptable, it\u2019s smart. Doing the same with code you found on Stack Overflow is passable, as long as you really<\/em> understand said code \u2013 you can\u2019t plug something into your projects if you\u2019re not 100% sure you know what it does.<\/p>\n\n\n\n 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\u2019re going to copy, watch your sources.<\/p>\n\n\n\n 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\u2019ll expect you to ask.<\/p>\n\n\n\n If the work you\u2019re 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\u2019s compatible with the project. And if somebody else suggests you may need help, keep your pride on the leash \u2013 that\u2019s not an insult, it\u2019s an opportunity. Thank them and see what that help can do for you.<\/p>\n\n\n\n This may seem incredible in the age we\u2019re 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\u2019re working in. It\u2019s so basic, it falls squarely into the category of \u201calmost nothing\u201d that my colleague mentioned.<\/p>\n\n\n\n And if \u201cavoid basic mistakes\u201d sounds like advice too obvious to be said out loud, that\u2019s 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.<\/p>\n","protected":false},"excerpt":{"rendered":" Senior developers are supposed to be patient with their juniors. If they lose their temper, it\u2019s probably going to be for one of these reasons.<\/p>\n","protected":false},"author":17,"featured_media":8685,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"content-type":"","footnotes":""},"categories":[42],"tags":[],"class_list":["post-8686","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-coding"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.wbscodingschool.com\/de\/wp-json\/wp\/v2\/posts\/8686","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.wbscodingschool.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.wbscodingschool.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.wbscodingschool.com\/de\/wp-json\/wp\/v2\/users\/17"}],"replies":[{"embeddable":true,"href":"https:\/\/www.wbscodingschool.com\/de\/wp-json\/wp\/v2\/comments?post=8686"}],"version-history":[{"count":1,"href":"https:\/\/www.wbscodingschool.com\/de\/wp-json\/wp\/v2\/posts\/8686\/revisions"}],"predecessor-version":[{"id":62626,"href":"https:\/\/www.wbscodingschool.com\/de\/wp-json\/wp\/v2\/posts\/8686\/revisions\/62626"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.wbscodingschool.com\/de\/wp-json\/wp\/v2\/media\/8685"}],"wp:attachment":[{"href":"https:\/\/www.wbscodingschool.com\/de\/wp-json\/wp\/v2\/media?parent=8686"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.wbscodingschool.com\/de\/wp-json\/wp\/v2\/categories?post=8686"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.wbscodingschool.com\/de\/wp-json\/wp\/v2\/tags?post=8686"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}#1. Assuming code is self-explanatory<\/h2>\n\n\n\n
#2. Not following established procedures<\/h2>\n\n\n\n
#3. Copying from the wrong places<\/h2>\n\n\n\n
#4. Not asking for help<\/h2>\n\n\n\n
#5. \u2026And the final one<\/h2>\n\n\n\n