Sep 8 2022

My Journey

I was a kid like all the kids around the world. Wake up, eat, play, screw up something, and dad blames me. Doing this cycle over and over again. Until one day something magical happened to me. It was a day one of my old friend drove me a flash drive that has a tutorial about how to build software. Back then in my heart, I was looking to understand how I can build one for fun and to stay cool & smart around my friends. That was a stupid plan but it work.

My friend gave it to me & I can't wait to say goodbye to him. Run home and see what's in it. I found some tutorials about batch programming. It’s like bash programming for Linux but this one is designed for windows. I wrote my first language like this.

@echo off
echo Hello, World
pause

Do you know what this program is called? Hello World. Yeah, it's common right but this one is different because It is written in batch programming like no one in the universe ever wrote their first hello world program in a batch language. Then I started writing in another language too. Then the crowd kicked me b/c of this.

I love the process. First, try to build what I want to build. Then get an error when I solve it and get also a bigger error. When I try to solve the bigger error messes up all the code and forgets what I'm trying to solve in the first place. It is an amazing experience and the worst experience at the same time.

That's what I was doing for several years even now.

Now I pack my skills and start showing the world what I got.

There are hard lessons I learned along the way.

1. Overestimate the foundation.

I always get too excited and too fast to finish by jumping some stones on the journey. Only after I get to the destination do I realize I should not be jumped the stones. They are there for reason. The stones are the foundation. They are what will help you to make an original solution. But If you mess up the foundation or the fundamental truths you will not have any power whatsoever to rebuild them or to solve problems. And most of all everything you learned so far doesn't line up together. But they are foundations to keep everything together. Without them, your knowledge will crush.

2. Your circle of competence.

Do you know a person who is a doctor who can do all surgery types? whether It's brain surgery, or other. I bet you not. They are specialists and they can't be perfect at all. That is what we have to consider in the technology world too. There is always too much to learn and knowledge adds up every day with unimaginable amounts. It's hard to keep up with. It will be better to limit the area we want to specialize in and become better at it.

Of Course, maybe your friend will say You're a programmer right? can you fix my computer? You know as a programmer how stupid the question is. If you're a programmer doesn’t mean you know everything. Same goes. When you’re a programmer doesn’t mean you know every language and framework.

3. Project timeline.

John: How much does it take the XYZ project to get finished?

Alex: 4 days.

John: Really that's great news, Okay Alex I will come back to you in 4 days.

Alex: No problem.

After 4 days. Alex, what the hell just I did? I didn't finish the project. So what I'm going to say to Alex 😨️

We are terrible at planning and good at lying. The problem was we don't have a margin of safety. It's a physics term that can be applied to projects too. It is a way of leaving some space to handle the unexpected. After I learn this hard lesson If I think the project will take 4 days, I will tell my client it will take 6 days and do my job as I have 4 days. If I get finished it will be delivered in 4 days. Otherwise, if things don't go as I expected I have a margin of safety for 2 days. So, I can get it done without pissing off my client and me.

4. Scope: You will never finish.

I built two startups. One was enterprise and the other was eCommerce. It was local, not worldwide. I build them one after another. First, the enterprise failed, then I started eCommerce it also fails. There are other factors why they fail but both of them have common ground. It was a scope. I never finish it. There are always ideas out there that need to be added but if I keep saying yes to these ideas guess what I will never finish. So, I make a conclusion whenever I want to build something whether software or other things I should have a clear picture of what I'm going to do.

I should answer this question for scoping the project. What are the things the app can't stay live If I don't do?

Those are the things needed to be done & put out there. Then start listening to what the world is saying. Only then you will make adjustments on that rather than building completely from assumption without grounding in reality and you will be surprised how the world treats you badly.

5. The computer was never wrong.

This is the hard one, Especially when you're angry. You blame the computer for your own fault. But one thing you should realize is the computer was never wrong. Once you realize this truth. You stop blaming the computer and start debugging like a true legend programmer.

But if you get out of control and get angry already. You should close the computer and never come to it again. I'm kidding just back to it in a few hours you will find the solution in front of you. Staying there is the worst thing you can do and your ego will say "Hey you can do it, I believe in you" When you hear these things in your head it's a signal to close the computer.

6. Choosing the tech properly.

Some techs are good for some things and really bad for others. I don't argue with a person python is better than JavaScript or visa-versa. It's a specification. Which one is better depends on the situation. So, the question we should ask is which one is a better choice for this situation? That's what we should do. Sometimes we choose bad tech because it is the only one we know for now. But we should not compare with what we know and what will be perfect for the project. If we don't know it, it will be better to learn it rather than choose the worst tech.