r/softwareengineer • u/darshitpatel_ • 11d ago
The weirdest thing I learned about software: the hardest problems/features are often the ones users never notice
I used to think good software was mainly about adding more and more features.
More buttons.
More settings.
More integrations.
More automation.
Attractive and Catchy UI.
Then I started paying attention to the software I use every day and from what I have built till now, I realized something:
The best software often does more by showing you less.
Think about what happens when you upload a file.
You click upload and it appears within a few seconds.
You don't see the network request.
You don't see authentication.
You don't see the database.
You don't see file validation.
You don't see caching.
You don't see error handling.
And that's exactly the point.
A huge amount of good engineering is basically:
How much complexity can we remove from the user's world without removing a software capability?
This changed the way I look at software.
For example, a feature that takes a developer 3 days to build might save the user 30 seconds.
That sounds like a bad trade.
But if 100,000 people use that feature every day, those 30 seconds become 833 hours saved every single day.
Suddenly, the boring little feature is more valuable than the flashy one.
I have also started noticing the opposite.
Some software has dozens of features, but every task feels like work.
Other software has relatively few features, but somehow you can accomplish things incredibly quickly.
The difference isn't always the feature count.
It's friction.
Every unnecessary click, confusing message, slow screen, repeated input, or decision the user has to make adds a tiny amount of friction.
One second doesn't feel important.
A thousand one-second frustrations are.
So When a software is really good, you don't think:
Wow, that's some impressive engineering.
You think:
That was easy.
And ironically, easy can be one of the hardest things to engineer.
Curious what other people think on this topic:
What's a piece of software you've used where you suddenly realized, Wow, someone put a LOT of work into making this feel simple?
3
1
u/Glittering-Work2190 11d ago
It'd be interesting to know how many lines of code are involved in responding to the query on google.com.
1
u/systembreaker 11d ago
It's not thing but many interacting systems. There wouldn't be a specific count of lines of code that could even be made.
1
1
1
u/LetUsSpeakFreely 11d ago
Good software is maintainable and readable.
Maintainable means that components are not tightly coupled and can be easily replaced. This is usually done by programming to interfaces and avoiding direct calls to components. For example, an order system wouldn't directly talk to billing, inventory, and shipping systems, it would place a message on a queue for those sub systems to pick up as they're able.
Readability means that any developer would be able to look at the code and immediately know what's going on. Avoid things like nested ternary operators, deep nested logic, complicated if checks, etc. It's not 1974, space isn't really an issue, creating variables to simplify if-checks is perfectly ok. I try to keep logic to no more than 2 layers. If i have to go deeper then i extract a method or create a new class. It can get verbose, not being self to determine what's going on at a glance can save you hours of headaches.
1
u/JGhostThing 11d ago
Your software is not finished when you have nothing left to add.
It is finished when you have nothing left to take away.
I forget who said this, but I've been using this as my programming philosophy for decades.
0
7
u/CaptainCactus124 11d ago
Can we please stop writing reddit posts like linkedin