What advice would you give to junior developers?

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?

Comments

[Ian]

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

[Arika O]

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 🥇]

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

[CristianCantilloDg]

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

[Ian]

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

[Oleg Aleksandrov]

1. Don't be ashamed to ask stupid questions.

2. Everyone makes mistakes, if you don’t make mistakes, it means you doing nothing.

3. 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]

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.

[JoelBonetR 🥇]

I think it's important to share experience to beginners for trying them for not doing the same mistakes than we did in the past, and to reinforce their knowledge (and so passion) about what they like more (or discovering new things that they like and passions). By the way, giving some advice and practical teaching at job or in posts makes people more secure and so more comfortable using a technology, which increases the motivation for keeping on and becoming better at it.

I usually add advice for beginners / juniors on all my posts for this reasons, you are free to check it out :)

[Arika O]

Thank you for sharing, I will definitely check it out. I agree that people should share knowledge and honestly, this is one of the things I like most about our field, people are always eager to help and share.

[Matthieu Cneude]

• 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]

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]

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.

[Justin]

As someone who actually just started my very first developer job 3 months ago here are the things that I tell myself when working:

1) Don't be afraid and ashamed to ask questions! Your team is there to help you, and some even appreciate you asking questions because it shows them you're putting an effort with learning the codebase/system

2) Ask your coworker how they would approach a problem or how they would start. This is actually something I do because it gives me insight on how they see it especially with the experience they have under their belt.

[Santosh Desani]

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]

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

[Santosh Desani]

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]

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

[Igor Formiga]

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]

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.

[Thomas Findlay]

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]

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]

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]

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

[Landon Young]

1. 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.
2. If you don't feel comfortable challenging the senior devs on your team, there is something unhealthy with the work culture.
3. Simple code is better than clever code. Readability and maintainability is better than performance (unless we're talking orders of magnitude difference).
4. It's okay to throw a project back to your manager/design if the acceptance criteria is unclear.
5. 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.
6. 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.
7. 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.
8. 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.
9. If you can master anything while starting a new language/framework/lib/etc, it should be debugging.
10. Never trust user input.
11. Run your code before you make a pull request.

[Arika O]

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.

[Bhumi]

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]

Thank you for your input.

[Edwin Klesman]

Protip 1: Don't just focus on coding. Coding is important as a developer - obviously - but getting inside people's heads and finding out what will bring them real value will be more important before you start coding a single line.

You can either choose to be someone who gets a pile of specs on their plate, and turns them into code
Or you become the person that figures out the best solution with the customer, help them define the problem and the solution and builds the best solution for them.

Protip 2: either code on something to learn, or code on something to build and ship it. If you choose the latter, choose a tech stack that you know (best) and build the best solution in order to ship it faster.

[Armando Cifuentes González]

• Never give up and believe in yourself
• Ask a lot of questions (it doesn't matter if these questions are silly)
• Don't be ashamed of your position and skills
• Get a mentor (if possible)
• Attend meetups about the stack or area where you want to grow
• Be a self-learner
• It's ok to get frustrated and cry, but the next time try the best of you
• Follow the rockstars/personalities of the IT area where you want to grow

[Arika O]

Thank you for your input, I am happy to see I'm already doing many of the things you mentioned.

[Muhammed Hilmi Koca]

I wrote an article about this topic :)

Here: medium.com/@mhkoca/pieces-of-advic...

[Pubudu Fernando]

1. Spend some time learning to use the IDE tools effectively. This means learning its shortcuts, debugger etc. This'll help in boosting productivity.

2. Have an understanding of the architecture of the project. This will help in understanding how it all connects and give you an idea of what to do and what not to do when working on your feature.

3. Learn to read code. Even the thought of going through a massive code base can be intimidating. But you need to dive in and figure out what the code does and how it behaves (at least for the parts relevant to you). The key would be to not fixate on every single line and just try to get an understanding of what it does (given that the code quality is good :P ).

4. Related to 2 and 3, setup and run the product. And then, use a debugger to trace through the execution and really see how it behaves and works.

5. Teach someone/answer questions (can even be on Stackoverflow or similar platforms). It can be a great way to really evaluate what you think you know. Sometimes when I try to answer someone's question, I realize I don't quite have a comprehensive grasp on that matter.

6. Blogging can be good too, for similar reasons as the above point and to create an online presence.

7. Read Clean Code. It's THE bible on writing quality code.

8. Related to the above point, try to keep it simple, without trying to be too clever. The code written is not just for the machine, other developers will be reading it too. If it is not easy to read, it'll result in a lot of dev hours wasted trying to decipher the code.

[Adnan]

Be objective about your code.

I have had occurrences of junior developers who would get very defensive about their code as if it were their child. If someone's criticizing your code (politely), thank them for their advice. Then, either look into it or ask them for more details. At the end, either you or them will be right (or both!) - with valid arguments instead of tension.