Landing a job as a Junior Front-End developer

Hello earthlings!
A few days ago I conducted a workshop in which I presented a set of advice learnt from experiences that have happened to me during the past 6 months in my internship as Front-End developer.
After some people asked me about the recording and because I’m not super confident with the outcome, I decided to convert it into an article.

But first of all, let me say I would be very thankful if you could take a couple of minutes to give me your feedback 🤓 I mean I would be very interested in knowing if those things ever happened to you as a junior or if as a senior developer you appreciate juniors having this kind of concerns.

Moreover, and especially if you are a junior developer reading this I would like to make sure you don’t believe my words too much. I would encourage you to question all opinionated beliefs and make your own opinion around them. There’s no right or wrong, it’s just an opinion.

So that being said, let me introduce my checklist:

1. Fake it till you make it != Be humble, most likely you’re surrounded by better developers than you are.
   I might be crazy but I’ve bumped into very polarised junior developers. Some of us suffer from a remediless impostor syndrome whereas some others tend to overestimate their abilities.
   I’d say I better fit in the first group.
   But the point here is none of those is going to help you better committing your tasks in a comfortable way… So if same as me you’re part of this (impostor-syndrome like) first group: Fake it till you make it.
   Do yourself a favor and check this TEDTalk out. It helped me a lot especially in the beginning and it still does 🥰.
   However, if while being a junior developer you tend to think there’s not much else you can learn from anyone… Always be humble, there are always better solutions than your own and stuff to be learnt out there.
   In my opinion, other developers and people in general are the best source of knowledge you can find! Community is a precious treasure!
2. Don’t be afraid to ask <>Identify all those things you’re not gonna be able to find on the internet.
   Asking is fundamental but try to make the right questions.
   Is it something I can find on the internet? Search it then.
   It didn’t take long for me to realise I was missing a great deal of knowledge about the architecture until I started making the right questions.
   Is this method something related to the framework/library they are using (Google-able) or is it an own helper /method they use repeatedly (non-Google-able)? The import is most likely going to help you answer this question… where does this resource come from? Does it come from an own repo or is it React’s, Vue’s or whatever other public framework/library’s import?
3. Is there something looking like black magic to you? You might be losing some piece of information and you better ask for it! Unless you find the answer on the internet first, of course.
   The only exception I would be always ensuring with someone in the team first (when in doubt) is anything related to GIT. If you are not certain about something and you haven’t been able to find the answer on the internet… you better ask for it. I mean GIT is kind of delicate.
4. Try to leave code better than you found it
   There’s not much to say… you’re not going to be hired for committing with the task’s descriptions only but also to keep code consistency, ensure scalability, prevent repetition… In order to stick to those principles, you’ll most probably have to perform refactors or change code that is not always going to be perceived by the final user. This is in my checklist because I tend to think that “if such code has been developed by seniors and revised in a pull request, it must be they want it this way” or “don’t change code developed by people who know better than you” whereas sometimes I found out my reviewer in the pull request asked for the same refactor I was thinking about… 😩
5. Be responsible for your own code
   One day I asked for help from someone in the team and this person asked me why did I do something in a particular way.
   My answer was: “Carlos helped me through it”
   His answer: “Does that mean I should blame him if it’s wrong?”
   WOW! This response switched something in my mind… And from that precise moment, I think it’s important to be responsible for one's code… If someone corrects it, understand the correction and if you think it was better before, say it out loud. This means if you decided to aggregate someone else’s code, it means you understand and agree with that piece of code and therefore you accept the responsibility towards it!
6. Don’t settle
   And by that I mean… whenever your developments are not a challenge anymore, you better find new interesting stuff to do. And I don’t mean a new job but maybe new responsibilities! The universe is full of technologies and things to learn… I found out I don’t fit in the description of being that kind of developer who’ll be programming the same language for the whole life. And given the pace in which technology is progressing, I don’t think any developer should do that. So try to always be keen on learning new tools, frameworks and languages even though your work ecosystem remains the same for ages!
7. Judge, never impose and bring forward.
   I mean, what reason may companies have for hiring junior developers? Junior developers are in general not tainted by how things are meant to be done and tend to have (sometimes) crazy/pure/fresh ideas on how to do certain things. Even though we tend to be wrong, we surely provide the team with creativity and ideas. We are good at helping the team improve processes such as onboarding plans or documentation giving a non-tainted point of view ✌️ So try to highlight your strengths and improve your weaknesses little by little!
8. Trust your instinct when you smell 💩
   Yes, legacy code does exist and refactors can be required from time to time! Don’t think you’re always wrong… your point may be right and if your instinct is shouting at you: “This can by dried” ,“There’s too much code repetition here”, “This is too coupled” ¡Hey! guess what, you may be right! Your team and the way in which the company works regarding this fact, will be crucial at this point… Is there time enough for refactors? Will the change be valuable for final user? It may depend on the case… but trust your instinct and ask!
9. Never point. Don’t blame. Find a team that shares both victory and defeat.
   What can I add here? treat others same way you would like to be treated and do your best to build a healthy working environment!
10. Chesterton’s fence principle.
    ‘Chesterton’s fence is the principle that reforms should not be made until the reasoning behind the existing state of affairs is understood.’
    Imagine we find a fence in the middle of nowhere. You may wonder… it has no sense, it’s useless, it has no point… Well, this principle stands that you should not remove the fence until you find out the reason for it to be there. And this can easily be applied to code… You find some weird code, you don’t understand the reason for it, it has no point, it’s useless… Well, you better don’t remove it until you know why was it there.
11. Test your skills when possible. Get out of your comfort zone but not too much.
    New dev in the team? Hey! Nice opportunity to test your knowledge by answering to their questions and most likely learn something new on the way. All in all, if you are not able to explain something, chances are you don’t understand it 100%.

All in all, find your voice in the team and grow little by little 🥰 Lucky me, I’m surrounded by amazing developers who understand all this and do their best to help and I couldn’t be happier 🌺

HAPPY CODING!💻

www.cristinamoreno.dev