> Why would a company warn that their technology is dangerous if it wasn't?
Because it makes their technology seem more important and powerful?
Do you usually believe 100% what a company says about itself?
> Mythos export control issue, it's obviously not good for profits
Who cares about profits? None of these companies make money like a business currently. It's all speculative valuation and influenced by the same hype/doom cycle
What are you being pressured to do to meet a deadline that's on the level of building collapse?
"skimp on the tests" or "do this hard to maintain fix as the solution" is maybe the hardest I've gotten pushed. Are people telling you to skip auth to hit a deadline?
When I started programming I wanted everything I wrote to be museum-ready. I was slow as shit and waaay too precious about code. As I've matured I realize that's not a good way to work.
I think my lowest acceptable quality bar is still pretty high (and I'm fortunate to work somewhere that is valued). But as time has gone on I've tried to emphasize speed and knowing when something is "good enough"
I feel that it's an important skillset for the profession, but often craft-oriented engineers dismiss it at "business people not understanding"
As always this depends a bit on where you work and your projects
My example is we want to skip the div if empty or undefined. We can't throw on assignment so we leave it as as string|undefined.
When we go to display, we have to check if the string is empty anyway, right? What if it's empty in the DB or API response?
No matter what the display-component is doing something to prevent showing the empty string.
`
if(fooBarDisplayName.length) { show div }
`
or
`
if(fooBarDisplayName?.length) { show div }
`
I'm not sure what we gain by leaving it as `string|undefined`
---
If there was a "NonEmptyString" type maybe I could see where you're coming from.
I guess you could argue treating `string` like a `NonEmptyString` type seems error prone. The compiler can't verify you've done the check. At some point someone will set a string when it's empty or not do the necessary check.
You'd want a separate non-string type to make sure it's actually been parsed
I think about this a lot. My belief is professional programmers should not be artists.
I think about other professions. A cook cannot spend time making every dish perfect. A bricklayer isn't perfectly aligning every brick.
Even in movie-making there's a shooting schedule. Things go wrong and the best filmmakers know how to keep the production moving.
I love the craft of programming, but I see a lot other craft-oriented programmers who want every line to be beautiful.
If you want to write code poetry in your off-time, that's your business. But that's not the job.
At work we are bricklayers and cooks. We practice a craft, but also have time constraints.
I try to do my best work while working at pace. Sometimes my code could be better, but it's not worth the time to fix. Ultimately the thing we make is the running software, not what's under the hood. The business people are sometimes right
Early errors are good, but I think the author overstates the importance of filtering out empty strings
---
I disagree that erroring out when the app doesn't have ALL the data is the best course of action. I imagine it depends a bit on the domain, but for most apps I've worked on it's better to show someone partial or empty data than an error.
Often the decision of what to do when the data is missing is best left up the the display component. "Don't show this div if string is empty", or show placeholder value.
---
Flip side, when writing an under the hood function, it often doesn't matter if the data is empty or not.
If I'm aggregating a list of fooBars, do I care if fooBarDisplayName is empty or not? When I'm writing tests and building test-data, needing to add a value for each string field is cumbersome.
Sometimes a field really really matters and should throw (an empty string ID is bad), but those are the exception and not the rule.
I was confused by why "use of AI" was a top-level requirement of this, but I see now that weave is AI-driven "engineering output measurement" company, down to the individual contributor level.
I can understand why you would have better luck hiring eager new-grads than seasoned engineers. I'm sure some IC find the weave stats useful, but it also sounds like a toxic manager's dream. I can understand why more senior engineers would steer clear.
I mean the answer is in the question--why are the self-driving cars (largely funded by billion-dollar private companies and VC) available in the same city as this anarchic public transit system (funded by largely by regional taxes and ridership fees)
Because it makes their technology seem more important and powerful?
Do you usually believe 100% what a company says about itself?
> Mythos export control issue, it's obviously not good for profits
Who cares about profits? None of these companies make money like a business currently. It's all speculative valuation and influenced by the same hype/doom cycle