I decided to change career from pharmacy to software engineering in 2018, which has changed my life forever. Since that time, I've had the chance to work on a range of projects, either independently or as a member of a cross-functional team.
Despite the fact that I have not been around for a very long time, I have discovered and seen a few factors that consistently lead to positive outcomes. I have also noticed the actions that don't result in the desired results.
I'll thus be sharing some lessons I've learned from my time spent working as a frontend engineer. These are my opinions. The ideas I present in this post have been shown to yield positive outcomes. I'd be interested to hear your opinions if you disagree with any of them, though. This article aims to impart some important lessons I've discovered that might be useful to others. I will therefore be glad to benefit from your experiences as well.
Well, with that said, let's get started!
A. If you understand the problem then you are 50% done even before writing the first line of code.
As software developers, our daily work revolves around finding solutions to challenges. Hence, when faced with an issue at work, it can be tempting to want to write code right away and provide answers.
If you are certain that you already comprehend the issue you are trying to tackle, then this is acceptable. But it turns out that this isn't true the majority of the time. Before attempting to write code to address a problem, it is crucial to make sure you have a thorough understanding of the problem and you know what success looks like.
This approach has some advantages such as:
- It helps to solve the root cause and not the symptoms of the problem.
- It helps to come up with a more robust and maintainable solution.
- It prevents you from wasting your time and that of your colleagues
- It saves resources in the long run
The most crucial lesson I've learned as a frontend engineer, in my opinion, is to fully comprehend the issue before writing any code!
Reading the technical/product specifications, asking the appropriate team member questions to clear up any confusions, doing internet research on the issue, etc., are all strategies for comprehending the problem you want to solve.
B. Be a team player. It's about institution and not individual.
Being a proficient and dependable software engineer is crucial. But playing well with others is just as crucial!
Being a team player and acting with humility at work go hand in hand. Never assume that because you have a task or feature to work on, it is because you are the most qualified for it. Someone else on your team might be able to perform the task better. Forget the reason why, then. Instead, concentrate on doing your best to provide a high-quality outcome.
To be a good team player, you must also communicate with your teammates, support them, and provide them quick feedback.
C. Consume quality content
Online resources are abundant for learning how to code. These are generally all free. Some of the paid resources are affordable, while others are pricey.
Yet, I've come to understand that quality, not price, should be the deciding factor when selecting a tutorial or course to enroll in.
Some questions to help assess the quality of a content includes:
- Who is the author?
- How many people have subscribed to the course?
- What are the reviews from those who are already taking the course/tutorial?
- What is the average rating?
- When was the the course published?
- When was it last updated?
- Does it contain updated syntax, APIs, and concepts?
As a Frontend Engineer, I have found certain platforms and tutors who are known for publishing quality content. They include Frontend Masters, Framework documentation sites (e.g Vue and React), Vue School, Vue Mastery, Scrimba, and courses by Michael Thiessen, Maximilian Schwarzmuller and The Net Ninja.
Of course, the list is not all-inclusive, but you get the idea.
D. Avoid a toxic work culture and a toxic boss!
I won't focus too much on this. But it's vitally significant.
When I'm considering joining a new company, the work culture is the first thing I consider, not the compensation. I'm not sure about you, but I work best in settings that value a healthy work-life balance, a culture of respect for others, and an open-door policy for employees to express their opinions and be creative.
E. The code should be based on the experience of the product. The product should be based on the experience of the user.
The lesson from this point is simple: The development of a software product should be user centric
It's crucial for software developers to code with the user in mind. In this manner, you can develop empathy and be motivated to implement simple and enjoyable user interfaces. Also, you can speak with the product manager or tech lead if you notice that a product or technical requirement won't contribute to making users' lives easier.
F. Testing is not only for QA engineers.
It's crucial to test the code you create. In addition to designing clear and manageable code, testing your code ensures the dependability of the final output.
In light of this, I believe you should write clean code as if you won't test, then test carefully as if you don't trust your code.
G. Take breaks
Taking breaks at intervals can boost productivity. Taking short intermittent breaks as you code can help manage stress and prevent burn out.
I have also noticed that sometimes all you need to figure out the solution to a coding challenge or bug fix is to take a break. You'll be mentally prepared to take on the challenge once more when you return to the code. And occasionally, during your break, you might have an epiphany, after which you can quickly return to your code and succeed in the task at hand š
That's it! The seven important lessons I have learned while working as a frontend engineer.
Do you agree or disagree on any of these points? Would you like to share the lessons from your own experience? It will be nice to know what you think.
Thank you for reading š
Top comments (12)
10 years experience in different teams as a freelancer. Wholeheartedly agree with your article!
Thanks You, Resnse. It's good to see more experienced engineers agree with these tips.
this are worth reading fact and alot of lesson was gained... thank you for sharing your precious experience..
Based on all that you have listed, i will wish to improve myself on th testing aspect. this is something i dont know how to but i will work on this to improve my code efficiency
thanks @timothyokooboh
Resonates with my 25+ years of development!
Wow that's awesome. Thanks Marc for sharing
It is the quality content, and breaks for me.
I realised I'm always in a better frame of mind to tackle bugs when I take breaks in between. Interestingly, before the break time runs out I'm running back, as you said, with an epiphany of what to do.
Quality content consumption, always a deal breaker/maker.
And, about testing, ahh. I am learning. Great line there - ''write clean code as if you won't test, then test carefully as if you don't trust your code.''
Thank you Timothy!
You should share more often ;)
These are really helpful tips!
Thank you
People really underestimate the benefit of taking breaks. Great tips all around!
I agree. Yet taking breaks helps to relieve stress, improve focus and productivity.
full agreement
It is foolishness to be shameful of what is gainful, I have learnt a lot from these articles, and the knowledges I got from these articles, will be a light to my path, as I continue on this journey .Well-done to you bro, more height.