Uncomfortable Truths in Software Engineering
buttondown.email
Uncomfortable Truths in Software Engineering
1–10 of 400 posts
Re: Uncomfortable Truths in Software Engineering
#2I really like this list, they all resonate with my own experience, I’ve been in both sides of many items (zealot became cynical)
Re: Uncomfortable Truths in Software Engineering
#3No. 13 is gold:
> We’re never going to get the broader SE culture to care about things like performance, compatibility, accessibility, security, or privacy, at least not without legal regulations that are enforced. And regulations are written in blood, so we’ll only get enforced legal regulations after a lack of accessibility kills people.
Sorry, can't help but blame capitalism for saying "fuck performance, compatibility, accessibility, security, and privacy" and making the lives of engineers (and users) miserable.
Re: Uncomfortable Truths in Software Engineering
#4No. 13 is gold: > We’re never going to get the broader SE culture to care about things like performance, compatibility, accessibility, security, or privacy, at least not without legal regulations that are enforced. And regulations are written in blood, so we’ll only get enforced legal regulations after a lack of accessibility kills people. Sorry, can't help but blame capitalism for saying "fuck performance, compatibi…
It's not capitalism, but the bad apples exploiting it.
Re: Uncomfortable Truths in Software Engineering
#5>The open source maintainer problem isn’t going to get much better in the near future.
>People are gonna keep blaming “Capitalism” for this.
Capitalism is great, there really is no need to defend it at every opportunity, especially if no one is attacking it.
Re: Uncomfortable Truths in Software Engineering
#6There’s no rigorous academic evidence for this, but a lot of companies have been backporting typescript/mypy/sorbet onto existing dynamic codebases and the case studies have been overwhelmingly positive.
Not to be a buzzkill, but migration reports from any tech A to tech B are always overwhelmingly positive when the industry has a newlywed period with tech B. Save for a clear, undeniable failure the stakeholders will always claim success.
Re: Uncomfortable Truths in Software Engineering
#7No. 13 is gold: > We’re never going to get the broader SE culture to care about things like performance, compatibility, accessibility, security, or privacy, at least not without legal regulations that are enforced. And regulations are written in blood, so we’ll only get enforced legal regulations after a lack of accessibility kills people. Sorry, can't help but blame capitalism for saying "fuck performance, compatibi…
It's not capitalism, but the bad apples exploiting it.
[deleted]
Re: Uncomfortable Truths in Software Engineering
#8No. 13 is gold: > We’re never going to get the broader SE culture to care about things like performance, compatibility, accessibility, security, or privacy, at least not without legal regulations that are enforced. And regulations are written in blood, so we’ll only get enforced legal regulations after a lack of accessibility kills people. Sorry, can't help but blame capitalism for saying "fuck performance, compatibi…
It's not capitalism, but the bad apples exploiting it.
if it's a near-universal problem, it's not "bad apples" it's bad incentives. IE, capitalism.
Re: Uncomfortable Truths in Software Engineering
#9No. 13 is gold: > We’re never going to get the broader SE culture to care about things like performance, compatibility, accessibility, security, or privacy, at least not without legal regulations that are enforced. And regulations are written in blood, so we’ll only get enforced legal regulations after a lack of accessibility kills people. Sorry, can't help but blame capitalism for saying "fuck performance, compatibi…
It's not capitalism, but the bad apples exploiting it.
Bad environments make bad apples.
Re: Uncomfortable Truths in Software Engineering
#10Re. 3 & 5: my theory is that a language with gradual typing, gradual error handling enforcement, and "gradual proving" that is seamlessly embedded in it (see e.g. the https://nim-lang.org/docs/drnim.html experiment) could hopefully actually work here. And as to dynamic typing, I found it useful when prototyping, to quickly PoC/MVP the "happy path" of an idea/design, and see if it is worth investing any bigger effort, or just completely crap. Ideally I'd then (gradually) enable (or, "un-disable") statical typing, error handling enforcement, and formal proving. Question is, can anyone design & implement a language that would have all of that, and still be readable and understandable to a common programmer (like me).
Re. 6: for API design, I have some (feeble) hopes behind https://aip.dev; as to the rest, I have immense hopes behind https://enso.org