Arika O

Posted on Apr 23, 2020 • Edited on Jan 13, 2021

What advice would you give to junior developers?

#frontend #junior #beginners #senior

Seniors or not-so-junior developers, what advice would you give to people just starting working as junior devs? The advice could be anything really. I'm still very new in this role (this month would be my fifth, after switching fields from product management) so I don't think I'm qualified to give advice (or maybe I'm wrong?), but I would really like to hear from people with more experience. What would you want beginners to know when starting out?

Oldest comments (38)

Ian • Apr 23 '20

Break. The. Project. Down.

Seriously though, do it, and learn how to. It's all too often you get a ticket or a project for someone which has 10,000 requirements (Ok a little exaggeration) and it may seem like a huge task up front and can cause excess stress. But breaking it down piece by piece, suddenly things become much simpler and easy to manage.

Albeit not directly developer advice but being able to look at a project and be able to break it down, but hey, being a developer is more than just programming :)

CristianCantilloDg • Apr 23 '20

Totally agree. This is a very important skill Im trying to masterize.

Ian • Apr 23 '20

Sort of on topic I guess. But also teach them that yeh. Being a developer isn't just developing :). Writing documentation, specs, debugging etc. Lots to programming other than code :)

Arika O • Apr 24 '20

Very good point actually. I'm still in shock when I see experienced developers writing code on the fly like they know where they want to get and how they want to do it, but not having an actual written plan anywhere. I guess this skill comes with years and years of experience. I'm at the point where I makes schemas on pieces of paper, even for simple tasks :). Thank you for the advice.

JoelBonetR 🥇 • Jul 1 '20

I find your comment kinda funny Silvia :)

You really will learn to write code on the fly (which is a very bad practice TBH) when you start doing it.
You can get a portfolio and editing code directly on production from the hosting IDE or using vim (or whatever) through SSH, but there's no much adrenaline here.

Then you can edit the .htaccess or add a return true (or false) at the beginning of a method (for blocking this path, for example on a method that calculate some specific discounts, when you want to finish this promotion and marketing department tell you to do that quick because they didn't planned it properly), or for fixing a blocking bug. All of it on a web app that earn 10M a year and then the adrenaline appears (and your know-how to open the views where your changes will take effect on a secondary screen before saving changes and make a quick test to ensure you didn't broke it).

My best advice here is:

I'm conscious that supposedly we must never edit code on the fly or in production directly, but sometimes it's needed for a quick fix (it's instant while a deploy could take 10-15min at least). When you are in this situation ALWAYS add exactly the same changes on your develop branch, as the next time you make a merge from develop into master for a new feature, you will not face a manual merge).

Igor Formiga • Apr 24 '20 • Edited

1) Search for help.
Sometimes you're going to be stuck in a problem. That's ok. It's easy to lose sight when you're looking for so long to a problem. By searching for help you're opening up to learn more quickly and get things done faster. It's almost like taking a shortcut.

2) Ask for feedback and mentorship.
This is what is most important when you're starting, know your blindspots. Ask for code reviews, mentorship this will make you a better developer every single day.

3) Take Ownership of your journey.
You have to own your journey. Own your career. Don't expect people to show up to help you, go for it.

Arika O • Apr 24 '20

I believe having a mentor is something that can make or break a junior developer. Guidance is always necessary, no matter how good of a programmer you are - it's like having a talent but not knowing how to use it, so a mentor is there to show you the way. Thank you for your nice words.

Oleg Aleksandrov • Apr 24 '20 • Edited

Don't be ashamed to ask stupid questions.
Everyone makes mistakes, if you don’t make mistakes, it means you doing nothing.
If something went wrong, 99,9% a problem exists on your code, but if it’s is 0,01%, and an information about that issue is not exists, it’s normal to write a bug report.

Arika O • Apr 24 '20

Valuable advice and I like the 3rd point in particular. Being that person who finds a bug and ignores it just because it's not related to their ticket is never the way to go. Thank you.

Santosh Desani • Apr 24 '20

On top of some of the things that have already been mentioned by other folks, I would add this,

Don't take automation for granted. Always learn/know things running a layer deep.

I have encountered people who just push code to master and do not track/verify whether it actually got deployed to dev. If anything breaks in deployment, they literally don't know what to do next or how to fix it. This not only takes time of other person who now has to troubleshoot, that too only after someone realizes that the code is not getting deployed, but also when you are not tracking, it can create confusion for anyone who is testing that functionality.

Arika O • Apr 24 '20

Do you mean, in this case, try to understand the tools you are using? Thx for the advice, much appreciated.

Santosh Desani • Apr 24 '20 • Edited

