I don't know that I've ever been more torn about a comment than this one. I worked in both "core dev" and professional services development, and have seen what comes from well-architected software design, the sort of architecture that only experienced top-line CS graduates (or several-decades-worth-of-experience autodidacts or engineers) seem capable of producing (IMHO, YMWV)...
...and have seen many, many 1.0's, shelfware, etc.
A CS grad from a top-flight school with excellent experience is worth their weight in gold, at least on teams of multiple people developing big systems - you want at least one, they will take care of data design, software architecture, etc., and likely cause your code to be more robust, more maintainable, etc.
But motivated college grads (I'm Canadian, not sure what the US term would be), talented engineers, and autodidacts can crank out code like nobody's business. I don't know that I'd want to built a multi-year "core services" library out of it, but PoCs, MVPs, 1.0's, and demoware? Why not? And the top-flight CS grad might be wasted there.
I'm torn because I care about quality, but really high quality only matters for the really long-lived system, the health-and-safety-critical system, and the system that must survive on its own with minimal human intervention and maintenance.
Were I building a radiation control for healthcare, I would want electrical engineers and CS grads from top-flight systems. Ditto military avionics.
If I was building apps, apps, apps, servers built atop well-architected OSS libraries, etc., I'd want code, fast, and I'd balance quality Vs lifetime to maximize profit, and probably hire less experienced, less well trained devs who "give good face", understand requirements, and code fast.
The libraries themselves? Good question....
I don't have a conclusion. But j45 is right, customers don't care so much - but they don't want 3AM bugs, either. It's a trade-off.
- Being reasonably kind to your future self without over engineering or over architecting is the real skill of a talented developer/engineer in my eyes.
- All software is like hardware, no matter how it's built, it has it's limits that will likely have to be revisited.
- Customers not caring about which language/framework something is made in doesn't mean the code is automatically unkept or made carelessly.
- Most languages and frameworks are pretty capable. All have their tradeoffs of what they uniquely provide vs give away. Very few projects will critically fail or succeed solely from the selection of a particular framework or language.
- I'm not sure if you're connecting customers who don't care what language their system is built in, causing 3 AM bugs. If so:
a) 3 AM bugs are not a cause of any particular language of framework or language, or the customer not caring about which one, but rather, the developer.
b) Bugs are a reality on all platforms, and are best insulated against by a combination of process, policy and strategy that can be reasonably implemented in any stack.
Ultimately, it's about how the user feels and the value that provided to them in solving a pain.
Customer value is NOT the same value the developer provides themselves to make the developer's own life easier and somehow believing that all the build tools in the world will solve the customer's problem any better, or make a difference for the end user. It's not as often as it seems.
Most languages and frameworks are capable of delivering delight if the developer spends time focussing on the user's pain and not just their own pains in their stack. Looking at how much value HN provides, it's not a function of it's language, framework, or coding.
Maybe like inter-faith, i'm an inter-platform kind of guy as a polyglot and see the good everyone can be doing instead of dividing among syntactical philosophy that is indistinguishable to the users in the end.
