The manager wants the Submit button to submit the form, they rarely care how the programmer does it. It's the programmer that chose to install the 11,000 node_modules, to use React with 3 layers of state management on top with hybrid SSR/CSR and to do Kubernetes because that's what was on Hacker News that day or whatever. And guess what, somehow the Submit button does still not submit the form 10% of the time.
Get rid of the junk and the program will be more efficient AND you'll ship quicker.
I suspect you're imagining something like, just write some vanilla JS and maybe some tasteful but not bloated CSS.
You could do that. Then I'll come along with my old man Win32 skills and write a form with a submit button that sends the data by doing a memcpy into a UDP packet. It will take 300 kilobytes of RAM and start in 0.1 seconds. That'll make it approx 100x more RAM efficient than the baseline you can manage with Chrome, where an empty renderer process takes 23 MB of RAM to achieve nothing and starts so slowly the browser has to cache them in the background.
On the other hand, delivering features your users expect might be a bit harder. Shipping and updating that app will be painful for me, unless I use [plug] https://hydraulic.dev/ to make it easy [/plug], and the styling options are limited to setting solid color backgrounds on things. Things the product manager views as basic, like adding a dark mode, will take a surprising amount of effort. The app is likely to be more crash prone than the web app due to all the manual memory management required. Text zoom won't work. I'll have to write in C or maybe C++ if I'm feeling extravagent.
So there's got to be a balance somewhere. Features do matter.
But what even is good code?
As an infrastructure guy i see my fellow software engineers endlessly debating and bikeshedding on anything but speed and memory consumption.
I see them arguing about functional vs object oriented, immutable data structures, test driven development, agentic bs, this or that interpreted language… never about reducing memory consumption .
If you ask your boss, it will most likely be whatever spaghetti code which ensures the contract gets signed on time.
The boss doesn't care if the developer needs 10000 libraries for the submit button.
Then there are industries where the customer complains if code is slow. They will actually hire expensive consultants to analyze and benchmark the code. And while the consultants likely are not more talented than inhouse staff, now you have both sides very interested at looking at the problem from engineering perspective.
In this case "good" includes performance.
With LLMs, it's faster to ship even in a more verbose language like Go or Rust.
For example, if you're rendering a user account page that has 100 data fields (name, address, etc), that's a few kilobytes at most. If your code is using Node of PHP you're probably using tens or hundreds of megabytes, possibly gigabytes, to turn that into a stream of HTML to send to the user.
I suspect using Claude to turn all the Node and PHP apps in the world to Rust or Go would massively reduce the necessity for huge datacentres using terabytes of memory.
If you're working on SAP or Salesforce, the language decisions are already made for you. If you're integrating with an existing Electron runtime, then you'll be using something in the JS family, like it or not.
Technical decisions like this have to take into account a lot of factors outside of just the language itself.
Is the language you want to use easy to hire for? Will we have to pay a premium for engineers with a specialised background in the language? Do all our 3rd party dependencies maintain SDKs for the language? Do libraries that meet various certifications we might need (i.e. FIPS) exist for the language?
Something like Typescript or Java is going to win out over Rust/Erlang/FP-of-your-choice on a number of these criteria.
Not solely. The business will have reasons to stay on a mainstream language, for example because
- it offers better guarantees for hiring maintainers in the future
- it has a higher likelihood that security issues will be fixed rapidly for free
- LLMs are better at maintaining code written in it
Even bus-factor comes into it.
I don't even want to recruit or be recruited with such a title.
If the company is using Common Lisp, do you have the 6-12 months to wait for them to ramp up, or do you hire someone who has done Lisp before? That is downstream from the technical decision to use Common Lisp, but it is a huge business impact.
Enh. I think this only exists for some programmers, who can't write good code fast.