My other approach to getting things done is that there are no special people, however there are special processes.

Every engineer or builder should have a process on how they get things done.

I am writing this as a manual for two reasons. To keep my action and thinking process clear and to help developers and builders who need an idea of how they can go about the day to day mundane work of getting stuff done.

Frequently I will update this guide as I learn new things, but my processes at this stage of my career revolve around learning, building projects, refactoring, solving algorithmic problems, and writing.

And this how I do each of them:

Learning

1. When I am first introduced to a technology that I intend adding to my stack. For example, I want to learn about Java, I focus on answering questions about the technology like:

   ✅ Why was this technology created?

   ✅ What problem does it solve?

   ✅ How do engineers use it in real life today?

   ✅ When is the right time to choose this technology?

   ✅ What are the other alternatives to using it?

2. Then I go through the documentation and read the quick start articles on it, go through some tutorials in the documentation and try to understand it, code along, research more on it, but I basically try to understand the basic and absolute fundamentals of the technology through the docs.

3. After that I hop on a short to medium YouTube video that uses the technology to build a fairly real world problem. It could be a website or a web app, something that interests you, or you are comfortable with. With this YouTube video, I use the CPU approach.

• Toggle for the CPU approach

1. Try to use it to work or build projects with it.

Building Projects

This can get fairly complex but I try to keep it simple.

1. I breakdown the project into user features or a user story entailing what the project should have.
2. I map out the technologies I want to use for the project.
3. You can expedite the previous options using AI.
4. If the technology is part of your stack, fine. But if not, I use my process for learning to quickly get a hang of the technology.
5. Then I start building, but the catch to avoid the illusion of building is that I only learn a new technology when it is time to use it in the project and never before, so I can only learn what I need to build.

Writing