Seven Lessons I Have Learned From My Experience as a Software Developer
Tags: productivity, discuss, career, programming
Published: 2023-03-06 18:59:01

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](https://frontendmasters.com/), Framework documentation sites (e.g [Vue](https://vuejs.org/) and [React](https://reactjs.org/)), [Vue School](https://vueschool.io/), [Vue Mastery](https://www.vuemastery.com/), [Scrimba](https://scrimba.com/), and courses by [Michael Thiessen](https://michaelnthiessen.com/), [Maximilian Schwarzmuller](https://www.udemy.com/user/maximilian-schwarzmuller/) and The [Net Ninja](https://www.youtube.com/@NetNinja).

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 😊