DEV Community: Ender Ahmet Yurt

Why Do I Keep Killing My Side Projects?

Ender Ahmet Yurt — Mon, 20 Apr 2026 05:20:35 +0000

I recently shut down Bloudme. It was my second personal project, which started as an RSS reader and quietly died. Before that, there was Podiscover — a social media platform for podcasts. Two projects, two deaths. At some point, you need to stop blaming circumstances and start asking harder questions.

This isn't a piece that starts with "what I learned from failure" and ends optimistically. This is an attempt to understand a pattern.

Two Projects

Podiscover was born out of a real void. At the time, there wasn't a dedicated social platform for podcast discovery. The timing was technically perfect too. Rails and Hotwire were new, and I wanted to both learn and create something. It started well but building a social platform alone is a brutal undertaking. I couldn't find anyone to help me with the UI side. I didn't fully understand the market I was trying to target. I was alone and eventually got bored.

Bloudme was different in scope but similar in spirit. A deliberately old-school RSS reader: share RSS links, the system pulls them every three hours, and you read them whenever you want. Simple. But simplicity wasn't enough for me. I constantly wanted to add more. Meanwhile, nobody was using it. It was burning through the money. My motivation evaporated.

The Pattern

When I put the two side-by-side, the same sequence emerges:

Genuine need → Technical excitement → Solitude → Doubt → Death.

Both projects started with something I genuinely wanted to see exist in the world. Both offered an excuse to explore new technical fields. And both died not because the idea was bad, but because the distance between "I did it" and "someone cared" was too wide and too quiet.

There are a few specific modes of failure worth naming.

I confuse technical curiosity with product belief. Learning Hotwire was a legitimate reason to start Podiscover. But learning a framework isn't the same as being tied to a market. Once the novelty of the technology wore off, I didn't have a deeper reason to continue.

I do it alone, and solitude kills motivation faster than any technical problem. I'm an introvert. Solo development comes naturally to me. But there's a difference between working alone by choice and having no one to share your progress with. No co-founder, no early user giving feedback, no one saying "it's great, keep going." Silence becomes a decision.

I skip the validation and go straight to building. In both cases, I started coding without a single person promising to use what I was making. The market signal was zero, but the terminal was open, so I wrote. This is the classic developer trap: coding is comfortable, talking to people isn't.

I let even small costs fuel suspicion. Running Bloudme wasn't expensive. But when you combine "nobody's using it" with "and it's costing me money," the rational conclusion writes itself. Cost isn't really the issue. It's a symbol.

Things I'm Not Sure About

I don't know if this pattern is a lack of perseverance or an ability to spot dead ends early. Maybe killing Podiscover and Bloudme was the right decision both times. Maybe the real mistake wasn't abandoning them — it was starting without the conditions for success.

I also don't know if I really want to build a product or if I want the identity of someone who builds products. Those are two very different things.

The first requires talking to users, iterating over tedious things, and tolerating long plateaus. The second only requires a GitHub repository and a launch tweet.

What Would I Do Differently?

I'm not swearing off side projects. But next time, I want to change the inputs, not just expect different outputs.

Start with a person, not a repository. Before writing a single line of code, find someone who will actually use that thing and give honest feedback.

Separate learning from building. If the goal is to learn Hotwire or try a new Rails feature, do an experimental project. If the goal is to make something people use, choose the boring technology you already know.

Set a cancellation criterion beforehand. Instead of slowly losing motivation over months, decide from the start: "If I don't have 10 active users by week 8, I'm stopping." Make quitting a decision, not drifting.

Find someone. It doesn't have to be a co-founder. Just someone who cares enough to check in. A weekly "how's it going?" from someone who understands what you're doing changes everything.

Sad but True

Two consecutive dead projects is a data point. If it happens a third time with the same pattern — solo development, no users, death of motivation — it's not bad luck. It's a system that produces a predictable outcome.

The projects didn't fail because I wasn't technically proficient. They failed because I optimized the part I enjoyed (building) and skipped the important part (connecting with users). It's not a project problem. It's a me problem.

And knowing this is either the first step toward fixing it, or another form of complacent self-awareness that changes nothing.

I write about Ruby, Rails, and software development every Thursday. You can follow me at enderahmetyurt.com.

Why I Stopped Using STI and Started Using Delegated Types

Ender Ahmet Yurt — Thu, 16 Apr 2026 05:33:26 +0000

