Going Beyond Abstraction layers of native behaviour to grow as a new dev
You are a new dev and focussing solely on delivering your task, but have you ever wondered what lies beneath the abstraction layer of your codebase?
Sure, it may seem tempting to stick to the comfort of the abstraction layer, relying solely on the provided methods and functionalities. But you should find time to go under the hood of these abstractions.
I am writing this with the experience I gained in the first 3 months while working with Amazon miniTv team.
Abstraction layers are used to manage complexity, improve modularity, and enhance code reusability. They allow developers to interact with a higher-level interface without needing to understand the intricate inner workings of the underlying components or systems.
While working with the code base, I found that there are abstractions built on top of many native properties. For instance, if you have to use heading
tag, you may use Heading
component which is abstracting the native tag. By passing props, you will be customizing them as per your use case. Understanding this abstraction is easy as there is no complexity beneath it.
However other instances like while accessing values stored in local storage, instead of using the native method like localStorage.get("key")
, there might be an abstraction layer with a different name, such as clientStorage.getItem("key")
. There are several reasons why such abstractions are implemented.
One reason is being a large company, there will be multiple products within the same application/website. If each team starts using native localStorage
methods as per their use, there will be a lot of key-value pairs stored in browser's local storage and it can overload the browser and will cause performance issues. To avoid this, the teams customize the local storage in such a way that the key
is unique for a particular team and inside that key, a team can have their key-value pairs.
When I encountered a task involving local storage, I connected with the folk responsible for creating the customized local storage API. He provided me with a high-level overview of the API's methods, which enabled me to complete my task. However, I didn't delve deeper into the implementation details behind the abstraction layer.
If someone were to ask me today to develop a similar local storage feature, it would require substantial effort on my part. However, if I had taken the time to explore the inner workings of the abstraction layer while working on the task, I would have gained more confidence in the codebase and learned valuable insights.
The key takeaway is to try to look beyond the abstraction layer and understand the underlying logic. You may not grasp everything at once, but it will contribute to your growth and learning. I intend to follow this approach going forward.
It might not be an easy journey at first, but trust me, it's worth it. Embrace the challenge, ask questions, and explore the codebase with a curious mind.
If you're a new developer-facing similar challenge, feel free to share your experiences and let's learn from each other's mistakes.