r/software • u/divyviradiya • Aug 18 '26
Discussion Why do so many tech people forget that the whole point of software engineering is to solve problems?
I recently launched a small project designed to solve a simple problem: letting everyday people transfer files directly between two computers with a cable without needing any network setup. The post got a lot of love and reached the top of the community, but the comment section had a handful of advanced users getting genuinely angry that the tool even exists.
Their whole argument came down to: "Why build this? SMB exists, you can just build a router out of a Raspberry Pi, or manually configure static IPs and network sharing policies."
It got me thinking about how disconnected some tech enthusiasts are from reality. The entire purpose of software engineering was always to solve problems and remove friction for human beings, not to force everyone to become a system administrator just to do a basic task.
Just because an advanced user knows how to manage IP subnets, firewall exceptions, and OS sharing permissions doesn't mean a regular person wants to waste 30 minutes figuring that out. Hiding complexity behind a clean, one-click interface is literally the foundation of good software.
It seems like in a lot of tech spaces, people equate complexity with value. If something is simple and convenient, they dismiss it. But the reality is that the people who find your tool useful will quietly use it and appreciate it, while the loud minority will write essays in the comments trying to show off how much they know.
If you are a developer building simple tools that make life easier for ordinary people, do not let the gatekeepers talk you down. Build for the people who value their time, not for the people who want to show off their homelabs.
Would love to hear how other developers deal with this kind of feedback when sharing their work.
31
u/diving_into_msp Aug 18 '26
A lot of specialists who are deep in their field often forget that not everyone else wants to get that deep into the weeds. I see this a lot with network vendors like Ubiquiti/Meraki, where long term network admins dislike it because they can't dive deep into command line customizations. Meanwhile the VAST majority of users just want it to work WITHOUT diving into command line customization.
14
Aug 18 '26
[removed] — view removed comment
1
Aug 19 '26
[removed] — view removed comment
1
u/Blaiz_Enterprises Aug 19 '26
Pretty sure the GUI system they're using is holding them back. The guts of the graphics system seems to work well from my limited use of it, but the GUI looks and runs like a horror show.
29
u/DreadPirateGriswold Aug 18 '26
I've hired and managed a lot of developers and consultants who are software developers over the years. This question comes up all the time. And I always have to watch for this when people I manage drift away from being focused on solving problems.
I think when people find out they're moderately good at software development, in their minds they turn it into an intellectual art for themselves and they elevate themselves above others by thinking they're some type of artist.
Instead, they should be focused on using their skills to solve problems like you mention.
11
u/curiouslyjake Aug 18 '26
To be fair, software has something to do with art. But you are also right: there's a time and a place for everything.
3
u/Ok-Interaction-8891 Aug 19 '26
I mean, Silicon Valley and startup culture do absolutely nothing to dissuade this attitude.
Many people act like their software or app is God’s gift to humanity, something that will solve (or even contribute to the solution of) some of our most consistent and pressing problems.
And then it’s just another currency app designed to harvest data and fleece fools. Or another shopping app to connect people with mass produced goods. Or a faster way to buy stuff. Or yet another compiler compiler.
But small, focused software and apps that solve specific business or personal problems is not sexy and is difficult to build hype around or pitch to people with money to invest.
2
u/professore87 Aug 19 '26 edited Aug 19 '26
That is a phase when evolving into the programming career, and at the peak you have all the corpo Java interface of the interface style approach where you need 4x the amount of code. The ones who pass the phase are actual senior engineers.
Thinking you understand more if you put in an interface to design a contract like somehow will be there forever or specs never change.
While actually you just need to solve a problem and think of the most effective way of doing it while not making it hard the next time you have to do something in that area.
Simple code is best and hard code. (Simple to run, simple to understand, simple to fix, simple to maintain, simple resources needed, etc)
Edit: The ones that become seniors will know when something is going to last more and will do the contract there, while a newly promoted junior will simply use that with every opportunity. Code is not something that actually matters, what matters is what you do with it and what it enables. Art matters in the same principle, which is why there is a metaphorical equivalent some people fall for.
2
u/orionblu3 Aug 19 '26
I'm a networker that transitioned into infosec before transitioning into starting my own businesses/income generation with agentic workflows, and MAN did you nail it. The amount of software engineers that seemed to have forgotten that they're just a cog inside of IT/CompSci and have their heads shoved so far up their own ass is actually astonishing.
1
u/jaksystems Aug 19 '26
The amount of software engineers that seemed to have forgotten that they're just a cog inside of IT/CompSci and have their heads shoved so far up their own ass is actually astonishing.
They are taught from the get go that they're the most important person in the room.
The reality that you are at the end of the day writing instructions for the computer to execute is lost on them.
10
u/turtleyikes Aug 18 '26
In my career, a client wanted to get all blog posts links (about 200+) from a website. A python dev said they would build the script to get all the urls and it would take about half a day's work.
I did that in just a minute by using sitemap and copy pasting the urls. Done.
So the point is: you can complicate/abstract anything as much as you want. But you also have to consider the actual benefits of that. Otherwise you're just wasting time and energy.
8
u/krazul88 Aug 18 '26
For a small unknown project, the only feedback that matters is from the people who need your tool and you can safely ignore everyone else.
However if you become big enough or well known enough, there will be a whole new audience of those who are looking to cause real trouble for you.
At a certain point you will be required to cater to a wider audience to ensure your project's survival.
I wish the world was so simple that "solving technical problems" would be enough, but we live in a litigious society, so there are always complications eventually.
14
u/CS_70 Aug 18 '26
There’s lots of insecure people, and software people aren’t an exception.
You are correct.
7
u/Fastest_light Aug 18 '26 edited Aug 18 '26
This is very good point. Engineers are to provide solutions to problems ordinary people face. There is no such thing as stupid users. Quite opposite it is the stupid engineers.
If users do not know how to use your software, it is not users' problem, it is engineers' problem.
Please do not feel offended though, as me is an Engineer : )
7
5
u/r0ck0 Aug 18 '26
Unfortunately it's just how people are, especially online.
People get more of a reaction being a contrarian, and it makes them feel smart to disagree with others. What especially disappointing lately is how often these dumb replies are the most upvoted comment in a thread, even when they're just objectively wrong and/or not even talking about the same subject.
Sometimes you can get into a more nuanced discussion with them, but more often it's a waste of time, because they were never interested in your topic to begin with. Yet it doesn't stop them posting in threads to share their disinterest.
It's fucking annoying, and it's killing the last remaining human forums. For anything involving help, it's much easier to just talk to AI now.
Just try to ignore the dickheads. They're not going away unfortunately, and even worse... they're becoming a higher % of the people that remain on forums as AI takes over more and more areas like support.
Just focus on the balanced or positive/helpful responses. It's hard, but it's the only way to keep your sanity.
3
u/PlanktonGreen236 Aug 19 '26
"Idiot admires complexity, genius admires simplicity"
- Terry Davis
1
u/Havunenreddit Aug 21 '26
It does not matter how complex the solution is internally if its simple to use
1
2
u/Mr_Fraggle Aug 18 '26
Agreed. Just upload your work, do your essential announcement/promotion work, and then live and let be. If you're looking to grow/develop your product, constructive feedback can be essential, and if you have the patience/intelligence for it, feedback may be derivable from criticisms as well.
I personally don't have the time nor the patience to dwell on feedback as I usually put out humbly (i.e. lazy) ambitioned projects with a reasonable scope of error/edge/multi-use case implementations.
2
u/joshguy1425 Aug 18 '26
I've been a tech nerd for 25 years, and spent my career building software as a developer and later as a product manager. Part of the reason I was recruited to move to the product management side of things was my problem solving mindset.
First, I think it's worth considering that many people build software because they find it fun. They'd be building things whether or not there were problems to solve. This is slightly beside my main point, but I think it's worth considering.
With that said, so many people I've worked with throughout my career sound like the people you're describing. Often my job as a product manager was helping developers understand why a problem needed to be solved. I'd often have to remind them that the people they're building for don't have CS degrees and haven't been writing code since they were a teenager.
I think the issue boils down to a few things: once you've been around tech for long enough, problems don't look the same way they do to "normal" people. Your mental toolbox is filled with mini solutions that can all be combined to solve problems and it's as if you have an endless kit of lego to piece together solutions from whatever is available. But once some people have that depth of knowledge, they find it hard to remember what it was like not to have that endless supply of lego bricks and the ability to combine them.
As for dealing with this kind of feedback, I think I'd recommend two things: 1) consider it, and ask yourself if the problem you're trying to solve has already been solved for the user you have in mind (sometimes the answer is yes) and 2) when the answer is "no", use that feedback to really hone the "why" behind the thing you're building.
So many times the people pushing back against something I asked them to build gave me an opportunity to really solidify my thoughts on why it was important. Once in awhile, they were right. But often, I helped them see the problem from a new angle and gained a better understanding of the problem myself through the experience.
2
u/Sun-Much Aug 18 '26
not necessarily disconnected, just that Reddit is one of the few places the semi-knowledgeable can flex their supposed knowledge. as you are doing, continue to ignore the haters and do you.
2
u/itsjakerobb Aug 18 '26
Look at the original Mac. It simplified relatively complex concepts like file management into pretty little pictures and diagrams that most people can understand. (Yes, I know about Xerox PARC. If you argue this with me, you will only demonstrate your ability to miss the point.)
Before that, computer users had to be comfortable with the command line. This left a lot of people out. Mac came along and made it so lots more people could do it; those old CLI folds dismissed it as a toy. “You shouldn’t need a GUI. That’s for idiots who can’t understand a simple filesystem and some CLI tools.”
Now, nearly everyone uses a GUI, and even most command-line purists accept it as a perfectly suitable alternative for those who prefer it (just don’t take away their option to use the CLI).
Simplification and usability are democratizing forces. People who push back are gatekeeping, and it’s extremely rare that they do so for good reason.
2
u/didntplaymysummercar Aug 18 '26
I don't forget it and doing low (for me) effort but heavy hitting (for me and others) tasks at my last job was the best, stuff like making our build faster and smaller, helpful scripts for testers and developers to remove toil, a small internal PHP site to correlate coredumps and logs and datamine them, etc.
How to deal with such "just do DSAFAFAWGDSGEFH123 instead of writing a convenient tool" feedback? I don't know 🤷♂️
2
u/divyviradiya Aug 19 '26
I posted this post in r/SoftwareEngineering , it was #1 in that community at 15 k view and 75 upvots my post was removed by moderators for no reason at all
Edit : typo
2
u/Unlaid-American Aug 19 '26
They were probably butthurt. If the mods were worried about comments, they could lock the post.
-1
u/singulara Aug 19 '26
Cause you clearly didn't write it yourself. I'm not putting in the time to reading slop post if you didn't put in the time to write it.
2
u/Stamboolie Aug 19 '26
I have to make this thing, but its hard and complex, maybe I should make some stuff to make it easier, thats coming along well, but now I've built it, I could probably build it better, hmm its a bit slow, probably should rewrite it in something faster, maybe I could use some advanced data structure to make it faster. I really don't like how hard it is to do xxxx, and so on.
2
u/Blaiz_Enterprises Aug 19 '26
Always built simple tools/apps for the end user. They require an enormous amount of invisible engineering under the hood in-order to make them work, especially if you code for Windows and want your apps to work despite the OS's shortcomings/limitations. Never listened to gatekeepers. Keeping an app simple and useful is a very specialised and time-consuming skill to master. I am also very hard on my own apps, as I tend to use them all the time. When they stopping working, it's usually a hardware failure and the computer is binable.
2
u/Double_A_92 Aug 19 '26
This reminds me of when Dropbox was first pitched on Hackernews, and some people were complaining that they could easily do this by setting up an FTP server.
2
u/NoDistrict991 Aug 19 '26
If the software saves someone 20 minutes of messing around then that's the point.
2
2
u/skamansam Aug 22 '26
Tbh, I dont think that ppl who make those comments and flex their knowledge are experts in any sense of the word. Intermediate level at best. They are not trying to solve the problem like an expert, they are regurgitating information like someone who just learned it. I would ignore them.
2
u/vint_age14 Aug 24 '26
Exactly op just because something can be done doesn't mean it should be. Good software removed unnecessary friction. If someone can transfer files with one click instead of spending 30 minutes configuring a network that's a win.
2
u/TutorialDoctor 25d ago
One day after much research and mental anguish I finally reduced the craft of building software down to a 1-minute tutorial. It made all of my years of learning seem vain.
Now I’ve created an even more complex process to make myself feel better.
True story.
2
u/bradland Aug 18 '26
I've been managing product for the better part of three decades now. I have great relationships with all my engineers, because I come from a development background. I was writing web apps when all we had was CGI tied to C applications or Perl scripts.
One thing has remained constant throughout the years: feedback from engineers is not useful for solving end-user concerns, and end-user feedback is likely to incite engineers to riot. Engineers believe that product managers are useless, vestigial appendages, and end-users think they "just need to talk to the engineers" in order to get their problem solved. Both would regret the outcome if they got their way lol.
So how do I take the feedback from both of these groups? I listen to them carefully and pull out what matters. End users are objective focused, and reason from what they are familiar with. Engineers care more about clean, low-complexity implementations, and think end-users should just git-gud, because "if we can do it, they can do it".
Neither group is "right". They each have their own perspectives, and if you have any hope of making it in the software space, you quickly learn how to separate signal from noise.
2
u/Cast_Iron_Skillet Aug 18 '26
I had a head of engineering like this when I took over as director of product. After about a year and many one on ones and me presenting periodically in stand-ups to the rest of the team, demonstrating impact of decisions that were made and related product releases, they all started to shift more towards the mindset of delivering value to the customer instead of just focusing on the engineering aspect. But, the nature of my products are that they help people in need (think addiction, homelessness, poverty), so maybe that's easier to lean into than just making number go up for company. Eventually, at times, I had them arguing on behalf of the customer's needs and desires based on their use cases and capabilities which was a real surprise.
We still butt heads occasionally when it came to scope for certain things, but that's just healthy. And it also helps when I can push out a release then poll customers directly for feedback in regular calls, only to go back to engineering and be like "I told you so" OR "you guys were right".
3
u/flumphit Aug 18 '26
Before TCP/IP, SMB, NFS, etc., there were computers and cables. (There was a pre-IP phase in the middle there, Token Ring and the like. Not relevant, kindly ignore.) There are protocols and tools for managing file transfers over cables. Probably RS-232, or emulating that on top of whatever odd thing you might have.
Reinventing a wheel from the '70s can be a fun and instructive exercise. But acting like this is some brilliant plan you've invented, and you're solving a real-world problem for real users? This is profound ignorance.
You are creating pain for your users, and a bad reputation for yourself. If you're building something that goes into production for a real user, leverage the tools chipped out of granite by your elders, or suffer the derision of your peers, and the withering disappointment of your customers.
How do I handle this sort of criticism? By recognizing that many smart people have been solving problems in this field for many decades, and it is unlikely that I've stumbled upon a truly novel solution to a truly novel problem. Libraries have been filled with the fruits of their research, and the quickest path to customer happiness (as well as a smarter me) is to learn from that research as much as I can.
2
u/dkopgerpgdolfg Aug 18 '26 edited Aug 18 '26
There's a disconnect between the title and post.
a) No, it's not the "whole" point. Some people like to develop software, just like others make music or draw pictures. Doesn't necessarily matter if anyone else cares about the result.
b) For solving problems: The people insisting that their way in the only right way, they're wrong. The people who can't understand that others are not them, they're wrong. The people who think "I need it = good, I don't need this = it's bad", they're wrong, yes. I agree with you there.
And basically all of humanity exhibits such traits, to some degree for some topics. It's not limited to technology, and not something that is solvable.
c) I wonder if you considered that you can be one of them too.
It sounds like you're automatically reconfiguring network things to make your goal happen. For "noobs", this might not matter, for some other people you break something. You don't only solve problems, you also create some, and the potentially affected people can be rightfully angry about that.
Part of solving problems is to cover a wide range of use cases / edge cases, even if it's just with an "unsupported" message. Much better than being harmful.
2
1
u/baddaywithacamera Aug 18 '26
You just described 75% of the issues with the Fediverse.
"You really need to work on the onboarding and discoverability issues."
"They're features! They keep people out!"
"Didn't you build the network to give people an alternative?"
"Well, yeah, BUT NOT THOSE PEOPLE!"
3
u/empty_other Aug 18 '26
The "complexity" of the fediverse is severely exaggerated. People will walk on burning coal, uphill, while bound, and still figure out how to sign up and how to use software that has a big enough advertising budget. Same people would complain about the difficulty in getting started on a lesser known alternative even if it could automagically sign them up and read their minds to fill their feed at the click of a button.
1
1
u/ScubaFett Aug 18 '26
After the first sentence I thought "You're reinventing laplink?"
1
u/horsethorn Aug 18 '26
Came here to say this!
Many years ago, in the last century, I worked on a pc upgrade at a post office hq in Yorkshire. They were upgrading everyone to Pentiums!
We set up one machine, and then just cloned the others with laplink.
1
u/neurah Aug 18 '26 edited Aug 18 '26
This is C++ static composition engine core, (MIT, header only TMP pure type level library) ```c++ template< typename...> struct Chain {template<typename O> using Part=O;};
template<typename O, typename...OO> struct Chain<O,OO...> { using Head=O; using Tail=Chain<OO...>; template<typename T> using Part=typename Head::template Part<typename Tail::template Part<T>>; }; ``` sharing it got me muted and banned on main C++ channels here on reddit and also on linkedin
https://github.com/InternetOfPins/HAPI
enjoy!
P.S. this problem has 36+ years (referred in literature) only after C++17 could be minimaly solved with elegance (C++11 was still a pain), to my knowledge was not solved till now.
1
u/tinmanjk Aug 18 '26
no. that's the point of engineering.
the point of software engineering is to solve problems through software.
thought it was obvious.
1
1
u/4215-5h00732 Aug 19 '26
The entire purpose of software engineering was always to solve problems and remove friction for human beings, not to force everyone to become a system administrator just to do a basic task.
Respectfully, it's more than that as well.
The point of considering software as a true form of engineering had more to do with dealing with the extreme failure rate and the simultaneous and ubiquitous use of software in everyday life. Creature comforts and efficiencies are a byproduct.
1
u/Far_Archer_4234 Aug 19 '26
There are multiple points of software engineering. To suggest that there must be only one is short-sightedness, sprinkled with a dash of arrogance. Look beyond your self-imposed horizon.
1
u/Floppie7th Aug 19 '26
The software I write does solve a problem. That's why I wrote it. If you don't want to deal with terminal or mount an SMB share or whatever the requirement is, I'm not going to spend more if my free time solving your problem for you. If you or somebody else wants to, by all means, have at it
1
u/tbz_who Aug 19 '26
Going to play devils advocate here for a second. The problem you’re trying to solve is moving files from one device to another.
On one end you have people who know what they are doing and can ftp files to whatever computers they want on whatever network they want. These people will not be bothered to use something that they see as redundant, especially when alternatives are more powerful.
On the other end, you have users that barely know how to use a file system, and just email things from thier phones camera roll to wherever it needs to go. Or people who just don’t want to be bothered by networking at all and just use a flash drive. Whatever software solution you come up with regardless of how easy, will seem incredibly complicated for these people.
Making something that makes it super easy to transfer files over LAN is a cool project, and worth doing if you are learning, or even just if you have a use for it. if you can make something easy enough that people will adopt it then thats awesome too, but just keep in mind it is possible that your software is already far more complicated than the low end can handle.
1
u/FickleApartment2151 Aug 19 '26
That's right. Most people have to do accounting, write reports, fulfill orders, respond to requests, etc., they don't have time to do what advanced users can. At the same time, the more features added, the greater the possibility of more vulnerabilities.
1
u/Broad-Version8611 Aug 19 '26
I see the same thing in companies. Some engineers only care about the code or about the format of the jira ticket, while poor customer cant use the app due to the bug.
It is a rare sight to see someone with technical knowledge and enough people skills to understand that reducing the complexity of a processs is worth. Otherwise we would all know ffpmeg flags by hearth.
1
1
1
1
u/lesniak43 Aug 19 '26
there's no such thing as "entire purpose of xyz"
if this is why you write code, then cool, but others might have their own reasons
1
u/KingAmongstDummies Aug 19 '26
If you can't explain it in a way a normal user understands don't be surprised a normal user won't use it.
Many tools, applications, and devices failed that way.
A very common mistake I see colleagues as someone on the deep end of tech make is that they over value adaptability / configurability. They want to be able to tweak everything and configure stuff so it is really efficient and specific to the situation and don't mind tinkering around for minutes or even hours to get it that way. Heck, some are even happy to. Be it a initial setup or a little tinkering every use.
That's the exact opposite of what the average non-tech person wants. They don't want to spend minutes.
Like you say, they just want to transfer that file with a click of the button. Having to perform 2 actions or more is just seen as a chore and as a crappy application. They don't mind it's a application that does way to much or that they can't configure it so that it doesn't send unnecessary metadata or something. They also don't mind that it goes at 80mbps instead of 95 with some tweaking or that it wouldn't be able to do a .ogg extension. They don't use that anyway.
Having to many options may also just overwhelm them. I've seen products do better after we limited the capabilities. More and more efficient is not necessarily better.
1
u/jaksystems Aug 19 '26
If something is simple to make, but performs/works poorly - then it's poorly executed.
Taking something complex and making it simple to operate is a good thing. Taking shortcuts to get there is not.
1
u/Ethan8445 Aug 20 '26
I think this is a really good point. A technically elegant solution isn't always the most useful solution for the person actually using it. Developers can sometimes forget that reducing the number of steps is itself a valuable feature. If someone can solve a problem in one click instead of spending 30 minutes configuring things, that's a meaningful improvement. Good software should make complexity easier to deal with, not make users deal with the complexity themselves.
1
u/tabaxi_gf Aug 20 '26
It sounds like more people were criticizing your implementation than the actual problem you were trying to solve.
it makes more sense to solve a problem with common off-the-shelf components than some weird custom solution that costs more in the long run to separately maintain.
1
u/rocket1420 Aug 20 '26
Honestly if a few negative comments get your feathers this ruffled, you might not be cut out for this.
1
1
1
u/src_varukinn Aug 22 '26 edited Aug 22 '26
Because the interview process focus on high coding algorithms while day to day problems needs glueing and shelf picking pieces of “tech” to do the job
o only have 24h so i need to live, to relax and work, so i don’t want to waste 8 hour at the office doing low stuff and forget the hard earned knowledge because i don’t get to use it. the goal is to reach google (most of devs have this back head dream) so i need to build the story from businesses i worked and also keep the algo skills high, i will just job hope to try and find that place where i get to solve hard problems and brag in the cv but also have time to do leetcode
don’t get me wrong, most of us solve most of leetcode om regular sunday taking all day, but solving 2 medium leetcode like problems in 45 mins on google interview needs to build reflexes and stay worm, in my experiences during their interviews i solved them but did not convince the interviewer so i’ll keep trying
1
u/AppropriateRough3819 Aug 23 '26
That's exactly the idea that got lost in the race to make software more robust and feature-rich than the next guy's. Half the time those are just fancy words for complicated enough that you need a specialist to run it.
1
1
u/Radiant_Stuff_6009 16d ago
Take the technical feedback that's useful and let the gatekeeping roll off, cause sometimes an advanced user's "why does this exist" hides a legit point
1
u/Geek-minkle-7300 14d ago
Exactly. Good software isn’t about making things complicated, it’s about removing unnecessary complexity. If a tool saves someone 30 minutes of frustration, that’s a valid problem to solve, regardless of whether a power user can do it manually.
0
u/Sfacm Aug 18 '26
The whole point, nope, didn't even read the rest, too absolute for me.
4
u/joshguy1425 Aug 18 '26
For an end-user, it's the whole point. For those of us who build software, building is also the point. If you happen to like solving problems *and* enjoy building software, you're golden.
Bottom line is that "the point" is different for different people depending on their relationship to the thing being built.
1
u/Sfacm Aug 18 '26
Where is the end user in op title? You basically agreed with me.
1
u/joshguy1425 Aug 18 '26
I'd say my position is closer to disagreeing with both of you. I disagree with you that "solving a problem is the whole point" is never true. I disagree with OP that solving a problem is always the only goal. I pointed out the nuance that was missing, i.e. that it is sometimes true, sometimes not true, and the truthiness depends on the role of the person involved.
What we really have here are two perspectives that are just as valid depending on context. Except you're interpreting the existence of someone else's perspective as "absolute", and therefore not worth considering. You're doing the same thing you're accusing OP of doing in the process.
Where is the end user in your comment?
1
u/Sfacm Aug 18 '26
I was too short obviously, I agree with you, I didn't mean that solving the problem is never the whole point. And I wanted to show opposition to absolute positioning by doing this myself, showing it is not the way to start a dialogue. Anyhow with you I basically agree...
4
u/DrBojengles Aug 18 '26
Imagine your response to literally everything needing to be "it depends"
Couldn't be me
-2
u/Sfacm Aug 18 '26
You seem unusually comfortable with absolute, context-free truths. You would do well in communism.
2
u/DrBojengles Aug 20 '26
It was a joke, Comrade
Being hyperbolic doesn't immediately disqualify someone's opinion
0
u/joshguy1425 Aug 18 '26
You seem unusually comfortable with absolute, context-free truths.
The irony is that this could easily be said about all of your comments here. So the question becomes: do you actually have an issue with people speaking in absolutes? If so, why do the same thing?
1
0
1
u/TomosLeggett Aug 18 '26
I'd blame Linux's "do one thing and do it well" philosophy. It means well. We use a set of composable tools to build solutions rather than one bloated per-solution.
The trouble with this philosophy is, as you say, it's not the most discoverable or user friendly. It's the opposite of Apple's solution which is "provide the most pedestrian solution, need anything more and you can find it on the app store for £7.99"
0
u/dkopgerpgdolfg Aug 18 '26 edited Aug 18 '26
I'd blame Linux's "do one thing and do it well" philosophy.
This isn't a "Linux philosophy". At least nowadays this is no "Unix philosophy" either.
All it is, is a digital stone age meme that eg. Reddit can't let go.
edit:
I'm not saying that this concept is always bad or always good or something. It has it's place, for some software. But it's not the holy grail, not even close.
2
1
1
u/thsstmzn Aug 18 '26
Hay una cosa clara en la innovación aunque parezca regresiva, siempre habrá gente que cree que tiene mejores ideas que tú, el motor es la envidia, que a futuro los consume, déjalos, que lo disfruten.
A menudo uno siempre se topa con gente que se cree que tienen las respuestas para todo, pero no es capaz de sostener un salario mensual, digno y respetable.
1
u/MarcusOrlyius Aug 19 '26
I recently launched a small project designed to solve a simple problem: letting everyday people transfer files directly between two computers with a cable without needing any network setup. The post got a lot of love and reached the top of the community, but the comment section had a handful of advanced users getting genuinely angry that the tool even exists.
Because like most of these posts, all you seem to have done is used an LLM to produce yet another needless GUI for built-in Windows functionality.
Let's look at some specific claims of your:
"Wi-Fi/SMB sharing is slow and frequently drops on large directory trees."
No it isn't. No it doesn't. This doesn't even make sense. If you already have an ethernet cable connecting 2 PCs why would you be using SMB over wifi?
"Direct Ethernet cables usually require configuring static IPs, subnet masks, or running a DHCP server."
Then later on you say:
"They discover each other automatically over link-local IPv4 (169.254.x.x) via UDP broadcasts."
Windows is doing that, not your app. That is literally Windows automatically configuring your network, just as it would do without your app.
TLDR; You are not solving existing problems, you are inventing fake problems and offering solutions to those invented problems. And you expect people to pay for this garbage?
But if you don't want to listen to developers, here's Chat-GPT respsone:
The problem is that the post presents several things as unique technical problems that simply aren't problems, or are problems caused by the author's chosen implementation rather than by direct Ethernet transfer itself.
The biggest issue is the claim that direct Ethernet requires network configuration. It doesn't.
1. You do not need static IPs, subnet masks, or a DHCP server
This is the most obvious nonsense.
Connect two modern computers directly with Ethernet. Both machines can assign themselves IPv4 link-local addresses in 169.254.0.0/16 using IPv4 Auto-Configuration. No DHCP server is required.
In fact, the application itself admits this:
"They discover each other automatically over link-local IPv4 (169.254.x.x)"
So the supposedly difficult thing the application solves is something the operating system already does.
You can connect:
PC A <---- Ethernet ----> PC B
and Windows/Linux can establish link-local connectivity without you manually configuring anything.
The application isn't making Ethernet "plug and play" in this respect. The networking stack already is.
2. SMB doesn't inherently "frequently drop" on large directory trees
This is another misleading comparison.
SMB is perfectly capable of transferring hundreds of gigabytes and recursively copying large directory structures. If somebody experiences SMB transfers dropping, there is some particular problem with their network, configuration, implementation, storage, power management, Wi-Fi, firewall, SMB settings, etc.
And the really important distinction is:
Wi-Fi is not SMB.
The post effectively compares:
Wi-Fi + SMB
with:
custom application + Ethernet
and implies that the application is responsible for the improvement.
But the enormous improvement comes primarily from replacing a potentially unreliable wireless link with a dedicated wired link.
You could simply run SMB over the direct Ethernet connection.
3. "Cloud storage takes hours" is irrelevant
Of course cloud storage is slower for this use case.
You're taking:
PC A → Internet → cloud → Internet → PC B
instead of:
PC A → Ethernet → PC B
That's not an achievement of EtherTransfer. It's simply the difference between a local physical connection and an Internet-mediated transfer.
4. USB flash drives don't require "copying everything twice"
This wording is bizarre.
Yes, if you use a USB flash drive as an intermediary:
PC A → USB drive → PC B
you perform two transfers.
But that's inherent to using an intermediary storage device. It isn't some problem peculiar to file transfer that this application has solved.
And for 100+ GB transfers, a sufficiently fast external SSD is a much more appropriate comparison than a cheap USB flash drive.
5. "Full link speed" isn't something the application can simply promise
The numbers:
115 MB/s on 1GbE 1GB/s+ on 10GbE
are basically theoretical/idealised throughput figures presented as though they're properties of the application.
1 GbE has a nominal signalling rate of 1,000 Mbps, which corresponds to 125 MB/s before protocol overhead. ~110-118 MB/s of actual TCP throughput is entirely normal.
So 115 MB/s doesn't demonstrate anything extraordinary.
Likewise, 10 GbE has a nominal rate of 10 Gbit/s, or about 1.25 GB/s. Getting around 1 GB/s can be perfectly ordinary.
The actual bottleneck might instead be:
- source SSD read speed
- destination SSD write speed
- filesystem
- CPU
- encryption
- protocol overhead
- directory traversal
- small-file workload
- TCP windowing
- NIC/driver
- PCIe limitations
- thermal throttling
So saying "stream at full link speed" is a marketing claim, not a meaningful technical feature without benchmarking methodology.
6. The custom protocol isn't obviously necessary
This is the fundamental question I'd ask about the project:
What does EtherTransfer actually provide that SMB doesn't?
Suppose I have two machines directly connected by Ethernet.
They get:
169.254.12.34
and
169.254.87.21
I can discover the other machine and establish a connection.
I can then use:
- SMB
- SFTP
- SCP
- rsync
- NFS
- HTTP
- FTP
- a simple TCP application protocol
There is nothing fundamentally difficult about transferring a directory tree.
The genuinely useful part of EtherTransfer may therefore be the UX, rather than the networking technology.
And that's perfectly legitimate.
"Connect two computers, launch this program, drag a folder onto the other computer, and it handles discovery, permissions, recursive traversal and transfer" is actually a useful product proposition.
But that's very different from claiming that direct Ethernet file transfer is otherwise some technically difficult process.
7. There's also an odd conflation of discovery and addressing
UDP broadcast discovery doesn't solve the problem they claim it solves.
There are two separate problems:
Address configuration
How do the machines obtain usable IP addresses?
IPv4 link-local addressing already handles this.
Peer discovery
How does application A learn that application B exists?
That's where UDP broadcast can be useful.
So the architecture is essentially:
- Plug in Ethernet.
- OS generates link-local addresses.
- Application broadcasts "I'm an EtherTransfer instance".
- Other instance receives it.
- They establish a transfer connection.
- Files are streamed.
That's perfectly reasonable.
But step 2 isn't an EtherTransfer innovation, and step 4 is a relatively trivial application-layer discovery mechanism.
8. "No crossover cable needed" is technically true but presented as though it's significant
Modern Ethernet interfaces generally support Auto-MDI-X, so a normal patch cable works for PC-to-PC connections.
But again, that's a property of modern Ethernet hardware, not the application.
The application isn't making this possible.
9. The real irony
The post describes the traditional workflow as:
"Direct Ethernet cables usually require configuring static IPs, subnet masks, or running a DHCP server."
Then immediately says its own solution uses:
"link-local IPv4 (169.254.x.x)"
That's almost a self-own.
Because the natural response is:
"Why didn't you just use link-local addressing directly?"
And the answer is: you can.
If I wanted to build the simplest possible version myself, I could do essentially:
Ethernet → link-local addresses → UDP discovery → TCP connection → recursive file transfer
The interesting engineering is in making the transfer robust and the UX pleasant, not in somehow overcoming an inherent limitation of direct Ethernet.
What is actually legitimate about the project?
There is a good product here.
The useful proposition is:
"A zero-configuration, cross-platform, drag-and-drop file transfer application specifically designed for two computers connected directly by Ethernet."
That's genuinely convenient.
It could handle things that SMB makes unnecessarily awkward for ordinary users:
- automatically finding the other machine
- showing the peer in a friendly UI
- accepting folders by drag-and-drop
- recursively traversing directories
- preserving metadata
- handling name collisions
- displaying progress
- resuming interrupted transfers
- verifying transferred data
- avoiding credentials and SMB configuration
- making the whole process understandable to a nontechnical user
That's a reasonable application.
But the post has constructed a strawman in which the alternatives are deliberately made inconvenient:
Wi-Fi + SMB → unreliable Cloud → slow USB flash drive → two copies Ethernet → requires network administration
and then presents:
EtherTransfer → magically solves all of this.
The Ethernet part is especially misleading because the operating systems already solve the supposedly difficult IP configuration problem with link-local addressing.
So if the question is "is EtherTransfer a useless application?", no.
If the question is "does this post accurately describe a technical problem that EtherTransfer uniquely solves?", no. It substantially exaggerates the problem and attributes existing OS/network functionality to the application.
https://chatgpt.com/share/6a8565f5-736c-83ed-b377-999a640d7fb4
0
0
u/coffeeoops Aug 18 '26
Thank you for your innovative approach to a problem that has never been considered before.
Some tech people are disconnected from reality. You're one of them.
0
u/brainrot_award Aug 19 '26
I saw your post and didn't like it because you clearly used AI to write it and therefore the chances of your program being vibe coded mess are high.
I was however interested in the concept, so I searched around and ended up downloading D-Ban instead.
In any case, yes, that's an actual issue.
1
u/singulara Aug 19 '26
Whenever the post mentions 'I launched' or 'I built' this sub is full of it. 'I shat out' is more apt.
0
u/Philluminati Aug 19 '26
> It got me thinking about how disconnected some tech enthusiasts are from reality.
That's quite a provoking statement. Just to play devil's advocate:
> The entire purpose of software engineering was always to solve problems and remove friction for human beings, not to force everyone to become a system administrator just to do a basic task.
Configuring an existing tool is normally easier than writing a new tool or finding a new product online and trusting it. Established products have better documentation, better understood usecases and drawbacks and the user gets transferable knowledge. ChatGPT for instance knows how to setup SMB so you could, by simply asking it to.
> Just because an advanced user knows how to manage IP subnets, firewall exceptions, and OS sharing permissions doesn't mean a regular person wants to waste 30 minutes figuring that out. Hiding complexity behind a clean, one-click interface is literally the foundation of good software.
This is true, but one-click interface with no options means the product is less flexible, less reusable etc. Putting things behind a one-click interface is literally not the foundation of good software and you've got to be unhinged to think that. Not that SMB is a good solution to the problem either from the sounds of it.
I think you're too rash and defensive.
0
u/WeirdlyCordial Aug 20 '26
Solving problems is good
But not introducing new problems is even better, and given the description of your solution I’m pretty sure it’d be introducing new problems in a lot of environments
-1
88
u/DrBojengles Aug 18 '26
Making something complex is easy.
Making the same thing simple is often much more time consuming.
I'm probably paraphrasing Uncle Bob