We hold a Ruby Campfire at the company I work for, bi-weekly. It's not a real campfire of course — we work remotely! Recently, we talked about Ruby delegated types in one of those meetings. It was really interesting. I used to use STI (Single Table Inheritance) to connect multiple tables, but it turns out there is a different and more effective solution.

Background

Single-table inheritance looks simple at first. One table, one type column, done. Rails makes it easy to set up.

But then the problems start.

I've been writing Rails apps for over 14 years. I've seen the STI trap many times in my own code too. You start with two or three similar models, put them in one table, and move on. Six months later, the table has thirty columns. Most of them are NULL for any given row. The type column is the only thing keeping it together.

There's a better option. Rails has had it since 6.1. It's called delegated types.

What's Wrong With STI

STI works fine when your models are very similar. When they share most columns and only differ a little in behavior. The Rails docs say it clearly:

"STI works best when there's little divergence between the subclasses and their attributes."

A simple example: you have Message and Comment. You want to show both in a feed and paginate them together. STI lets you do that. But a Message has a subject column. A Comment doesn't. With STI, the comment row gets a subject column anyway. It's just always NULL.

Do this with enough models and enough columns, and your table becomes a mess. It's hard to query, hard to index, and hard to understand.

Polymorphic associations fix the sparse table problem, but they bring other issues: no foreign key constraints, more complex queries, and it gets confusing fast.

A Third Option

DHH added delegated types to Rails 6.1. The idea is simple: keep the shared columns in one "superclass" table. Give each subclass its own table for the columns that are specific to it.

DHH said this pattern had "the most profound impact on how we do domain modeling at Basecamp". They used it in Basecamp 3 and then in HEY.

Here's how it looks. You have an Entry model. It holds the shared stuff: creator_id, account_id, timestamps. Then Message and Comment each have their own tables with their own specific columns.

class Entry < ApplicationRecord
  delegated_type :entryable, types: %w[ Message Comment ]
  delegate :title, to: :entryable
end

class Message < ApplicationRecord
  def title
    subject
  end
end

class Comment < ApplicationRecord
  def title
    content.truncate(20)
  end
end

Now you can call entry.title on anything in the feed. Message returns its subject. Comment returns a short preview. The caller doesn't need to care which one it is.

The schema stays clean. The entries table has only shared columns. The messages and comments tables have only their own columns. No NULL columns, no if record.type == "Message" checks in your views.

How Is This Different From Polymorphic Associations?

Delegated types are built on top of polymorphic associations. DHH called it "syntactic sugar" in some early discussions. But the intent is different.

With normal polymorphic associations, you go from parent to child: fetch a Post, then get its images. With delegated types, you go the other way. You query from Entry and let it delegate to the specific type. Entry is the main entry point. Message and Comment are details.

This means you can write Entry.all and paginate across all types with no UNION queries. You can eager-load associations on Entry. You can build controllers around Entry that work for both messages and comments.

When to Use It

Delegated types aren't always the right choice. If your models are very similar and you don't need pagination across types, STI is fine.

But if you see yourself doing any of these things, delegated types are worth trying:

Adding columns to an STI table that only one model uses
Writing if record.type == "Message" in views or controllers
Having trouble paginating across different model types
Building a feed, timeline, or activity log with different kinds of content

One Thing to Know

When you need to filter by a subtype-specific column, you need a join. If you want to filter by messages.subject, you join entries to messages. This is usually fine, but it's good to know before you start.

How to Set It Up

Creating a record is simple:

Entry.create!(
  entryable: Comment.new(content: "Hello!"),
  creator: Current.user,
  account: Current.account
)

Rails gives you scopes and helpers automatically: Entry.messages, Entry.comments, entry.message?, entry.comment?. Rendering is clean too:

<%# entries/_entry.html.erb %>
<%= render "entries/entryables/#{entry.entryable_name}", entry: entry %>

Each type gets its own partial. Entry doesn't need to know which one to pick.

Why It Matters

Rails is opinionated. It bets that good conventions make code easier to work with over time. Delegated types feel like one of those conventions — not a new abstraction for its own sake, but a name and a structure for something developers were already doing by hand, usually in a messier way.

If you've been using STI out of habit, it's worth reconsidering. Not every model hierarchy needs delegated types. But the ones that do will be much cleaner for it.