Yup to most extend. As an example, if you have a Spinnaker pipeline which deploys the artifact, if everyone understood what different stages that pipeline has and what each phase does (what script/lib it uses), it would reduce time and effort in testing/troubleshooting/fixing. Not necessarily understand the script/lib itself code wise but atleast knowing/understanding what it does can help.

This thought can also be expanded to other areas as well. If you consume something internally, testing/troubleshooting becomes easy if we understand what that service/server, that we consume, is doing and what are some of its dev/deployement workflows.

Arika O • Apr 25 '20

On a different note, I especially agree with this one when it comes to learning frameworks but not having any clue about how the language actually works :).

Matthieu Cneude • Apr 24 '20

Ask questions. If you don't understand everything of the answer, that's fine; write it somewhere and look it up. If you still don't understand it, that's fine too. It will come.
Be patient. There is a lot to learn, and you can't learn everything at once.
Don't try to learn everything at once. If you have a very partial knowledge of git, that's fine. Same for everything else. You can go deeper later.
Make your code work, that's the most important. Try to write automated test, that\s the second most important.
Languages, algorithm and whatnot are not important, for now. You are a problem solver. That's why you need to break down the problem before coding. Not the other way around.
If you don't get how to break down the problem, that's fine. Analysis paralysis is not good either; begin to code, and see what happens.
Keep in mind that EVERY principle are no silver bullets. They have their drawbacks; don't use them if you're not sure if you understand them. Same for design patters.
Everything depends on the context you're in, i.e. the business problem you're trying to solve. Use your brain, more than anything else. Don't follow blindly anybody / anything and keep a sharp critic mind.
Keep your code simple: no code which is never executed (dead code), don't code functionalities which will maybe come up in the future.

Arika O • Apr 25 '20

I really like your advice. I'm still guilty of some of the things you mentioned (especially point 3) but I hope the day when the learning journey will come a bit easier is not that far. Thx for the nice words.

Matthieu Cneude • Apr 26 '20

You're welcome!

I know it's easy to say, but guilt won't bring you anything good. Don't compare yourself to others, it's flawed. Somebody will always be better than you, or worse. Plus, it's very difficult to have a realistic judgment on your knowledge/skills, on the others skills, and even more difficult to compare both.

Compare yourself to your past self. See if you improved. It will take time, so be patient. Meanwhile, enjoy the journey! Whatever happens, you'll always learn something new.

Thomas Findlay • Apr 24 '20

Use a lot of console logs. Google stuff a lot. Read documentation before you start using a library. If you are really stuck, and can't find out how to fix an issue then ask for help on stack overflow, etc. Sometimes you might need to re-word your google search query, but most of the time searching by keywords is enough.

Arika O • Apr 25 '20 • Edited

Oh yes, still use the old console.log()s and always forgetting to remove them when submitting code for reviews :). Stackoverflow is my next best friend, after my dog. Thank you for the input.

Thomas Findlay • Apr 25 '20

You might want to add pre-commit hook which will run eslint. If you have any console.logs it would prevent you from committing your code before console logs are removed.

Arika O • Apr 25 '20

Didn't know that's even a thing. Thx for the tip!

Bhumi • Apr 24 '20

Hi Silvia - one thought that jumps out at me is this - I recommend that you not explicitly label yourself as 'junior' in your public profiles. So 'Junior front-end developer' --> 'front-end developer'. Here's why dev.to/bhumi/don-t-label-yourself-... hope that makes sense! :)

Arika O • Apr 25 '20

Thank you for your input.

Landon Young • Apr 24 '20

Ask lots of questions, but also get used to doing research. Your ability to use a search engine and sift through results is one of the things you'll see grow the most early in your career.
If you don't feel comfortable challenging the senior devs on your team, there is something unhealthy with the work culture.
Simple code is better than clever code. Readability and maintainability is better than performance (unless we're talking orders of magnitude difference).
It's okay to throw a project back to your manager/design if the acceptance criteria is unclear.
If you're using an open-source language/framework, don't be afraid to jump into the source code. It'll make you better at your base language/platform.
If you make a mistake, take ownership but don't beat yourself up excessively. Never take credit for somebody else's work. If you see somebody on your team doing something good, call it out.
You'll never know everything, but you'll eventually have enough expertise to completely dismiss some approaches and/or say, "I've kinda done something similar before" to most common tasks in your domain.
It's okay not to be 'in love' with software development, but do your best to find yourself doing the things you 'like' about it in a daily capacity.
If you can master anything while starting a new language/framework/lib/etc, it should be debugging.
Never trust user input.
Run your code before you make a pull request.

Arika O • Apr 25 '20

Thank you for point 8, it's refreshing to read it. Sometimes I feel like I don't want to be a software developer and I guess that's ok. It's a difficult relationship. Overall, great advice, especially point 11.