[HN Gopher] Principles and priorities
___________________________________________________________________
Principles and priorities
Author : hypertexthero
Score : 91 points
Date : 2020-04-27 16:07 UTC (6 hours ago)
(HTM) web link (adactio.com)
(TXT) w3m dump (adactio.com)
| ncmncm wrote:
| Operating system policies are interesting in this regard.
|
| Continued correct activity of OS processes is prioritized over
| user-level activities even where the purpose of the system is
| explicitly the latter. The reasoning seems to be that if the OS
| can't keep up, it can't maintain the environment that enables
| user-level stuff to work.
|
| This generates conflict where user-level activities have real-
| time requirements. It is very, very hard to get your typical OS
| to leave a process running on a dedicated ("isolated") core and
| never, ever interrupt it, even given root privileges and boot-
| time static provisioning. Just store a byte in a file-mapped
| page, and whoops! get unsynced millisecond pauses while the OS
| copies it to the disk sector. Oh, and surely you still wanted an
| interrupt every millisecond to see if any OS resources tied to
| the core need cleanup, even though it never is asked for OS work.
| jschwartzi wrote:
| Which OS? In QNX this isn't an issue. If you have hard real-
| time requirements you need to use a Real-Time Operating System.
| MattGaiser wrote:
| 1. Most developers don't work for the end-user. They work for who
| is paying their salaries, which is often someone is mostly
| interested in luring the end user and using them to sell a
| product to someone else (everyone from Google to Facebook to
| DoorDash has this model). Without those megabytes of JS analytics
| and whatnot, the end-user cannot be packaged into the actual
| company product.
|
| 2. As the real customer for the developers consists of these
| institutions, they care more about development costs than whether
| customer internet is wasted. Developer convenience means cheaper
| projects.
|
| 3. Users blame themselves for the performance tax. They think
| they downloaded a virus, have an old computer, or need faster
| internet and they go and upgrade all those things, making the
| performance tax seemingly disappear.
| askafriend wrote:
| > Most developers don't work for the end-user.
|
| This is extremely reductionist.
|
| If you want to take it further, then nobody works for the end
| user ever. If you have any funding _at all_ (even from the
| public markets) then you "work for investors".
|
| Can you see how this is theoretically true, but practically not
| as true?
| Ididntdothis wrote:
| You work for whoever is deciding how much money you get. In
| bigger companies that decision gets made many layers away
| from the end user.
| wayoutthere wrote:
| I dunno, this feels like a technicality. Almost all of us
| work for a company, not the end user. We look at the company
| to figure out the balance it wants to maintain between user
| experience and maintainability. And companies are focused on
| the customer relationship, which is the sum of all
| experiences a customer has with the company _over time_.
|
| And part of the way you can actually deliver a good customer
| experience, consistently, at scale, is by _focusing on
| developer efficiency_. To consistently deliver a great
| experience to customers in a world of constantly shifting
| customer expectations, you need to be able to ship features
| from design through delivery very quickly.
|
| This means enabling your developers to be more efficient by
| designing products that are _flexible_. Maybe the user
| experience isn 't 100% optimal for a given customer
| interaction, but the goal is to keep the sum of all
| interactions over time as high as possible.
| Rury wrote:
| I don't see your point.
|
| Maybe the OP's argument doesn't fit every case, but there's
| many where it does (e.g. large companies). Calling it
| reductionist, doesn't necessarily invalidate it...
| Yen wrote:
| Maybe nobody works for the end user ever, but some people
| work more for the end user than others.
|
| If you work for a web site that makes its money by lead gen
| or advertising, you're often working against the end user.
| This isn't necessarily true, it's just how the incentives
| will align.
|
| If you sell SaaS to the enterprise, you're not working for
| the end-user, you're working for their boss, or whoever else
| is making the purchase decision.
|
| If you're selling a product directly to end users, and
| usability is a factor in whether or not they choose pay you,
| that's a little closer to working for the end user.
|
| And, best-case scenario, if _you_ are the end-user, or your
| boss is the end-user, then you can truly be working for the
| end-user.
| joefourier wrote:
| But it does explain a lot of things in practice. Many
| developers will choose to use a technology not because it
| makes the end-product better for the end-user, but because it
| will make their resume more attractive for potential
| employers.
| pmw wrote:
| I suspect OP is referring to the Principal-agent problem: htt
| ps://en.wikipedia.org/wiki/Principal%E2%80%93agent_proble...
| a1369209993 wrote:
| Similarly: "Make it work, make it right, make it fast, make it
| pretty, _in that order_. "
| partyboat1586 wrote:
| Developer efficiency is actually harmed by valuing it so much.
| Developers get into pointless ideological debates about purity
| and that hurts their efficiency. When good developers have to
| deliver features in a short time frame they stop debating that
| stuff and make decisions. They then learn from these decisions
| the hard way and no one is having an ideological debate any more.
| majormajor wrote:
| There's a "no true scotsman" answer where both these
| ideological debates, and the "ship a bad experience because the
| developer wants to use shiny technologies" the original article
| discusses, are clearly not ultimately "efficient" for the
| business.
|
| But it points to a problem with using the word "efficiency"
| like this if it's so commonly misused/misinterpreted.
|
| "Deliver value" is something I've seen people push instead, and
| it tends to stay more customer-focused. It's hardly perfect,
| and there are still temptations to bikeshed and focus on the
| wrong thing, but it's a bit easier to recognize and course-
| correct as a team when that's your ultimate goal.
| a1369209993 wrote:
| > But it points to a problem with using the word "efficiency"
| like this
|
| Just adding faux-numerical terminology helps a bit:
| ideological debates are of (approximately) zero value,
| whereas javascript frameworks are of negative value.
|
| > "Deliver value"
|
| TFA did already make this point, but that's meaningless
| unless it's short for "Deliver value, even it conflicts with
| [some specific other thing that you might resonably want to
| do].".
| agentultra wrote:
| And if they keep delivering features in short time frames they
| will never get a chance to debate quality or elegance in their
| work.
|
| And eventually you will start hearing them complain about an
| unmaintainable mess and turnover will probably increase.
|
| /s
|
| I think you do have to care, on some level, about maintaining
| code quality and standards. I've worked in feature-factories
| and it's not a panacea. _It doesn 't crash_ and _it goes
| reasonably fast_ are both features after all that seem to be
| related to the quality of a code base and the expertise of the
| team behind it.
| jakear wrote:
| One approach is a schedule for when everyone works on debt vs
| features vs testing.
|
| For instance: first week of the iteration is for paying off
| debt. Second and third are feature work. Fourth is testing
| (note: not unit testing, real testing. As in everybody chips
| in to actually play around with the features their colleagues
| added and provide feedback; also verify that all the bugs
| that were fixed this iteration didn't creep back in, or get
| fixed with a "works on my machine" patch)
| partyboat1586 wrote:
| Of course there is a balance to be struck. I'm not saying
| don't plan things out at all. I'm saying limit the time you
| spend doing it relative to the impact of the decision. That's
| not always easy to gauge which is where an experienced tech
| lead comes in to have the final say on what gets done and how
| long the debate goes on for. A strong tech lead is essential.
| wslh wrote:
| Yes, indeed it is team efficiency.
| craigkerstiens wrote:
| The TLDR states that the current state of modern development
| prioritizes developer efficiency over all else, and that user
| experience is way under valued.
|
| My problem with this isn't that it places value on user
| experience, it is in the premise that developer efficiency is
| prized above all else. Deploying an app today is just as hard as
| it was 15 years ago. The only two things that jump out in recent
| memory that made a very sizable difference on developer
| experience were Heroku, Github, Docker. Setting up a hello world
| with react and a basic API takes me a day or more, where as 10
| years ago with jquery this was an hour or so. Deploying an app
| with K8s is google scale, but takes me a week to do, forget
| debugging something in production.
|
| If we've been prioritizing developer efficiency at all costs
| we've failed pretty massively. I personally love the idea of
| optimizing a lot for developer efficiency because we can do
| deliver more value to others at the end of the day, but there's a
| lot of shiny new stuff that has some reason for existing which is
| definitely not developer efficiency.
| MattGaiser wrote:
| React's efficiency is through its millions of packages. I had
| to build a project rapidly in React a short while ago and there
| was a package for everything.
|
| A toggle? Yep. A timeline? Yep. A textarea? Yep. Toasts? Yep.
| Spinners? Yep. React just has so many pre-built components that
| you can add features very rapidly.
| polote wrote:
| You will have the same thing if yo use a jquery extension,
| and you won't have to install webpack
| ThrowawayR2 wrote:
| > " _If we 've been prioritizing developer efficiency at all
| costs we've failed pretty massively._"
|
| Do we not hear all the time on HN, for example, that "Yeah,
| native apps are more efficient and look better but Electron
| lets us just write it once and deploy on multiple platforms"?
| saagarjha wrote:
| You hear the opposite, too. In fact, you'll hear both anytime
| an Electron app makes it to a front page, or if a company
| known for sticking to their guns on Electron or native
| announces literally anything.
| zxcmx wrote:
| A bloaty app that's not platform native is still infinitely
| more usable than something which doesn't exist at all.
|
| Electron is one of a number of technologies which allow
| things to exist (in a non-optimal form) that might not be
| economically possible if a bigger team or a lot more time
| were required to ship them.
|
| IMHO the sad thing is not that Electron exists, the sad thing
| is that we don't have stuff that's _way easier_ like
| hypercard or VB6 was.
| joefourier wrote:
| Electron allows you to package your webapp into a
| downloadable stand-alone package, but does not make your
| development any more or less painless if you decide to use
| modern Javascript frameworks and infrastructure built for
| Google-scale deployment.
| tensor wrote:
| It's certainly a sentiment that is somewhat common. At the
| extreme end you have people arguing that you should optimize
| developer efficiency even over shipping working bug free
| software, which always blows my mind when I hear it. And I
| don't mean accidentally doing it, I mean _knowingly_ shipping
| something that doesn 't work.
| polote wrote:
| > Sadly, I think the current state of "modern" web development
| reverses that principle. Developer efficiency is prized above all
| else.
|
| I strongly disagree with that, "modern" web development values
| beautiful code over almost anything else, if that wasn't the case
| you could have one of your dev building a form in a few hours,
| instead they need tons of tools (react for example) that slow
| their development
| [deleted]
| lolsal wrote:
| > I strongly disagree with that, "modern" web development
| values beautiful code over almost anything else
|
| I would condition this to be:
|
| > "modern" web development values beautiful code _that you can
| see_ over almost anything else
|
| I wouldn't call apps that are run by transpiling code into
| another language so that it can be compiled into something
| else, that is packaged up and shipped around in a docker
| 'image' and then run in who-knows-how-many levels of
| virtualization in someone else's cloud, particularly beautiful.
|
| I contrived a painful example, but if we're talking 'beauty' in
| terms of what you see in your IDE/text editor, then maybe
| you're right, but in terms of what an application is and how
| it's used/deployed? No way.
| 0xDEEPFAC wrote:
| Yea, the idea that "modern web programming" is beautiful at all
| franky makes me cringe.
|
| Web programming and the web has separated developers too far
| from the hardware that actually runs the stuff and, as a
| result, we have built confusing towers of babel.js.
|
| I mean, Javascript was originally made for developer ease over
| user reliability - and look at it now - it shows with the
| cacophony of NPM dependencies prone to "leftpad" style failures
| and the new frameworks every 6 months. All of this, of course,
| goes against one of the author's key points: "User experience,
| even over developer experience."
|
| Unfortunately, I don't think the problem is solved by process
| but instead on re-education to compiled, reliable systems, made
| with a typing system designed to catch errors. Introducing more
| process and efficiency will never make a bicycle into a proper
| car.
| Tade0 wrote:
| > I don't think the problem is solved by process but instead
| on re-education to compiled, reliable systems, made with a
| typing system designed to catch errors.
|
| We already have that in the form of TypeScript, but both
| left-pad and core-js were, for lack of better term, non-
| technical failures.
|
| Only the most recent such case - is-promise - was purely a
| technical failure.
|
| There's not much than can be done when the sole core
| maintainer of a popular library lands in a penal colony.
| 0xDEEPFAC wrote:
| > We already have that in the form of TypeScript
|
| While an improvement Typescript is a far cry from the likes
| of Ada and doesn't really compare.
|
| > There's not much than can be done when the sole core
| maintainer of a popular library lands in a penal colony.
|
| Perhaps the solution is to not use Javascript, since it
| always forces you into an "ecosystem" of "frameworks" at
| every turn - and they are not cheap! Just another thing to
| throw on the stack. mb's be damned.
| [deleted]
| [deleted]
| simonw wrote:
| The thing that confuses me about "modern", JavaScript-everything
| web development is that I just don't see the developer
| efficiency, at all.
|
| I've collaborated with many different teams that use the modern
| JavaScript stack. It seems to me that it takes multiples of time
| to deliver features compared to the old forms-and-HTML-with-a-
| tiny-bit-of-JavaScript-enhancement methodology.
|
| Are we really optimizing for developer efficiency here? We've
| given JavaScript-everything a decade to prove that it's a better,
| more productive way of building higher quality websites and
| applications. I don't think it has.
| ssalka wrote:
| The problem is, today's applications are not HTML forms with "a
| tiny bit of JavaScript enhancement."
|
| Today's apps are immense JS programs - tens if not hundreds of
| thousands of lines.
|
| Good luck scaling that without modern tooling.
| [deleted]
| simonw wrote:
| Most of those applications don't need that though. Developers
| write hundreds of thousands of lines of code because that's
| what you have to do if you commit to a JavaScript-everything
| architecture.
|
| If the thing you are building needs that then go ahead and
| build it like that. But SO MUCH of what I see built on the
| modern JavaScript didn't need to do that at all.
| godot wrote:
| Quoting this paragraph by the author:
|
| > First and foremost, there's the end user. If a technology
| choice harms the end user, avoid it. I'm thinking here of the
| kind of performance tax that a user has to pay when developers
| choose to use megabytes of JavaScript.
|
| I believe the author is indeed talking about React (and other
| frameworks), SPA, big JS bundles. The developer efficiency
| being alluded to here is for tech startups to scale a team. A
| component-based frontend is valuable in providing that
| efficiency. The efficient is not about building a form in a few
| hours vs 2 days with React, but about code maintenance and
| scaling a team so many developers can work on the frontend at
| once in a sensible way.
|
| However, having said that, I am not an advocate for a React
| frontend. I actually recently wrote an article, on a different
| topic, but with a very similar theme [1]. I think component-
| based frontend framework solves a real problem in an
| organization, but it does not have the best UX in mind.
|
| [1]: https://dev.to/bigi/dev-to-is-the-perfect-demonstration-
| of-h...
| hinkley wrote:
| I had a job with a bad case of NIH and my lead was a very
| upbeat guy.
|
| A couple months in he gave me kudos for getting something done
| in "only two weeks"
|
| This was work that would have taken less than a week on my
| first big frontend job and here it was noteworthy that I did it
| in twice the time. Confusing emotions. Initially I felt dirty.
| Or like I was in the beginning of a horror movie where it turns
| out the happy guy is the killer.
|
| And while I agree with the title on the article, I think it's a
| shame because what we should be rewarding is effectiveness, not
| efficiency. I probably spend 20% of my time working on
| improving productivity and reducing variability for the whole
| team. Which means I get a little bit faster (and a lot less
| stressed out) in aggregate while everyone else gets a lot
| faster. That lead's boss hired me specifically for that, but
| not all bosses are so enlightened (and he left a year later).
| [deleted]
| derefr wrote:
| Depends on what you're trying to build/display.
|
| A sign-up form? Yeah, you aren't getting much from your SPA
| framework. Pure overhead.
|
| A data-table with user-selectable columns, pagination, and
| arbitrary sorting and filtering, where the data is too large to
| fit in memory (billions of rows) so you have to re-render by
| hitting the server; but the rows contain view-state components,
| so you can't re-render _on_ the server? Two lines of code in an
| SPA; three months on your own. Equal resulting JS size, either
| way.
|
| And something like Grafana: how would you even _do_ that
| server-side? Emit a server-sent-event stream of SVG images?
| This is a case where server-side rendering would result in
| heavier _client-side_ code than an SPA would!
|
| -----
|
| Now, the majority of people using SPAs don't need SPAs. I think
| people get into SPA frameworks like React because everybody
| wants to learn the frameworks and libraries, to have them in
| their pocket and on their resume, for when they
| (hypothetically) one day get hired for that one job where they
| _do_ get to build the fancy slice-and-dice analytical data
| dashboard. That job probably would pay pretty well. They want
| to be qualified for that job.
|
| If you're a project manager, and you really value getting an
| MVP shipped quickly, you should push back on the engineering
| lead's desire to use an SPA framework. Ask them whether there's
| anything they're really gaining _for this specific project_. If
| there 's no reason not to, then just suggest they build the app
| as a plain-old server-side-rendered-HTML app. Use Rails; heck,
| use PHP. (Or be fancy and use Phoenix LiveView.)
| SkyMarshal wrote:
| _> Are we really optimizing for developer efficiency here?_
|
| Good question, we're really not, we're optimizing for making
| websites and webapps work and feel like desktop apps.
|
| > _We 've given JavaScript-everything a decade to prove that
| it's a better, more productive way of building higher quality
| websites and applications. I don't think it has._
|
| Not unless you count things like Google Maps, which wouldn't be
| possible without SPA-style JavaScript.
| simonw wrote:
| I am 100% on board with Google Maps and Trello being built
| using JavaScript-everything.
|
| Most of the things I've seen built using the modern
| JavaScript stack don't warrant working and feeling like
| desktop apps. They should work like fast-loading websites -
| especially on mobile phones, which is the source of most
| traffic these days.
| potta_coffee wrote:
| I'm not a front-end developer. Often times I end up developing
| quick front-ends for internal tools, but I've also built them
| for customer facing products. I've become pretty competent with
| VueJs and I've been able to build features very quickly,
| sometimes in a matter of hours. If development is taking a very
| long time, I feel like that's more likely an organizational
| problem.
| someguydave wrote:
| On the other hand, a decade of Javascript sprawl has been great
| for creating a business case for hiring more Javascript
| developers and paying them more.
| izacus wrote:
| I think it optimises for developers ego and "fun" factor. If
| you actually read into posts around you can quickly see that
| the developer having fun is paramount to any solution - this is
| why everything needs to be a proper library and everything
| needs to be written in the developers favorite language.
| Ecosystems like JS driven Electron apps come out of this
| mindset.
| Touche wrote:
| HTML with a tiny bit of JavaScript is just considered not an
| option at all, by the designers and the business. They don't
| want a HTML form post when you delete an item from a list, they
| want the item to animate out. So if you look at it like that,
| then yeah it is probably more developer efficient to do it the
| modern way.
| simonw wrote:
| That's the tiny-bit-of-JavaScript-enhancement.
|
| It's trivially easy to hook up a "delete" button such that it
| works without JavaScript, but if JavaScript is available it
| turns into a fetch() POST that removes the item (with a CSS
| animation) once it completes.
|
| Or if you're too lazy for progressive enhancement, you can
| skip the "works without JavaScript" bit.
|
| I used to do this kind of thing with jQuery one-liners all
| the time. Today browser compatibility is good enough that you
| don't even need jQuery.
| Touche wrote:
| Yeah but requirements are never that simple. You also have
| a cart item in the header that shows 4 but now must show 3,
| and you have a price that's over in the sidebar that needs
| to update, etc.
|
| Oh and the user is logged in and is receiving a
| notification that an item they were watching is now
| available, better show a toast.
|
| Sorry but the simple jQuery sites turn into soup once the
| requirements are what they are today. You can still do it,
| it's possible, it becomes harder and harder to maintain
| long-term though. Then efficiency becomes worse than how
| people do it today.
| simonw wrote:
| So many of the projects I've seen built with modern
| JavaScript aren't nearly that complicated though. They're
| building in anticipation of that complexity, but it never
| arrives.
|
| Look at how many content-oriented news website article
| pages have gone all-in on React, with the result that
| they serve up over 1MB of JavaScript just to show you an
| article with a "save" button that no-one ever clicks.
| Touche wrote:
| This is very true. I think, as this article describes,
| going through the process of discussing priorities as
| part of the initial architecture would lead to asking the
| questions about what the requirements really are, and
| what technologies best fit those requirements.
| simonw wrote:
| Yes, definitely. There are plenty of applications that
| benefit enormously from the modern JavaScript stack. I
| wouldn't dream of attempting something like Trello
| without React or similar! But I don't think it should be
| the default for every project without at least some
| careful thought.
| kethinov wrote:
| I laughed when you said Trello because I just got done
| speaking with a colleague who complained that it locks up
| on her every time she tries to screen share while using
| it; the only web app she works with where she has this
| experience. It's obvious that the over-reliance on
| JavaScript is the reason for this and if Trello had a
| non-JS option she would surely take it even if the UX was
| "worse." (What could be worse than the UI freezing
| constantly?)
| potta_coffee wrote:
| Also as soon as you provide something nice, the manager
| or business owner or whoever is going to ask for a dozen
| more features and then you realize "doh, it'd be nice to
| have some way of organizing all this spaghetti".
| cknoxrun wrote:
| I couldn't agree more. And I have also found there is a dogma
| surrounding JS technology that views plain old HTML generated
| on a server as bad practice and outdated. Yet, again and again
| I see fast and functional websites converted to JS frameworks,
| becoming slow, memory intensive/leaky, and less responsive.
| zozbot234 wrote:
| The new dogma is "plain old HTML generated on a server is OK,
| as long as it's using node.js on a client-side oriented JS
| framework". Of course it's just as slow and memory-leaky as a
| plain old SPA, but now you get that on _both_ the client and
| the server!
| aboodman wrote:
| Your experience doesn't match mine, either. I'll go to a lot of
| trouble to avoid server side development, which is partly why I
| love <s>Zeit</s> Vercel's offerings -- they abstract me from as
| much of the unix morass as possible.
|
| I think it might just be a matter of what feels like home to
| you.
| stickfigure wrote:
| Your experience does not match mine.
|
| I worked through the pre-Javascript world, the jquery world,
| the angular1 world, and now the react world (not to mention a
| decade of native GUI development before that). I am _vastly_
| more productive with react and my UIs are much easier to use.
|
| Every time I submit some 1990s or 2000s era form that gives me
| an error because I typed some field wrong, but also wipes out
| half the other fields I spent 15 minutes typing... and of
| course, hitting the back button wipes out the remaining
| fields... I want to reach into the screen and throttle someone.
|
| No thanks.
| simonw wrote:
| "Every time I submit some 1990s or 2000s era form that gives
| me an error because I typed some field wrong, but also wipes
| out half the other fields I spent 15 minutes typing..."
|
| That's exactly why we put so much effort into making sure
| Django's forms framework didn't wipe out the values you had
| already filled in if there was a validation error.
| samastur wrote:
| None of the problems listed is inherent in HTML + touch of
| JS. Especially since most browsers these days will remember
| what you typed anyway unless specifically instructed
| otherwise. Complaining about the back button behavior in SPA
| world seems...misplaced? If anything, its behavior is even
| worse.
| andrewla wrote:
| I think this is referring to the server round-trip -- form
| submit, server-side validation, "you have to specify a
| color for your widget" and everything on the field is
| blanked out because the server didn't fill in the default
| values into the form based on your previous submission.
|
| Back button stuff; I mean, it's not trivial to support it
| correctly now, and it might just be an increased focus on
| usability and testing of this sort of thing, but hitting
| back was always dicey -- half the time you'd get some error
| about re-posting form data when you hit back, and if you
| said no, bad things happened, and if you said yes, worse
| things happened.
| Erwin wrote:
| Going one level up to https://adactio.com/journal shows a
| sparkline (with author's activity perhaps, the latest posting is
| entry 2666!) which has a feature I have never seen before: an
| audible graph. Clicking on the sparkline plays tones matching the
| data. Not particulary useful, but make me thing about using audio
| for presenting data (apparently "sonification" is a thing!)
| jdbernard wrote:
| I think there is some truth to the conclusion. But remember that
| developer time is by far the largest expense when creating
| software. Sometimes the focus on developer efficiency is driven
| primary by a desire to minimize this cost.
| jasode wrote:
| Developer efficiency often gets prioritized over user experience
| _because that 's the only way the software would even get to
| exist_.
|
| I take my own software that I write solely for personal use as
| examples. In those cases, I play both roles of the developer and
| the end user. Most of my utilities are _console command line_
| utilities instead of full GUI. As a result, I have a bunch of
| command-line utilities that are very cumbersome to use. That 's
| because I prioritized the dev experience over the UX.
|
| Console apps are 10 times faster to code. I can bang out printf()
| or Console.WriteLine() statements 10x faster than placing GUI
| textboxes on a form. Yes, GUI wizards and templates accelerate
| the layouts but it's still not as fast as console apps for quick
| & dirty utilities. As an end user, I'd prefer easier-to-use GUI
| apps but I don't have the extra time to code them. I complained
| to the developer (that's me) to make a GUI app with better UX
| instead but the dev ignored me.
|
| With my limited time, I'd rather have 20 utilities with bad UX
| that _exist_ rather than just 5 apps with good UX at the expense
| of not having the other 15 at all. It 's an unavoidable tradeoff
| of finite time.
|
| Likewise, I as an end user don't like Electron apps but I know
| that lecturing developers on using something lighter weight like
| C++ & Qt or C#/Winforms means they _wouldn 't bother writing the
| app at all_. It was the ease (and/or familiarity) of Javascript
| that allowed them to write the app in the first place.
|
| [REVISED above text to clear up the misunderstanding in the
| reply.]
| redisman wrote:
| I've build GUI tools for projects like game editors before and
| since they're mainly for developers it'll just end up as a huge
| mismash grid of buttons anyway. Not really any better usability
| than a console app, just there is usually a requirement to show
| some image on the screen at the same time.
| spiffytech wrote:
| I think this is the key point -- JavaScript is eating the world
| because it allows a single team to support a single codebase
| built in a single technology across all target platforms with
| minimal platform-specific integration. Indie software gets to
| exist _at all_, and businesses don't have to pick and choose
| which OSes are worth the investment, and which simply won't get
| the product. As was common 10-15 years ago, when most software
| was either Windows or Mac, often not both, and Linux considered
| itself lucky that Flash was only a _little_ behind instead of a
| _lot_ behind.
| cml wrote:
| Is it possible you are agreeing with the author?
|
| > Most of my utilities are console command line utilities
| instead of full GUI and they are very cumbersome to use. That's
| because I prioritized the dev experience over the UX.
|
| As the user you prefer command line utilities, and so I
| interpret your building command line utilities as prioritizing
| the user's experience.
|
| On the other hand, if you needed a program that could exist
| very efficiently as a command line utility but, desiring to
| learn how to use some new GUI toolkit you built a GUI instead,
| I might interpret your action as prioritizing the developer
| experience (in which you are focused on the details of the
| implementation) over the user experience (in which you are
| focused on the results).
| intarga wrote:
| You misunderstood that line, they're saying the command line
| utilities are cumbersome
| a1369209993 wrote:
| > the command line utilities are cumbersome
|
| Except this is obviously untrue? I can't pipe a _window_
| through grep or sed.
| buckminster wrote:
| Command lines! That's some fancy UI.
|
| For utilities I won't use very often I just hard code the
| parameters. If I want different parameters I edit the code.
| yepguy wrote:
| > Most of my utilities are console command line utilities
| instead of full GUI. As a result, I have a bunch of command-
| line utilities that are very cumbersome to use. That's because
| I prioritized the dev experience over the UX.
|
| Same here, although lately I don't even bother writing a full
| CLI utility. Instead I just write a few functions to call from
| a REPL.
|
| (On a side note, why is the REPL experience so bad in
| JavaScript? How can Clojure have a better REPL to the
| JavaScript ecosystem than JavaScript itself?)
| franciscop wrote:
| There's a big unspoken truth with Javascript here. The _vast
| majority_ of Open Source Javascript is created by developers for
| no money to solve their own problems and itches. Maybe not the
| most visible top-level libraries like React, but the thousands of
| dependencies are there to help the developer with some issue they
| had at some point. Sure they may have secondary goals, some of
| them including being time efficient, or memory efficient, or size
| efficient, etc.
|
| So it seems expected that the agglomeration of tools with varying
| secondary goals, and a clear primary goal, results into this goal
| of developer efficiency being potentiated greatly. Forget about
| writing 5 lines of code, just npm install it.
|
| And that _is fine_ IMHO, people /companies with different goals
| should be doing things differently. It also seems that turnover
| is a big issue as well for most companies, so they also try to
| make dev experience better!
| imbusy111 wrote:
| You're talking about values, not design principles.
| stx wrote:
| In my experience, companies expect developers to output features
| quickly. When it does not happen as quickly as expected the
| assumption is that its the developers when often times its the
| overall organizations process that is a mess. Its not necessarily
| a technology problem but a people problem.
| bconnorwhite wrote:
| Short term: user experience, even over developer experience,
| because user experience is the point of developer experience.
|
| Long term: developer experience, even over user experience,
| because over a long enough time period developer experience
| drives user experience.
| mrfredward wrote:
| Software development doesn't exist in a vacuum. The author talks
| about these design principles as if they are supposed to satisfy
| the software team's personal values, when in reality it needs to
| be more about the organization's goals and values. Take this
| statement:
|
| >Usability is more important than profitability.
|
| For a bootstrapped company in danger of running out of money,
| it's ridiculous to prioritize perfecting UX over making sales.
| For an open source team, profitability isn't part of the equation
| at all but user experience might be a top priority. My point is,
| these aren't just matters of personal taste, the "design
| principles" have to mesh with the rest of the organization.
| throwaway55554 wrote:
| Here's the TL;DR.
|
| > But as a general principle, I think this works:
|
| > User experience, even over developer experience.
|
| >Sadly, I think the current state of "modern" web >development
| reverses that principle. Developer efficiency >is prized above
| all else.
| ehnto wrote:
| I probably complain about this too much, websites built with
| SPA technologies can very often behave poorly to the user.
| Jittery, slow to be useful, generally less performant than
| other solutions. I feel like that gets ignored because so many
| people want to be on the bandwagon, and many feel the developer
| experience is better so we just kind of sweep that part of UX
| under the rug.
| dang wrote:
| The submitted title ("Developer efficiency prized above all
| else") broke the site guidelines, which ask: " _Please use the
| original title, unless it is misleading or linkbait; don 't
| editorialize_"
| (https://news.ycombinator.com/newsguidelines.html). Cherry-
| picking the detail you think is most important from an article is
| editorializing.
|
| Like it or not, titles dominate discussion. The comments in this
| thread are nearly entirely a reaction to that title. The HN
| guidelines specifically ask users not to abuse that power. On HN,
| submitting an article doesn't confer any special right to frame
| it for everyone else.
|
| If you want to say what you think is important about an article,
| please post it as a comment to the thread. Then your view will be
| on a level playing field with everyone else's:
| https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
|
| If it's necessary to change a title, please do that by picking
| the most neutral and accurate phrase you can find on the actual
| page which represents what the article is about. More on that
| here: https://news.ycombinator.com/item?id=22932244
___________________________________________________________________
(page generated 2020-04-27 23:01 UTC)