10 ms·

Principles and priorities

119 points by hypertexthero 6y ago

imbusy111 6y ago
You're talking about values, not design principles.
throwaway55554 6y ago
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 6y ago
  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.
partyboat1586 6y ago
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.
- wslh 6y ago
  Yes, indeed it is team efficiency.
- majormajor 6y ago
  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 6y ago
    > 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 6y ago
  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 6y ago
    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 6y ago
    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.
craigkerstiens 6y ago
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.
- ThrowawayR2 6y ago
  > "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"?
  - joefourier 6y ago
    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.
  - saagarjha 6y ago
    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 6y ago
deleted 6y ago
[deleted]
MattGaiser 6y ago
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 6y ago
  > 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?
  - joefourier 6y ago
    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.
    - andrewingram 6y ago
      I don’t doubt that these developers exists, but I’ve never knowingly met one in 13 years of full time dev work.
  - Ididntdothis 6y ago
    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.
polote 6y ago
> 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 6y ago
  [deleted]
- 0xDEEPFAC 6y ago
  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 6y ago
    > 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 6y ago
      > 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.
stx 6y ago
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.
- onemoresoop 6y ago
  People also create technology or adopt technology because of people, most of the time. You have a point there with messy organziations, but that is not mutually exclusive with the software stack, usually up to date with the fashion. And it is amusing that older technology almost always can get the job done okay and efficiently only because its problems are already known and there are already boring but understood worksarounds. Yes, boring but works. Versus cool and solves this problems but causes other new problems we know nothing about. It’s been so far just like a game of whackamole
ncmncm 6y ago
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 6y ago
  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.
  - ncmncm 6y ago
    Since when is QNX a typical OS? Most programs need to run on the OS they need to run on, and on the hardware they need to run on. QNX (or other favorite obscurity) most usually is not an option.
simonw 6y ago
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.
- someguydave 6y ago
  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 6y ago
  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 6y ago
  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 6y ago
    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.
jdbernard 6y ago
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 6y ago
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.]
- cml 6y ago
  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 6y ago
    You misunderstood that line, they're saying the command line utilities are cumbersome
bconnorwhite 6y ago
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.
franciscop 6y ago
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!
mrfredward 6y ago
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.
dang 6y ago
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 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&query=by%3Adang%20%22level%20playing%20field%22&sort=byDate&type=comment 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 https://news.ycombinator.com/item?id=22932244
Erwin 6y ago
Going one level up to https://adactio.com/journal 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!)
a1369209993 6y ago
Similarly: "Make it work, make it right, make it fast, make it pretty, in that order."
- onemoresoop 6y ago
  Make it work now and fast potentially has maintainability issues down the line. Make it maintainable and brautiful may miss the mark on what’s actually needed and may be overengineered. Somewhere in between there is a sweet spot that can be found by luck or with some planning, a POC, etc
- galaxyLogic 6y ago
  I would replace that with "Make the code easy to understand". One you have easy to understand code it is easy to understand how it needs to be modified to make it work, right, fast and or pretty.

119 points by hypertexthero 6y ago

You're talking about values, not design principles.

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 6y ago
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.

partyboat1586 6y ago

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.

wslh 6y ago
Yes, indeed it is team efficiency.
majormajor 6y ago
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 6y ago
  > 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 6y ago
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 6y ago
  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 6y ago
  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.

craigkerstiens 6y ago

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.

ThrowawayR2 6y ago
> "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"?
- joefourier 6y ago
  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.
- saagarjha 6y ago
  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 6y ago

deleted 6y ago

[deleted]

MattGaiser 6y ago

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 6y ago
> 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?
- joefourier 6y ago
  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.
  - andrewingram 6y ago
    I don’t doubt that these developers exists, but I’ve never knowingly met one in 13 years of full time dev work.
- Ididntdothis 6y ago
  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.

polote 6y ago

> 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 6y ago
[deleted]
0xDEEPFAC 6y ago
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 6y ago
  > 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 6y ago
    > 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.

stx 6y ago

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.

onemoresoop 6y ago
People also create technology or adopt technology because of people, most of the time. You have a point there with messy organziations, but that is not mutually exclusive with the software stack, usually up to date with the fashion. And it is amusing that older technology almost always can get the job done okay and efficiently only because its problems are already known and there are already boring but understood worksarounds. Yes, boring but works. Versus cool and solves this problems but causes other new problems we know nothing about. It’s been so far just like a game of whackamole

ncmncm 6y ago

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 6y ago
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.
- ncmncm 6y ago
  Since when is QNX a typical OS? Most programs need to run on the OS they need to run on, and on the hardware they need to run on. QNX (or other favorite obscurity) most usually is not an option.

simonw 6y ago

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.

someguydave 6y ago
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 6y ago
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 6y ago
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 6y ago
  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.

jdbernard 6y ago

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 6y ago

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.]

cml 6y ago
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 6y ago
  You misunderstood that line, they're saying the command line utilities are cumbersome

bconnorwhite 6y ago

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.

franciscop 6y ago

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!

mrfredward 6y ago

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.

dang 6y ago

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 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&query=by%3Adang%20%22level%20playing%20field%22&sort=byDate&type=comment 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 https://news.ycombinator.com/item?id=22932244

Erwin 6y ago

Going one level up to https://adactio.com/journal 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!)

a1369209993 6y ago

Similarly: "Make it work, make it right, make it fast, make it pretty, in that order."

onemoresoop 6y ago
Make it work now and fast potentially has maintainability issues down the line. Make it maintainable and brautiful may miss the mark on what’s actually needed and may be overengineered. Somewhere in between there is a sweet spot that can be found by luck or with some planning, a POC, etc
galaxyLogic 6y ago
I would replace that with "Make the code easy to understand". One you have easy to understand code it is easy to understand how it needs to be modified to make it work, right, fast and or pretty.