I write about Ruby, Rails, and software development every Thursday. You can follow me at enderahmetyurt.com.

The Hidden Cost: AI's Time Complexity Trap

Ender Ahmet Yurt — Mon, 13 Apr 2026 06:07:09 +0000

These days, the moment a problem gets stuck in our heads, we turn to AI for help. We explain our problem, it gives us some answers. How accurate or high-quality those answers are is always up for debate. If we know the subject well or have some background, it's easy to interpret AI's responses but what do we do when we don't?

As developers, AI is now a tool for us. I think there's no one left among us who doesn't use it. From writing code from scratch to updating existing code, AI is now our teammate in many tasks. But how consciously does this new teammate suggest code? How much of the code it suggests actually works properly? Can we be sure that code won't cause us problems down the road?

I wanted to start this post with some questions to stir things up a bit. The answers are all hidden within us. Today I want to talk a little about my own experiences, about the consequences of accepting AI-written code without thinking, and about how we can catch those problems early if we just stop and think.

The Silent Trap

You ask AI: "How can I find duplicates in this array of 100,000 user records?" It gives you 20 lines of clean, working code. You copy it. It works. You deploy it. Three months later, your data import job takes 45 minutes instead of 5. That's the hidden cost of not reading the code AI wrote for you.

Here's the thing about AI-generated code: it works, but it usually doesn't work efficiently. AI models are trained on a massive corpus of code collected from the internet. That code reflects the average, not best practices. When you ask an AI to solve a problem, it statistically generates the most common solution, not the most optimal one.

And here's the key point:

If you don't understand what the code does, you can't see the inefficiency

This isn't about AI being "bad" or developers being "lazy." It's about a fundamental shift in how we consume code. Back in 2015 when you copy-pasted from Stack Overflow, you'd usually skim through the answers and pick the one that made sense. You understood what you were copying. With AI, code looks so fluent, so professional, that understanding it feels optional. But it's not.

Example 1

Let me give a concrete example from my data migration work.

Problem: Let's say I have a CSV file with 50,000 user records. Each record needs to be deduplicated by email address before importing.

A typical AI solution:

class UserImporter
  def deduplicate_users(records)
    deduplicated = []

    records.each do |record|
      if deduplicated.any? { |r| r[:email] == record[:email] }
        next
      end
      deduplicated << record
    end

    deduplicated
  end
end

Looks reasonable, right? It works. With 100 records you won't notice anything. But what about 50,000 records?

Time complexity: O(N²)

Why? For each record (N iterations), you're checking whether it exists in the deduplicated array using .any? (which is another N iterations in the worst case). That's nested loops. That's exponential pain. To visualize it quickly:

1st record: 1 check
2nd record: 2 checks
...
50,000th record: 50,000 checks

Total: ~1.25 billion comparisons.

On a modest server that handles ~1 million comparisons per second, you're spending more than 20 minutes just to remove duplicate records.

A Better Solution:

class UserImporter
  def deduplicate_users(records)
    seen_emails = Set.new

    records.select do |record|
      if seen_emails.include?(record[:email])
        false
      else
        seen_emails.add(record[:email])
        true
      end
    end
  end
end

Time complexity: O(N)

Same 50,000 records. Same logic. The difference? Instead of taking more than 20 minutes, it finishes in seconds.

Understanding the tradeoff between array lookup (O(N)) and hash/set lookup (O(1))

Example 2

The first example was about processing large files, and maybe not everyone deals with that day-to-day. But the example I'm about to give is something we all run into very often — N+1.

# What AI suggests
users.each do |user|
  puts user.posts.count  # A SQL query runs for each user
end

# The code after paying attention and fixing it
User.includes(:posts).each do |user|
  puts user.posts.count  # All data loaded, single query runs
end

Example 3

# O(N²) nested loop:
results = []

array1.each do |a|
  array2.each do |b|
    results << a + b if a == b
  end
end

# Better:
common = array1 & array2
results = common.map { |a| a * 2 }

Why Does This Matter?

1. Data Grows Faster Than Hardware

Your test data has 100 records. Production has 100,000. An O(N²) algorithm that's invisible in tests becomes a bottleneck in production.

2. AI Doesn't Know Your Context

AI generally answers your question. It can't know why you're asking or what you're going to do with the answer.

3. Performance Debt Accumulates

Bad algorithm + bad algorithm + bad algorithm = system failure. You won't notice individual O(N²) operations. But when you have 10 of them on your critical path, a feature that "should take 2 seconds" takes 20.

