30 frontend tips

January 4th, 2022 · ~5 minutes

I recently posted a Twitter thread of 30 tweets on frontend development. Pieces of advice I wish I had when I started in the field over 10 years ago. This post is basically the thread verbatim, kept for posterity on this site.

Learn what you want. There is enough to learn for a lifetime, so don’t feel like you have to follow the hype. Frameworks and libraries come and go, fundamentals remain, so I would recommend focusing on HTML, CSS and JavaScript if you get to choose (and do frontend).
Learn about accessibility, when you get a chance. At least the basics, like what it is, why it matters, how it works… It’s core of frontend development, and tend to be forgotten or included too late in the process. Get into it early if you can!
Don’t get too precious about your code. Trash it if needed. Start over. You’re more than your output. If someone has a better solution, consider it. Being too attached to code is just an impediment in my opinion. Code doesn’t have to be yours to be valuable.
Write code for humans. Write code comments. Self documenting code is a harmful myth, don’t fall for it. Slap that whole paragraph before that function to make it clearer to the next person (might be you!). Comment your code and encourage others to do so.
Use an incremental approach as much as possible. Don’t prematurely optimize. Things don’t start perfect. Write that crappy code. Copy paste some stuff. Make it work first. Once it works and you get it, improve it, clean it up, polish it. Or not, sometimes it’s also fine!
Set up Prettier wherever you can, no matter what configuration you choose. Life is too short to argue about coding style. Automate that stuff so your code reviews are actually interesting and valuable. Don’t turn people into human linters — it’s costly and ineffective.
It eventually becomes interesting to know a bit about setting up automated deployment or perhaps even testing. No rush, and no big deal if you don’t know much about it. But it did come in handy for me to learn about continuous integration & deployment.
If you have the occasion, dig into Cypress. It’s the best thing that happened to frontend testing in the last decade in my opinion. It’s an absolutely incredible tool that’s completely free and open-source which makes end-to-end testing reliable and (gasp) even enjoyable.
Spend time on docs. At work, for your side projects, for yourself. It’s severely underrated, which is a shame because it’s absolutely vital. I am convinced one of the reasons I’ve had some success as a dev is because I love writing. Documentation is worth time and effort.
Debugging is a skill to learn. It takes time, it takes practice. It starts by reading error messages, and learning what to Google. It gets easier with time, and is a useful (necessary?) skill to grow. Don’t get frustrated if you struggle, especially at the beginning.
Accept that you can’t understand everything. Heck, you don’t even need to understand everything! Go with the flow. Dig when you need to, otherwise just take things as presented, enough to do your work and move on. Knowledge grows with experience.
Admit when you don’t know stuff. A common mistake people do when getting seniority is to think they have to know everything not to appear weak or something (definitely done that as well). It’s good to admit not knowing. It shows humility and gives credibility.
Ask for help! Don’t get stuck needlessly. Give it a good try, do some research, and if you’re blocked, then ask around. Ask your peers. Ask Twitter. Ask your manager. It’s fine to ask for support, it’s a healthy attitude which pays off. Collaboration is often key.
When pairing, let the least experienced person (if there is one) drive. Otherwise they could get lost, or confused, or stressed out. Have that person set the pace and lead the session with questions and suggestions. Pairing is a collaboration, not a lecture.
In most cases, I’d recommend staying away from coding challenges if you’re involved in hiring devs. They are unhelpful, exclusive and stressful. Design a good conversational technical interview instead, which should yield same or most likely better results in my experience.
Surround yourself with people who care. Care about others, care about quality, care about safety. “Jerk geniuses” are typically way more jerks and way less geniuses than advertised. People who can collaborate, share and compromise are the people you want to work with.
Tech is not a zero sum game. You don’t have to diminish people’s success to feel good. Their achievements don’t negate yours. You get to be happy and proud of your peers for succeeding, even in places where you might have not. Celebrate their success with them!
Similarly, don’t compare yourself to others. At any point of your career. Some people will be better, faster, or just different. This is not a competition. Your career is your own, not theirs. You design it, shape it and pace it the way you want, that works for you.
A tough but important one: acknowledge your mistakes and shortcomings. It takes guts to admit you were wrong or messed up, but it’s important. It shows humility, it shows professionalism and it builds trust.
Learn to pick your battles. Especially when gaining more seniority, we tend to want to be involved in more topics to gain knowledge, experience and influence. But not everything is worth it. When in doubt, make it a group conversation, share your opinion and move on.
Faking confidence has helped me at times. Sometimes you have to shield less experienced/senior people from the stress or the uncertainty so they can safely focus on the task at hand. Tell them it’ll be fine, and take the tough part away from them.
Following up on this, if you have the authority or position to make someone’s life easier, use it. Lend them your authority if that makes sense. Help them settle conflictual situations. Save them some battles if you can, by just being there and supporting them.
Give constructive feedback when asked or possible, and welcome feedback given to you — be it technical or otherwise. It’s a good way to improve, to grow, and to be better towards others. Contribute to creating a culture of feedback in your organization/community.
If you notice someone being particularly good at something, tell them. Your acknowledgement might mean a lot to them, and be the push they need to keep doing that thing so well. Give praise when due, publicly ideally, otherwise at least in person.
If you can, especially if you’re in a privileged position, participate in shaping a heathy and inclusive environment. Use your position, your privileges, to make people safe and comfortable. Speak up. Amplify voice of your peers, especially from under-represented groups.
On a similar note, make sure everyone gets a chance to contribute and grow. Learn when to delegate and empower people to take on new responsibilities in a safe way. Build confidence and seniority by trusting them to take ownership of situations and discussions.
Being the “smartest” person in the room is not always desirable. If you happen to be, share your knowledge. Don’t be that person hoarding knowledge and responsibilities to be important. Making myself obsolete at N26 was the best move I’ve pulled in retrospect.
You don’t have to hustle all the time. Take on side projects if you want to, not because you feel like you have to. Resting is productive. Taking time to do something else is healthy. You’re more than your work.
Find yourself a hobby outside of coding maybe? Coding gets old eventually I think. Having another way to spend time that sparks joy is probably a good thing. I like writing, playing with my cats, and playing video games on my phone (or laptop sometimes).
Simple and strong one for last: be nice to people. We all try to do our job and go through the day. People are not the NPCs of your life. Be kind, don’t burn bridges. Unless they push you around, in which case tear them a new one.

Last but not least, kind thanks to Adiya Mohr for helping me come up with some items in this thread. Make this my last advice then: find yourself a friend like Adiya. ✨