by: Alyn Parry and Ryan Ernst
Welcome to the first post in the IQ Ask an Architect Series! In this series of posts, I will be collaborating with one or more of our Systems Architects to pick their brains on various topics.
This week I jumped on a Google Meet to talk with Alyn Parry, an IQ Systems Architect. Alyn has over 15 years of development experience and works mainly in C#, but is also versed in C++. We discussed the top five mistakes Alyn sees junior developers make and how to avoid them.
Not Asking Enough Questions
Have you ever spent several hours trying to solve a bug, only to mention what you were battling in standup, and your lead quickly rattles off the fix? I think we have all been there at some point in time. As a junior developer, it is easy to fall into this trap; you want to prove yourself and don’t want to be seen as needing too much help. According to Alyn, you should “… try to solve the problem on your own, but if you find yourself stuck for more than an hour, it is probably time to ask for help.”
Asking Too Many Questions
On the other hand, if you find yourself asking your dev lead questions several times every hour, you might have the opposite problem. All (good) architects and senior engineers understand that they need to mentor their team, but they also have their own obligations to meet in the sprint. If you are constantly preventing them from focusing on their work, you might find that they stop responding in a timely fashion.
To avoid this issue, Alyn says: “If you are going to ask me to take a look at something, at least be ready to explain what you think the problem is, what you have read online, and what you have tried. You shouldn’t be bringing me problems that you haven’t even tried to solve on your own yet.”
Trying to Reinvent the Wheel
This particular issue comes in two flavors, according to Alyn: Internal and External. Internal when you add new functionality to an existing codebase when that functionality already exists in a different class or area of the code. External when you try to write an implementation of functionality that already exists in proven libraries.
According to Alyn, spending a bit of time researching existing implementations, whether internal or external, is always worth the time and effort.
Getting Fixated on One Technology
Alyn mentioned that he often sees junior developers easily get fixated on one technology. Sometimes when an engineer develops competency and comfort in a specific technology, they try to use that for every project, even if it is not the best tool for the job.
Alyn said: “I see this happen with LINQ sometimes — people will realize they have a LINQ hammer that can solve all problems, and when you have a LINQ hammer, everything looks like a nail.” This mistake applies to programming languages as well; just because you know one language well, you shouldn’t try to force it onto a problem where it’s not a great fit.
Understanding Changes in Different Levels or Areas of the System
This one is my favorite; Alyn told me: “Junior engineers need to understand the relative impact that changes have in different parts of the system.” I didn’t follow right away — but then he expanded: “For example, adding a hack in UI code that nothing depends on is not the end of the world. Adding a hack deep in core-code that everything depends on is not OK.” This knowledge comes from experience in a given system and understanding the system you are working within. If you are ever uncertain how important something is, talk to the more experienced team members who should have a broad understanding of the different areas in the codebase.
If you have any additional questions for Alyn or would like to suggest topics you would like us to cover in future Ask Architect posts, let us know by sending an email to tech@iq-inc.com!