A man in a toque writes and reviews code on a laptop and display screen.

Dear Junior Web Developers: My Wisdom to You

Over the years of being a developer I’d like to think I’ve cultivated some healthy habits (and probably an equal amount of bad ones, but that’s for another article).

If I had a time machine I would love to visit my younger self and pass on this wisdom, but we all know that’s impossible. First, because I’m quite lazy and time-travel sounds like a lot of effort. And second, my younger self and I are not really on speaking terms. So since I can’t do that, I’d like to offer up my wisdom to junior devs (and maybe seniors, too), whom I don’t need to bend space-time to speak with.

Here’s the tl;dr version:

  • Always ask question as if you’re new. Then ask again.
  • Take a break after creating a Pull Request, then review your own code
  • Look at others’ Pull Requests, even if you’re not reviewing them
  • Look and ask about development patterns, conform!
  • Embrace your weaknesses and leverage that as your learning experience
  • Don’t question what the seniors say
  • Always question what the seniors say
  • Acknowledge you are a junior and be proud of it

That was the short of it, but if you’d like the long of it (i.e. having any context at all around each point), read on:

Always ask question as if you’re new. Then ask again.

I mention this regularly but I always feel like people — especially junior devs — hold back questions a lot. And even when they do ask, if they don’t quite understand they won’t ask again, because they fear it may make them look stupid. Truth is, there’s nothing more embarrassing than pretending to understand, executing on what you think you know, and then getting it completely wrong. Always clarify until you get it right: ask all the questions up front, ask questions along the way, then ask after you’re done if you have to. It’s better to be honest about your confusion and give people a chance to help you than to break something and have to come clean about your lack of understanding later.

Take a break after creating a Pull Request, then review your own code.

After creating a Pull Request I like to take a break, then review my PR. Tickets usually take a day to complete and after coding for a day you might have gotten lost in your own logic. It’s healthy to step back and rethink what you just wrote and evaluate if it actually makes sense. Logic that made sense when you wrote it may not make sense when you read it. At the very least, you’ll catch any debug code/comments that you forgot to take out. There’s nothing more annoying than reviewing a PR full of commented out code and console.log.

Look at others’ Pull Requests, even if you’re not reviewing them.

One of my weaknesses is I always want to know everything about the project I’m on. (Weakness because I lose sleep over this and I’m constantly in everybody’s face.) But in terms of the codebase, I find there’s no better way to understand and keep up to date with everything than to read all the PRs. Even if it’s the backend that I don’t have anything to do with, or just formatting changes — I still want to know! For junior devs this is the best way to pick up on others’ practice/techniques as well as understanding patterns (which I’ll be discussing next). The more you know about the overall code base, the easier it’ll make your job. You’ll reduce time writing redundant code or asking where certain components are, and gain greater overall understanding while you’re at it.

Look and ask about development patterns, conform!

I am surprised at how many devs don’t ask about development patterns. The easiest thing to do is ask! Some don’t even look out for them, but we all should do this. And on occasions where there’s not enough context to figure it out, just look through some of the code (or PRs) to gauge where there are patterns and where there aren’t. Of course, there could be linters and config files to help teams conform, but there could also be things that are hard to catch such as file structuring, naming, or when something should be two components or one. Figure out what these patterns are, and if it’s not the “wrong” patterns… conform.

(A related side-plug to some other articles I’ve written on standards and patterns: alphabetize your css properties and use space over tabs.)

Embrace your weaknesses and leverage that as your learning experience.

As a fresh computing science or engineering grad, junior devs often think they have the basics down pat, but I can guarantee 90% of them don’t. The basics I’m referring to are HTML and CSS. Whenever I conduct an interview with a junior dev, they always rate themselves between 7~9 (out of 10) for CSS, but most of them land closer to a 5. There are two reasons for this:

  1. They think HTML and CSS are easy, and with this understanding they believe they have skills sufficient to do all HTML and CSS tasks.
  2. They assume a higher number could help them land the job.

For me neither of those are true, especially number 2. When I do my CSS test I look for candidates who evaluate close to the rating they gave themselves. I look for devs who have self-awareness of their own strengths and weakness so they know where to spend effort on personal development because that way, when they join the team there are no surprises. I’m using HTML and CSS as my example here, but I think this self-awareness applies to all soft and hard skills. Acknowledge your weaknesses, let teams know of them and how you’re actively trying to strengthen these skills. In turn, your team may be able to accommodate or assist you.

Don’t question what the seniors say.

There’s a reason why they’re seniors (they old!)(jk). I don’t want to upsell the senior role, but usually senior devs have a bit more experience in the field (or at least within the company). If there’s a problem, and you’ve discussed the solutions and possible outcomes of each, and the senior dev recommends doing it a certain way because of x, y, and z, then that’s probably the way to go. I’m not saying blindly follow what the seniors say or don’t ask why we should do it a certain way. I’m saying if there have been discussions and considerations, then there’s no point turning a problem-solving discussion into a stubborn debate. The senior dev probably has insight and experience on how these situations may play out in the bigger picture.

Always question what the seniors say.

This is not countering the last point, but building off of it. I always encourage questions and discussions. I believe it’s healthy to always be re-evaluating the way we do things, or even just understanding if x, y, and z are really fixed (or that important to begin with). Fresh perspective is invaluable to teams of seasoned developers, who can end up with tunnel vision in certain circumstances. If you work in an environment where senior people are not even open to discussion, then that’s a sign you need to move on.

Acknowledge you are a junior and be proud of it.

This goes back to my first point about asking questions. I find a lot of junior devs are afraid of being judged and thus, try to refrain from most of the habits I’ve listed above. But I think the healthiest, most productive mindset has to be quite the opposite. The advantage of being a junior dev is that others’ recognize it already — they’re not expecting you to solve everything without any problems! You just have to acknowledge it yourself: this is where you are right now. You should be proud of that fact. I envy this. When you’re a “senior”, people have certain expectations of you and it’s hard to wear the “junior” hat and ask “silly” questions such as, “what is const?” (bad example, but you get the idea). It took me a long time to let go of my ego and operate with more of a junior mindset, and it has never been more rewarding. I learn so much more, and I can better appreciate how much my teammates know, too.

If you found this valuable, give it a 👏 and send it along to some of the junior devs you know! There’s some overlap, but if you’d like more guidance on your journey to awesomeness, check out my contribution in The Murky Path to Growth article. And of course, if you’ve got suggestions of your own, add them in the comments below.