7 Things that helped me in my DEV Journey
Tags: beginners, programming, productivity, webdev
Published: 2024-02-29 14:16:56

Hey Folks!!

It's been a long time since I posted on this community.
I'm glad to say I am back :)

Here are 7 things which I have learnt along my DEV journey which has helped me personally to improve on my skills - 

## 1. Solution before implementation

I can assure you, if you don't do this you'll have to re-write multiple times.

Whenever you are given with a problem - 
1. Create a flow diagram which envisions all the negative scenarios and what will happen when that negative scenario occurs

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/g562a14u8a9sa3nhy0l2.png)

2. In case there are multiple systems involved, each system can be a point of failure hence you have to consider the scenario when any or all of them are down.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/q9m8ya63lzmqou61caps.png)

3. Review with senior DEVs and subject matter experts.

## 2. It is what it says it is.

Most of the times we overlook the error message and try to debug things by ourselves and end up in circles. I have observed that **99%** of the times the error is exactly what it says it is and it also suggests how to solve it.

Example :- 
```js
console.log(student.name)
```

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7d6gujllpvbnt1mxuwyq.png)


The error is clearly mentioning that you cannot read an attribute of undefined

In this case you are reading the **'name'**, however the student object itself is undefined.

I've been here too many times.

**Learning :** Always read the error, try to understand the message and exactly at what line it is occuring

## 3. PR over direct merges and build before commits

1. If you are working on a project where there is a small team and code review flow is not setup, make it a habit to still make a pull request and review your own code.
2. I took this tip from one of my friends and it works wonders, when we wear a developer hat we enter the developer mindset to get things done, but post development we need to wear the reviewer hat and actually review our own code without bias. This will help you cut down on a-lot of bad practices, think about clean code and reducing redundant DB / API calls.
3. Always build your solution before committing code, we often over-look our code and miss out a semi-colon or have some typos.
Introducing a small build / compile step before you commit will help you gain a clean history and reduce **"Fixed xyz"** commits

## 4. Modularize and Reuse, Plug N Play

1. Wherever possible try to identify a logic which does a generic thing and can be applied across solutions, remove that chunk out and keep it as a separate module which can be plug and play.
2. Keeping these common modules logically grouped outside the system will help you maintain them easily. 
3. Learn concepts like unit of work, SOLID principles, segregation of layers, they will help you in the longer run.

## 5. Logging is ART.

1. Logs are like hints which will help you solve the crimes of the past.
2. While adding logs always keep in mind the functional requirement and add the necessary meta data which you feel will be required to cover that functionality.

Example - You have a page for admins where they can modify / add users to the application

In this context it is important to log the who, when, whom and why.
```
admin : "Prafulla"
action : "AddUser"
user: "PrafullaB"
reason : "Requested access to the portal and fits the role"
timestamp : "25-02-2024 12:30:00"
```

The above fields will change based on the functionality, however it is important to log the key fields by which you will have to search the logs to help you in times of difficulties / audits.

3. Never logs passwords in your logs.
4. Encrypt sensitive data while logging.
5. Too much of logs (or anything) is bad for health. Log only the crucial things and in case of exception handling.

Example : You  have a method fetch_data_from_db() which fetches 1 million records from DB


```js 
  data = fetch_data_from_db()
  console.log("fetched data ")
  console.log(data) ❌
```

Log only the required things like the count of data fetched and in case of failure exception - 

```js
 try:
    data = fetch_data_from_db()
    console.log(`fetched ${data.length} records`)✅
 catch:
    console.error("Failed to fetch data")
```

There's just a-lot of useful things we can do by optimizing the logs.

## 6. Prevention is better than cure

Yes you read that right, you don't want to end up losing company reputation and tons of money by overlooking security measures.

If you have an application with a-lot of users and contains sensitive data, it is extremely crucial to ensure the right security checks in place - 

1. Encrypt Passwords
2. Mitigate Risks of SQL Injection
3. Check that a proper role based authentication is established which functions correctly when new users are added and removed.
4. Whitelist third party APIs
... (This list is never ending, implement security measures based on your application scale and criticality)

## 7. Unlearning 

Many times we learn things and connect the dots unknowingly without knowing what's happening at the back-end. I have learnt that as I keep learning more about the systems and architecture I keep realizing how limited my knowledge is in the domain. 

The skill of unlearning has helped me tremendously cut down a-lot of misinformation and wrong methods which I learnt in the process and replace them with actual facts.

That's a wrap for now. Thanks for reading ^_^ 💖
Feel free to discuss and add your learnings in the comments.