this post was submitted on 17 Mar 2026
0 points (NaN% liked)

No Stupid Questions (Developer Edition)

1139 readers
3 users here now

This is a place where you can ask any programming / topic related to the instance questions you want!

For a more general version of this concept check out !nostupidquestions@lemmy.world

Icon base by Lorc under CC BY 3.0 with modifications to add a gradient

founded 3 years ago
MODERATORS
 

Recently went down a familiar rabbit hole while building a REST API for a simple task tracker. It started off clean just a few basic CRUD endpoints. Nothing fancy. Then, like always, I thought… “what if this scales?”

That’s where things went sideways.

I added nested routes, polymorphic relationships, custom middleware for edge cases I hadn’t even seen yet, and somehow convinced myself I needed event sourcing. For a task tracker. With zero users.

Two weeks later, I had something that looked impressive on paper but was painful in reality. Deployments were messy, debugging took forever, and performance? It struggled with even 10 concurrent users.

That’s when it clicked, I wasn’t building for real problems. I was building for imaginary ones.

So I stripped everything back.

I kept the API simple, clear endpoints, straightforward DTOs, basic validation using Zod, and plain Postgres queries. No magic. No overthinking.

The result? Everything got better. Performance jumped, tests became easy to write, and for the first time in days, I actually enjoyed working on it again.

The big lesson: YAGNI is real. You really aren’t gonna need it at least not yet.

Now I try to follow a simple approach:

Build the simplest version that works and Only optimize when something actually breaks

So tell me.. have you ever done this too? Like overbuilt something and then regretted it?

top 4 comments
sorted by: hot top controversial new old
[–] JakenVeina@midwest.social 0 points 6 months ago* (last edited 6 months ago) (2 children)

Planning for the future doesn't mean getting the architecture right the first time, it just means being modular/layered, in such a way that you CAN refactor later, without having to rewrite the whole app from scratch. Which admittedly isn't obvious to solve, without experience under your velt.

[–] chickenf622@sh.itjust.works 0 points 6 months ago

This plus "keep it simple stupid" are 2 key things to keep in mind when writing a program. Going back to old code of mine can be painful when I didn't keep these key principals in mind/was too inexperienced.

[–] jackevans@programming.dev 0 points 6 months ago

Agree with the emphasis on modularity upfront, as it aligns with my YAGNI takeaway, start simple but layer cleanly for future refactors without a full rewrite. In my case, zero users meant no pressure for premature complexity, letting me ship fast and iterate based on actual needs. Experience definitely sharpens that balance. What's one modular pattern you'd recommend for a basic CRUD API?

[–] cows_are_underrated@feddit.org 0 points 6 months ago

Recently was tasked with building an interface to manipulate and work with a CSV file in bash. The interface would only be used by other programs and not a human user (although you could use it AS A human). Guess who coded an entire system do detect if a line in the file is broken and it even tries to recover the old data of the line to reset it. Will this ever be needs? Probably not except if some weird bitflips occur. Would it bite me in the ass if I didnt have it? Probably also no, because AS ling AS it does not happen on a regular basis the impact would be quite small, but impossible to track down without manually checking the entries.

I did not regret over engineering it (especially since it meant that I got way better at coding bash) and it did not change debugging/usage in any meaningful way. It would have saved me about 2 days or so if I wouldn't have done it, but now I'm glad I have it, because now it will probably be very hard to break this system.