What Should We Do?

Checklist:

Read the code. Don't skim it. Read it.
Ask about scale. "This works for 100 records. What about 100,000?"
Check for common traps:
- Unjustified nested loops
- Array operations inside loops (.include?, .any?, .select in an O(N) context)
- N+1 queries in databases
- Unnecessary sorting
- String concatenation in loops
Understand the why.
Benchmark early.

Conclusion

We're getting used to not understanding the code we write

AI promised to make us more productive. And it does. But productivity without understanding is technical debt with a smile.

AI is a powerful tool. But tools don't eliminate the need for craftsmanship. They amplify it.

So next time AI gives you 20 lines of working code — don't just run it. Read it. Understand it. Question it.

Because in the age of AI, code literacy is not optional — it's part of surviving in our industry.

I write about Ruby, Rails, and software development every Thursday. You can follow me at enderahmetyurt.com.

Accessing Values in a Hash with dig in Ruby: Differences and Alternatives

Ender Ahmet Yurt — Mon, 02 Dec 2024 13:34:05 +0000

Hello 👋

Ruby provides multiple ways to access Hash values. The dig method offers a safe approach for retrieving values from nested Hash or Array structures. Let's explore how dig works, along with its alternatives and key differences:

Using dig

The dig method lets you traverse nested structures by specifying a path of keys. Rather than raising an error when a key doesn't exist, it simply returns nil.

hash = { user: { profile: { name: "Ender", age: 38 } } }

# Accessing the 'name' value
hash.dig(:user, :profile, :name) # => "Ender"

# Invalid path
hash.dig(:user, :address, :city) # => nil

Benefits:

Safe: Avoids errors by returning nil if any key is missing.
Readable: Makes code cleaner when working with complex structures.

Alternatives

Chaining Keys

While you can chain keys directly to access a value, this approach is risky—it will raise a NoMethodError if any intermediate key is nil.

hash = { user: { profile: { name: "Ender", age: 38 } } }

# Accessing the 'name' value
hash[:user][:profile][:name] # => "Ender"

# Invalid path
hash[:user][:address][:city] # => Error: undefined method `[]' for nil:NilClass

Difference:

Unlike dig, chaining keys can result in errors if the path is invalid.

Using Safe Navigation Operator (&.)

The safe navigation operator (&.), introduced in Ruby 2.3, lets you chain method calls safely by returning nil when encountering a nil value instead of raising an error.

hash = { user: { profile: { name: "Ender", age: 38 } } }

# Accessing the 'name' value
hash[:user]&.dig(:profile, :name) # => "Ender"

# Invalid path
hash[:user]&.dig(:address, :city) # => nil

Difference:

A more modern approach that can be combined with dig for added flexibility.

Using fetch

The fetch method retrieves a value for a given key and raises an error if the key doesn't exist. You can handle missing keys by providing either a default value or a block.

hash = { user: { profile: { name: "Ender", age: 38 } } }

# Accessing the 'name' value
hash[:user][:profile].fetch(:name, "Default Name") # => "Ender"

# Missing key with default value
hash[:user][:profile].fetch(:address, "Unknown") # => "Unknown"

Difference:

fetch can provide a default value for missing keys, but it must be called at each level of a nested structure.

Deep Search with each_with_object

To search for a key nested deep within a structure, you can use specialized methods like each_with_object.

hash = { user: { profile: { name: "Ender", age: 38 } } }

def deep_search(hash, key)
  hash.each_with_object(nil) do |(k, v), result|
    if k == key
      return v
    elsif v.is_a?(Hash)
      result = deep_search(v, key)
      return result if result
    end
  end
end

deep_search(hash, :name) # => "Ender"
deep_search(hash, :age) # => 38

Difference:

Useful for deep searches but more complex and computationally expensive.

Conclusion: Which Method to Use?

If safety and readability are your primary concerns when working with nested data structures, consider using the built-in dig method, which gracefully handles nil values and provides a clear, chainable syntax.
When dealing with flat Hash structures that have a simple, single-level organization, direct key chaining using square bracket notation or dot syntax proves to be the most straightforward and effective approach for accessing values.
In scenarios where you need to handle default values or implement robust error handling mechanisms, the fetch method offers comprehensive options for specifying fallback values and custom error messages when keys are not found.
For situations involving complex searches through deeply nested data structures with multiple levels, leverage powerful enumerable methods like each_with_object to efficiently traverse and transform the data while maintaining clean, maintainable code.

