Conway's Law Never Lies #dfist25 Here is the extended version of my slide deck.
Thanks to everyone who joined my talk and to the GDGIstanbul crew for organizing such an awesome festival.
speakerdeck.com/lemiorhan/co...
Here is the deck that I delivered at my talk at Devnot Summit 2025: Fixing The Typos in Engineering Culture speakerdeck.com/lemiorhan/fi...
Enderinko yeni bölüm yayında 🎉
Lemi Orhan Ergin ile "Mükemmellik Yerine Adaptasyon: Modern Yazılımcının Rehberi"
🔥 3 önemli çıkarım:
Deadline koyarak öğrenme hack'i
Mükemmel kod obsesyonu neden kariyer katili
Senior yazılımcının "hissiyat" süper gücü
Daha fazlası bölümde. Keyifli dinlemeler.
Tebrikler abi. Allah analı babalı büyütsün. 🥰😍
Could (almost) everything we know about Agile be wrong?
It is best to leave all our assumptions and beliefs aside and let's start questioning the agile concept from the beginning.
speakerdeck.com/lemiorhan/ev...
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...
There are no agile practices, sorry. There are:
product management practices
project management practices
communication practices
collaboration practices
development practices
leadership practices
feedback practices
sdlc practices
Context is everything!
The deck of Unlearn Product Development, Unleashed Edition is now available!
This version dives deeper into lessons learned at @craftgate.bsky.social, offering insights on solving real problems, building meaningful products, and rethinking how we work.
Take a look: speakerdeck.com/lemiorhan/un...
50%+ linkedin posts are AI generated.
AI generated bullet points with an AI generated header image.. It sucks, I hate them. Take my money and show me just human-generated content please.
Discover why most teams unknowingly develop projects, not products, and why we get stuck in deadlines, useless metrics and ‘feature first’ thinking.
Let's deep dive into "the project & product mindsets"
speakerdeck.com/lemiorhan/un...
"The hard parts of software development – understanding requirements, designing maintainable systems, handling edge cases, ensuring security and performance – still require human judgment."
This is a powerful idea to keep in mind when giving and receiving advice:
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.
Should we continuously refactor our code within development tasks or create separate refactoring tasks? My answer is that it depends.
+ thread
Introducing the Problem Solving Operating Model (PSOM™®©)
“Don’t Repeat Yourself” is advice that only makes sense when developers are talking about semantics.
Even if two passages of code are identical, unless a change to one should always change the other nothing has been repeated.
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."
The evaluation came back: I was rejected. No explanation. For weeks, I tried to find out why. After a month, I finally got a response.
Taking this seriously, I used TDD for all my coding. I wrote BDD tests, reached 100% code coverage, and ran performance tests to optimize everything. I submitted the project with pride.
The coding step was critical. They gave me a project to complete at home. I took annual leave, locked myself away, and got to work. I was told the company cared deeply about Object-Oriented Programming and expected flawless code design.
For years, I dreamed of working for a foreign-based software company. When their Turkey office posted a job opening, I was thrilled. I applied immediately. The process included 5 interviews: face-to-face, written tests, and even a coding assignment.
