I really liked @abbeyperini post and decided to share my tips after 5+ years as a software dev.
Ready? Let's dive in πͺ.
1. Master the fundamentals
A house π built on shaky grounds will fall apart at the smallest issue.
Similarly, if you don't have strong basics:
- You will struggle with JavaScript frameworks
- You will get stuck at the first unfamiliar problem
- You won't grasp the common themes between some problems
So, if you want to improve as a frontend developer, master HTML, CSS, and JavaScript first.
2. Understand how the web works
Frontend development has become more complex in the past few years.
Numerous tools are used (bundlers, transpilers, etc.)
If you don't understand how the web works (i.e., the "only" languages supported are HTML (for structure), CSS (for styling), and JavaScript (for interactivity)), you'll struggle to understand why there's a need for so many tools to run your code online.
3. Get familiar with Data Structures & Algorithms
Data Structures & Algorithms often get a bad rap due to coding interviews π€¦ββοΈ.
Yet, it's crucial to understand the key ones and their complexities. Without this knowledge, you won't be able to code complex programs or evaluate your code efficiency.
Below is a non-exhaustive list of Data Structures/Algorithms to know :
Data Structures: Stack, Queue, Hashmap, Set, Graph, etc.
Algorithms: Dynamic programming, Greedy algorithm, Recursion, etc.
4. Learn by doing rather than reading/watching
Tutorials trick you into feeling like you're making progress.
They make you believe you're learning and improving, but you're not moving forward. Real learning happens through practice or teaching.
So, practice a lot and avoid getting stuck in tutorial hell π₯.
5. Ask for help when stuck
You're not alone.
Chances are, you have senior developers nearby whom you can ask for help.
So, don't waste time going down rabbit holes. Your goal is to provide value, and you're not achieving that if you're wasting time tackling issues others have already addressed.
6. Ask for help the proper way
Before asking for help, make sure you have done the bare minimum.
You should first:
- Search on Google/Stack Overflow/ChatGPT for solutions
- Understand your goal and what's not working
- Keep a record of all your failed attempts
Also, don't repeatedly ask for help for the same issue. When you get help, note it somewhere so you don't forget it π.
7. Don't copy/paste code you don't understand
This is seriously bad for various reasons:
- You might end up with insecure code that exposes sensitive information like tokens.
- You won't be able to debug the code easily.
- You won't be able to explain it to your colleagues.
This is particularly concerning with ChatGPT, as it sometimes provides only 80% accurate answers.
8. Don't blindly apply every piece of advice found online
I made this mistake when I just started.
I came across advice saying memoization in React was evil, so I stopped using it.
To my embarrassment, my code crashed in pre-production π .
So, don't be "old" me.
When you see advice online, ask yourself the following questions first:
- Does this advice apply to me?
- Is the person advising in a similar context to mine?
TLDR: Exercise common sense π« .
9. Assume good intent: people want you to succeed β€οΈ
When you're new, it's common to think people are waiting to catch your mistakes and fire you.
At least, that was what my mind was whispering to me.
But it's the opposite.
When a company hires you, it wants you to succeed badly. Otherwise, it's a waste of the time and resources they invested in training and onboarding you.
So, trust that your company wants you to do well, and don't hesitate to lean on your colleagues for support.
10. Done is better than perfect
The pursuit of perfection often results in the following:
- procrastination
- waste of time
- overcomplexity
- etc.
So, aim to ship/validate a V0 before pushing for more.
11. Always break tasks into manageable ones
Easiest way to feel overwhelmed?
π Trying to bite more than you can chew.
Always break projects into smaller tasks.
This will:
- Keep you from feeling overwhelmed
- Make your PRs (pull requests) easier to review
- Provide a sense of progress
12. Be trusted to reach out when you need help
When starting out, your top priority is earning your manager's trust.
They should have peace of mind when thinking about you.
They should believe that:
- You're reliable with simple tasks
- You'll seek help when necessary
- You'll communicate any problems
You don't want to add to your manager's workload by becoming a problem they must constantly monitor π.
13. Show enthusiasm for the work
You can make up for a lot of shortcomings with enthusiasm π€ͺ.
When you're new, be eager and excited.
Only experienced devs can afford to lack enthusiasm.
No one wants to constantly push someone to work. Mentoring is tough enough already; having to motivate someone makes it more challenging.
14. Stay open to learning new things/tools/methods
Frontend development is constantly evolving.
So, you need to be open to jumping to new technologies.
Don't cling too tightly to your current tools. Instead, show an appetite for learning π.
15. Master your dev tools π οΈ
Want to speed up your development time?
Master your dev tools:
- Your IDE (e.g., VSCode)
- Your source control system (e.g., Github)
- Your browser and the inspector (e.g., Chrome inspector)
- Etc.
16. Focus on delivering value
Don't write code in a vacuum.
Every code you write should provide value to:
- Your customers
- Your company
- Your stakeholders
- Etc.
Your compensation is tied to the value you provide, not the code you write.
So, prioritize writing effective code that serves a purpose π₯ .
17. Advocate for your work: it won't speak for itself
Probably one of the most common mistakes for new devs (especially if you come from a culture valuing modesty).
You've done something remarkable.
No one knows about it.
π That work won't matter.
So, share your work through writing, demos, etc.
18. Prefer writing dumb code over clever code
Code is read much more often than it is written π.
So, refrain from writing clever code that only you can understand.
Readability > Performance > Cleverness.
You want your colleagues to work with your code efficiently, assist you if necessary, etc.
19. Your manager is your best ally
Unless you're exceptionally unlucky, your manager is there to support your growth π.
They typically want you to thrive, contribute to the team, and remain with the company instead of seeking opportunities elsewhere.
So, make sure to enlist them to reach your goals.
Share your wins, setbacks (in a positive light), and frustrations instead of struggling alone.
20. Make your manager's life easier
This one's easy but often overlooked.
Your manager likely has issues you can assist with:
- They might need to add documentation but lack time
- Their workload could be overwhelming, and they need support
- And more
This is probably the simplest way to earn your manager's support (for promotions, raises, etc.). They're already aware of the tasks and can directly see their impact (at least for them).
21. Understand the big picture behind your tasks
Don't be a code monkey π.
It might serve you well when starting.
But to reach the next level, you need to understand the context behind your tasks:
- Why they are valuable
- Why you were assigned to them
- How they fit in the company's overall strategy
This understanding is essential for advancing to the next level of your career.
22. Contribute to the team (documentation, tech talk, demos, etc.)
This benefits not just the company but also you.
By conducting demos, sharing documentation, etc., you showcase your skills and enhance the team's productivity.
Always aim to uplift your team's performance as much as possible: it's enjoyable and rewarding π.
23. Become the "go-to-person" in a specific area
If I had to offer just one tip, it would be this.
At the beginning of your career, exploring various areas is okay.
However, to advance to mid/senior levels, focus on building expertise in one area. This is more compelling for promotions than being average in multiple areas.
So aim for T-shaped skills: broad knowledge with deep expertise in one area.
24. Develop your communication skills
Unfortunately, this is a must π.
Communication is vital for developers. We often have to do the following:
- RFCs (Request for Comments)
- Demos
- Presentations
- Etc.
So, make sure you have a basic level of proficiency in communication.
25. Take breaks when you're stuck on a problem
It's tough to pause when you're deep into a problem.
Even after 5+ years, I struggle with it π₯Ή.
Yet, I consistently generate fresher ideas after taking a break.
So, step away if you've been stuck for too long.
26. Work from your strengths, not your weaknesses
Stop wasting time trying to fix apparent weaknesses.
If it takes you consistently >1 hour to do a task that others at your level accomplish in <5 minutes, steer clear of that task.
Likely, investing more energy won't make you exceptional at it.
Instead, do the essentials and concentrate on maximizing your strengths. If something comes naturally to you and is valuable, do it more π.
27. Take ownership of your career path
No one will plan your career for you.
And without a plan, you'll be working for someone else's plans.
So make sure you create a plan for what you want to achieve in 1/2/5 years πͺ.
28. Hang with other devs
Are you currently experiencing impostor syndrome?
If so, spend time with other developers.
You'll quickly realize you're not alone.
Connecting with other devs has additional benefits:
- You can pick up new tricks/tips
- You can discuss shared experiences
- You can complement each other's work
- Etc.
29. Mentor younger devs
This is one of the top cures for impostor syndrome.
Once you begin mentoring younger devs:
- You'll realize you know things
- You'll establish yourself as a mid/senior dev
- Etc.
30. Diversify the problems you solve
If you're constantly tackling the same issues, your progress will plateau.
Ensure you're solving diverse problems so you can:
- Compare various approaches
- Develop a toolkit for problem-solving
- Etc.
31. Find mentors
Having great mentors has been the highlight of my career π₯°.
- Mentors keep you grounded as they understand your journey.
- They guide you to avoid the mistakes they've made.
- Etc.
How to find a mentor?
Connect with a more experienced developer you interact with, ask questions, discuss their experiences, etc.
If you don't have access to a senior dev, engage with individuals on platforms like X, build a relationship with them, and then reach out π.
32. Commit to a JavaScript framework & master it
The best framework is the one that helps you achieve your goals the fastest.
So, ignore pointless debates online.
Choose the framework you're most comfortable with or need to learn.
And master it. That's sufficient.
With solid JavaScript fundamentals, transitioning to another framework will be quick.
33. Constantly think of the user experience
As a frontend developer, you should think about the user.
Even if you have PMs or designers, ensure the user experience is nice π.
- Use loading states when needed
- Communicate progress in the UI
- Give feedback to the user
- Etc.
34. Be comfortable saying no
This is a tough one for me.
I get excited about every project and struggle to decline.
But as a developer, you'll often have more requests than you can manage.
So, prioritize the ones that align best with your goals π₯ .
35. Continuously invest in your skills
By choosing to become a frontend developer, you committed to a career in which you must continuously learn.
Therefore, keep investing in your skills by acquiring new languages, mastering new techniques, etc.
36. When faced with too much work, reduce the features vs. the quality of the code.
The more features your app has, the better, right? Right?
Initially, this might seem true, but additional features lead to more code. And more code means more issues (maintenance, bugs, etc.).
So, when pressed with time, trim features over sacrificing code quality.
37. Strive to understand your collaborators (designers, Backend developers, etc.)
Always show respect to your collaborators (backend devs, designers, PMs, etc.).
App development is a team effort.
The more synergy among team members, the happier and more effective the environment will be π₯°.
Thank you for reading this post π.
Leave a comment π© to share a tip.
And don't forget to drop a "ππ¦π₯".
If you like articles like this, join my FREE newsletter, FrontendJoy.
If you want daily tips, find me on X/Twitter.
Top comments (206)
thank you very much for this
Glad you like them!
you're welcome
i'm actually a young dev so i've been wondering how'll i get to know all of this
It definitely comes from experience (sometimes painful one π )
Thanks a lot for this piece, it's so timely! I am just starting out. Delving into JS, I am comfortable with HTML and CSS. JS ain't easy, but my goal is to learn and master it before adding frameworks. The truth is that, the learning journey is a never-ending process. I sure will take these tips to heart.
Hi Godwin. I'm a fairly new dev too. I found learning JS challenging, but my big breakthrough was when I read a book called "You don't know JS yet." It's an involved read, but, if your like me, after studying the first three chapters, you should be able to write basic JS. You can download a free pdf of the book online. I hope this helps!
OMG, I read the same book @softwaredeveloping. It was an amazing breakthrough to me.
The book was even hard to read at first and I had to re-read it π .
That book is all you need to know!
Indeed. It's a great book.
Thanks, I will
I hope it helps!
Super glad you like them and best of luck in your journey π
What an awesome freaking list of advice. This is great!
Thanks a lot π
Hi, I either don't understand 26. or I think this is bad advice for junior Devs:
If something (that is part of your job) is a pain in the a** then you need to improve your skills there. As a junior everything can become a struggle: do you have a hard time understanding code that uses
async
/await
? Go learnPromise
. Especially as a junior something that takes a lot of time might actually be a lack of knowledge ("1. Master the fundamentals") and skills ("15. Master your dev tools π οΈ") like keyboard shortcuts, automation, advanced editing features, RegExp for Search&Replace, Refactoring Tools, ...Once you are experienced and established enough you might be able to afford to avoid a task that is part of your job and that everybody else can do.
I find myself telling my managers "Well, I could do that task, but I have the high priority/value tasks X, Y, Z to do. I am not that familiar with this module and need to spend some time getting to know the details. Mid-Level Dev Q is able to do that task as-well and it probably takes them the same amount of time."
Oh I definitely mentioned you need to master fundamentals. Like you canβt be doing frontend and not understand async, etc..
What I mean by focus on strengths is like maybe you are not comfortable with architecting code but you are amazing at building simple UIs/animations, etc. you should focus on that vs. the first one.
Frontend development is large and you have to choose the area where you can be one of the best.
Being average doesnβt pay offπ
Somehow this gives me a bad gut-feeling. Although the field is huge, and I know that in some way I am a specialist, some part of me deeply rejects the Idea that you need to specialize.
We need to learn constantly - and just because today I am bad at creating UIs, it doesn't mean that I should refuse to learn it, when that skill becomes necessary for me tomorrow.
Let me conclude by adding to your advice: "Always keep an open Mind. After you found X is hard, you will learn Y and Z, and some of that knowledge can be applied to X. Just because something is hard for you today, It doesn't mean it has to be when you need to learn it 5 years from now."
I definitely see your point there. I will take an example to illustrate for myself. For example I am bad at coming up with UI/ thinking about the UX, etc. I put in a lot of work but no results whatsoever.
On the other hand, I am very comfortable with JavaScript, with hard problems,etc.
So I decide to rely on people better than me at UX and rely on my strengths instead.
I think we should do what makes us unique more π
this! teams don't exist for no reason, you can't do everything. yes, familiarize yourself with as much stuff as you can, even just to know it exists, but don't try to be a everything man
π― agree even if it is hard!
"Take ownership of your career path" so true!
This one took me a long time to realise. I used to be just there and saying « yes » to tasks.
But no one can have more your interests in mind than you π
This was such a great read, as a junior Frontend Developer with only 3 months of professional experience, I can not relate more to so many of your points. Thank you for sharing these tips and being such an inspiration for us!
Truthfully, I aim to be a reliable senior such as yourself one day, that can guide and help others on their journey. I should stop waiting for "29. Mentor younger devs" until I feel "ready" or "good enough". Your post is eye-opening.
Super glad you like it. Yes there are always people you can help even after 3 months.
i want to make new dev friends
Well, here I am! π
Hi, my name's Benjamin. I've been developing for six months. How long have you been developing? Do you have a dev related job yet?
If your interested in getting in contact, I can send you my email.
i'm working as full-stack dev, developing for 6 years , sure you can share
Oh, okay. Well, I've only been doing front-end six months. Here is my email:
This! π
Wonderful article. Not only did I learn some wonderful tips, I also found I related to many of your experiences @_ndeyefatoudiop. β€οΈ
I am super glad you like all these points, @ashleyd4880 π.
It means a lot to know that this is a shared experience!
great post! π
Thanks π
I'm a junior dev myself. I was able to both empathize and learn from this article. Thanks for taking the time and thought to write it.
I am happy you like it. Hope you wonβt make the same mistakes I did π .
don't spam!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.