Tebrikler abi. Allah analı babalı büyütsün. 🥰😍

The crucial answer to this was discussed by @scott.hanselman.com way back in 2012. In a nutshell, don’t pour your words into social networks that don’t care and can disappear. Own your words forever. The blog is the best engine of community.

www.hanselman.com/blog/your-wo...

"The hard parts of software development – understanding requirements, designing maintainable systems, handling edge cases, ensuring security and performance – still require human judgment."

I think separate tasks should have their own PR. It should not interfere with the work, otherwise it makes the PRs very difficult to understand. But tidying the tables is also part of the work. I think it can stay in the same PR.

That's because it's difficult and long. It should be a separate task.

Sometimes we change the position of a cupboard in the room. This requires a much bigger change. When the cupboard is moved, the room becomes fresh and light. We always want this kind of change, but we can only do it after months of waiting.

But sometimes we feel the need to completely clean the house at least once a week. Sometimes we get help from cleaners. We set aside a specific time for it. If we don't do it that often, each time it takes longer and harder.

For example, no one wants to work on a messy desk. We usually clean the desk before we work. It's the same with code. We usually touch the code and clean it up. I think this kind of refactoring can be done continuously while writing code.

I think continuous refactoring as described in books is a myth. But it only makes sense up to a point. In fact, we usually refactor the code every time we develop. Everyone does it in one way or another.

My journey is not over. New sharings are on the way...

Over the years, I turned the lessons from this journey into presentations. You can find my "Unlearn"-themed talks here:
speakerdeck.com/lemiorhan

I made a decision: I would start over. From the fundamentals, I would set aside what I thought I knew and relearn software development from the ground up.

This feedback shook me. Until that moment, I was someone who believed in what I knew—someone confident in years of development experience. But I realized I had been wrong.

The email said:
"We feel you have a lot of things we would need you to 'unlearn,' and we feel you over-engineer solutions. Currently, we don't have the bandwidth in the team to support your onboarding."