Technology Agnostic Tips for Frontend Developers
It can be tough to keep up with the rapidly-evolving web development scene. Technology changes so frequently it’s hard to know what’s relevant. If you ask other developers for advice, you’re going to get a wide range of responses, depending on which tech company or framework they’re currently emotionally invested in.
However, during my 10 years’ plus experience in web development, I’ve found a handful of technology-agnostic principles that continue to remain constant — and getting your head around these will keep you on top of your game, no matter how fast things move.
So with this in mind, here are some things I wish I knew when I was starting out.
Coding is a Method of Communication
In the non-technical world, a code is often thought of as something that can be “cracked”; a puzzle that can be solved. In the programming world, it’s therefore easy to think code is intrinsically cryptic — but this couldn’t be further from the truth. We may write code to instruct machines, but our main goal is to effectively convey meaning to other people.
Experienced developers know that good code is synonymous with good communication. Another person is going to come along, read your code and try to understand what it means. Your job as a developer is to effectively communicate what the program does, via a programming language.
Why is this so important? Because the easier a codebase is to reason about, the easier it is to maintain, which ultimately means less bugs and faster delivery. So when you’re coding, imagine you’re describing the feature to another person who needs to make sense of it in the future. It’s also worth considering that the other person might even be your future self!
Technical Words Aren’t Clever
If I wanted you to fetch me a coffee cup from the cupboard, I might say, “please fetch me a coffee cup from the cupboard”. I certainly wouldn’t say, “please initialise a new coffee container instance from the hot drink container dispatcher” — you’d think I’d lost my mind.
Consider a piece of code that checks if a customer is logged-in, and if so sends them to the account page. You might have come across something like this before:
Perhaps the code needs some more clarity? In this scenario, it’s common practice to add a comment:
Can you spot the irony here? We recognised a problem — the words need clarity — so we rectified it by writing more words next to them! If you find yourself adding comments to explain your code, consider refactoring it to read better:
Unless you’re a hacker in a sci-fi film, code doesn’t need to sound technical. The more it reads like natural language, the easier it will be to work with.
Complex Features Don’t Require Complex Code
I’m sure you’ve opened up a file before and thought, “I literally have no idea what this means”. You might even feel disheartened because you were expecting it to look simpler. It isn’t uncommon to suffer from imposter syndrome (I still do) and if you’re not aware of it, it can make you doubt yourself. But in a scenario where you’re presented with a wall of indecipherable text, there’s a good chance the code isn’t written very well.
I hope it goes without saying that pointing out how poorly-written the code is to your teammates is a bad idea! Instead, just keep practicing (you could challenge yourself to write it in your own words in your spare time) and eventually you’ll become confident enough to suggest better ways of doing things.
Code really doesn’t have to be difficult to understand — I’ve never come across a feature so big and so complicated that it warranted complex code behind it. Don’t settle for high code-complexity — it will only slow you down. There’s always a way to decouple, rename and abstract to make things more readable.
Surround Yourself with Good People
You know that Senior Developer who maintains parts of the codebase no one else will touch? The same person who works in isolation for weeks on end and emerges with a masterpiece that nobody else understands? That’s probably someone you’re not going to learn anything from — in fact, I’d go as far as to say, they’re not actually very senior at all.
A friend of mine once described seniority as, “something that can be measured by how many people are learning from you” — I really like this idea. In contrast, I can tell you that seniority is certainly not measured by how many features you exclusively own or the number of zeros in your pay packet.
If you want to progress, you need to work with people who have your best interests at heart. Find others who seem passionate about sharing their knowledge. People who, if they don’t have the answer, gracefully admit it and Google it with you so you can both learn. Those are the ones who will help you master your craft and achieve your career goals.
Put Your Customers First
It might seem counterintuitive, but when presented with requirements, the sooner you learn to stop thinking about code, the better your features will be. When a request comes in, your first thought should be, “what problem are we trying to solve?”. Once you’ve understood that, your next thought should be, “what solution would result in the ultimate customer experience?”.
You need answers to these questions before you start building. You also need to continuously ask these questions during the build. If you don’t, your code might be amazing but you won’t be able to deliver maximum quality. And don’t make the mistake of thinking you’re off the hook if you’re building an API; you still have customers, they’re just called developers!
Don’t lose sight of the end goal — quality code isn’t necessarily valuable code — you’re aiming to deliver a quality customer experience.
No Code is Good Code
No code means no bugs. No code means no time or money spent. If a business request comes to you or your team and you’re smart enough to turn around and say, “Have you considered solving the problem with X?” (X being a product or feature that already exists in the company), then you’re a hero!
No business wants to spend time and money unnecessarily; if you have the technical knowledge to suggest a free alternative, you’re actually providing a ton of value.
And Lastly… Enjoy the Struggle!
There will always be something new to learn — this never stops. Don’t kid yourself into thinking you can “win” or reach a point where you know everything. If you do feel like you know everything, you’re probably experiencing the Dunning-Kruger effect — it works a bit like this:
Over time, I’ve learned that feeling slightly out of my depth is a very good place to be. Slightly out of your depth is that sweet spot where you know what you’re doing but you’re also learning at the same time. Embrace this feeling and enjoy it — it’s a good indication that you’re progressing.
Thanks for reading! If you enjoyed this article, please share and recommend.