❤️

^{Note: I got help by AI for improving English of that post and examples.}

Intern Programs in 2024

Ender Ahmet Yurt — Thu, 04 Apr 2024 11:09:00 +0000

With summer coming, many new developers are looking for internships to start their tech career. We can create a detailed list of top internship programs to help them. These programs are great for beginners, providing tools and experiences to start their careers. The list will be available here for anyone interested. Let's support the new generation of developers! 🚀

You can add any intern programs you know of in the comments. 🥰

cover image: Photo by Ehud Neuhaus on Unsplash

Exploring the Latest Ruby News: March 2024 Roundup

Ender Ahmet Yurt — Fri, 29 Mar 2024 11:51:48 +0000

Hey Ruby enthusiasts! It's that time again where we dive into the latest happenings in Ruby community. From exciting new releases to insightful articles and events, there's plenty to catch up on. So, grab your favorite beverage and let's explore what's been going on in March 2024.

Conference Updates

EuroKo 2024: EuroKo is back with its 2024 edition! Dive into the world of Ruby with this year's conference featuring talks, workshops, and networking opportunities.
RailsConf 2024: If you missed RailsConf, fret not! Follow the highlights and updates on Twitter.

Frameworks and Tools

Hanami 2.1.0 Release: Hanami, the alternative web framework, unveils its new version packed with enhancements and improvements.
Solid Queue: Explore how to migrate to Solid Queue from Sidekiq with this insightful blog post.
ActiveType: Discover ActiveType, a library for creating form and view models in Rails applications.
Ferrum: Check out Ferrum, a high-level browser automation library for Ruby.

Articles and Tutorials

Why I Love Ruby: Vlad shares his love for Ruby and what makes it a favorite among developers.
Frozen String Literal: Understand the significance of frozen string literals in Ruby and how they impact performance.
VSCode + WSL: Learn how VSCode with WSL is transforming Windows into a powerful platform for web development.
Micro-benchmarking Value Objects in Ruby: Dive into the world of micro-benchmarking and explore the performance of value objects in Ruby.
Thruster Released: Get insights into Thruster, a new tool released by 37Signals for enhancing web performance.

Events and Community

Ruby Türkiye Meetup 2024#03: Join Ruby meetups and connect with fellow enthusiasts to discuss all things Ruby. It's in Turkish.
Why Should Developers Write?: Explore the importance of writing for developers and how it can benefit your career.
RailsConf Behind the Scenes: Meet Ufuk, the secret organizer behind RailsConf 2024, and get a glimpse behind the scenes.

Miscellaneous

New Rails Template: Check out the latest Rails new template for starting new projects with ease.
Allow Browser to Set Minimum Versions: Learn about the new feature in Rails 8 that allows browsers to set minimum versions.
History of the Endless Method Syntax: Delve into the history behind Ruby's endless method syntax and its evolution over time.
Schedule for RailsConf 2024: Check out the schedule for RubyCentral events and plan your participation.

That's a wrap for March 2024 in the Ruby and Rails world. Stay tuned for more exciting updates, releases, and events in the coming months. Happy coding! 🚀

What's your the weirdest Ruby Gem you have worked with?

Ender Ahmet Yurt — Wed, 24 Mar 2021 09:42:10 +0000

Hello,

Ruby gems are cool and powerful but some of them could be weird. What's yours?

Cheers.

Why do you follow a person on Github?

Ender Ahmet Yurt — Fri, 02 Nov 2018 08:32:05 +0000

I follow 137 people on Github. I follow some of them because of just my friend. They can be a really good developer but some followings don't push any code to Github for a while. I just worry why we follow a person on Github? What are your reasons? Why should we follow a person who hasn't any activities on Github?

being your friend
being your colleague
being a really good developer
being a good open source develop
being a famous guy like a big tech company CTO or etc
...

The other point, I can ask, why do you push the unfollow button? That can be the second question. Actually, two questions are related to each other.

Cheers.

What are your criteria for staring a Github repo?

Ender Ahmet Yurt — Thu, 18 Oct 2018 09:21:29 +0000

Hi,

I just wonder how you can you decide to star a Github repo. Nowadays, we star the repos that show up on our Github dashboard.

Cheers.