Hacker News Reader

Comment by jabbany | Hacker News Reader

> The only thing that matters in software is the experience of the user.

I have one disagreement with this... There is another thing that matters in software --- the experience of the developer making it.

IMHO, I agree that libraries, languages, tooling,... etc. are not art whose complexity should be admired. But they are a necessary intermediate tool for _developers_ to make their work easier.

We can apply the same logic to something like construction. You can build a house with hand tools and man power, just like you can write code in machine language. It's not enjoyable but you can do it. The work around developer tooling is like a builder working with scaffolding, an excavator, a crane, an electric drill... You spend effort to set it up, and before the final product is delivered, you have to tear it down. But it was still worth it because it serviced the developer in some transient way.

View on HN

The problem with that argument is the "developer experience" is also awful for a lot of "modern"[1] software. The JS ecosystem is notorious for this, especially huge dependency trees of tiny fragments which no one really understands, tools on top of tools, etc. A lot of that complexity isn't actually necessary.

[1] Whenever I hear that word, I think "is that the best adjective you can come up with to convince people to use it?" because it often has no other advantages.

For sure, but things are still evolving and evolution is messy.

FWIW, I'd probably be considered a JavaScript luddite these days lol. When I build my own projects, I write vanilla ES5 (yes, 5). No tooling. No frameworks. No compiler. Just edit and hit refresh.

But when I work with others I will respect their choice of framework. Because the goal of frameworks and libraries and encapsulation in general is to trade-off extra individual work in exchange for smoother between-developer "compatibility" (reduced communication friction). I don't need to understand someone else's code, and neither do they need to for mine.

> A lot of that complexity isn't actually necessary.

I don't understand this take. Client-side JavaScript is hard because of cross-browser / cross-platform / cross-device challenges. Server-side JavaScript is hard because of the nature of the language and the runtimes, the lack of standard library and the myriad attempts to "fix" it, ranging from inventing new languages to transpilers to runtime rewrites.

May be you mean to say, a lot of complexity could have been avoided? Unfortunately, that ship has sailed.

Client-side JavaScript is hard because of cross-browser / cross-platform / cross-device challenges.

Is it really? Or is it hard because people are under the impression that it's hard and thus jump into the quagmire of others "selling" grossly overcomplicated "solutions" hoping it'll be easier (when in fact it isn't)?

When I can replace something that a team of about a dozen needed several months to create using a few MB of frameworks that work only in the latest version of Chrome and somehow needs multiple seconds to load over a gigabit LAN (internal tool) with an HTML form and a few lines of JS written in an afternoon that will work in any browser newer than ~IE5 (and will mostly work even without JS at all), I don't think that's the answer.

I don't understand this take.

As the saying goes, "It is hard to get a man to understand something when his salary depends on him not understanding it."

I think that's ultimately what it comes down to: Developers justifying their existence. They're all enamored with the new and shiny, resume-padding crap that they forget the problem they were hired to solve and instead create more problems that they then solve to show how "smart" they are.

...then they all get thrown out when the company downsizes. That's why I ended up having to do some JS work. I don't normally work with JS but I can use it if I need to.

I never had a need to do server-side JS so I won't comment on that in specifics, but I suspect it's much of the same situation.

It only matters as far as the cost to the user (including any externalities due to poor construction).

The software serves the user. Period.

The software serves the business' bottom line period.

The user only matters in so far as the keep coming back and paying money (or attention, which is also money).

Developer experience only matters in so far as it keeps costs low, creating better margins.

If that sounds kind of gross to hear, it's because it is. Businesses are made up of people. Customers are people. Every interaction on both sides of the equation should take that into account. If you ruthlessly maximize like the human part doesn't exist, your optimization strategy will fail.

"The software serves the business' bottom line period."

Making big assumptions about what the software project here. Given the article was mostly complaining about software developed for developers by developers, I don't think we can blame the suits for this one.

Selling shovels is just as much about making money as selling gold.

I only care if software serves the user when I’m the user.

I think both of you recognize a noble & true goal of optimizing & empowering people.

I somewhat think there's a huge error here though, a massive mistake in computing that we have such a huge divide between user and developer. A couple small vim tricks or enough shell knowledge to be a little dangerous, or even someone ok at excel macros blends the line so much here.

We have been building more and more totalistic apps, which afford less & less view of computing & developer-ish sensibilities. It keeps getting harder to see because we are so entrenched in pro application anti computing paradigms, but I think some day consumeristic computing will be worn thin. I New-old dynamics can re-start, embracing systems that also try to offer more developer-like sensibilities & capabilities.

Douglas Engelbart's idea of augmenting intellect to me speaks of the need for people to get great at toolbending, I at taking some good existing tools & capabilities, and being greatly empowered to bend create & explore different configurations & possibilities. Soft systems, with malleability, where users can ad-hoc cross over the aisle & become developers: that's a strong culture, where softwares real hidden noble purpose lies.

And where we can stop hating, stop being adrift & trapped, amid unyielding prisons of hard computing.

My take on this sentence is that, the user doesn't care how complex the system you're working with is, how pretty or efficient the code is.

All they care about is does it do what I want+expect it to do when I want it done while it solving my problem? That makes money.

There's lots of scenarios where the end user is in fact another developer, but I think the spirit is talking about the general populous.

Sure but it's a bit misleadingly reductive to both say that "only the end product matters, intermediate steps should just keep adapting to be the most optimal in producing that product" while also complaining about the exact artifacts that are resulting from that adaptation of intermediate steps.

Tooling does not get complex because engineers are somehow magically attracted to complexity. They get complex because the world is complex. To "hate [the complexity of] the tooling" is really just indirectly saying you hate the complexity of the world... which, I mean, I guess is fair, but not that interesting.

fair criticism - we like punchy, sound bites.

> the experience of the developer making it.

Is a infrequent commonly one time thing that pales in comparison to operating it.

That's assuming software is static. Write once, release it, and anything further is someone else's problem.

Is that how software development works today?

Reply on news.ycombinator.com