Live data from Hacker News

Uncomfortable Truths in Software Engineering

buttondown.email

31–40 of 400 posts

Re: Uncomfortable Truths in Software Engineering

#31
post #3

No. 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…

I'm honestly starting to feel like I transported back in time to my 1980's small town childhood, when the adults around me all blamed "Satan" for everything in the world they didn't like.

"Capitalism" has about as much to do with software performance as actual devil worship had to do with my Dungeons & Dragons or heavy metal cassettes.

And if your life as an engineer or user is "miserable" today, then I wish I could transport YOU to the 1980's. Yeah, existence is suffering... it sucks to be in the top 5% of household incomes, be inundated with open source platforms and tools that didn't exist too long ago, and a have a supercomputer in my jeans pocket.

Re: Uncomfortable Truths in Software Engineering

#33
post #17

Earlier quoted context omitted.

It's not capitalism, but the bad apples exploiting it.

Capitalism is a handful of people who own the means of production and the rest of us trying to get by. The bad apples exploiting it are the people who own the means of production, and saying they're the bad part of capitalism might as well be saying "capitalism is only bad because of what makes capitalism what it is".

> Capitalism is a handful of people who own the means of production and the rest of us trying to get by.

Well, good thing then that the "means of production" for software development consist of a 500€ laptop, which is well within reach of just about every programmer in the Western world.

Re: Uncomfortable Truths in Software Engineering

#35
post #6

There’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…

Number one, static type checking is hardly a "new tech" for which the industry is in a "newlywed period". If anything, it is the middle-aged wife that the industry's crawling back to, as the passion fades from its dynamic mistress dalliance. Secondly, the obvious counterexample here is MongoDB. Way too hyped-up during its honeymoon, and then almost immediately crapped on by the entire industry (to the point where we'…

You are right there is hardly a tech that hasn't existed in some form or shape since 1970s. Doesn't change my point (and nobody said newlyweds have to be on their first marriage).

Re: Uncomfortable Truths in Software Engineering

#36
post #6

There’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…

I think part of it is that there are suddenly a bunch of clear, actionable and measurable goals when doing a migration - so people can commit to progress, deliver on it and feel good about their accomplishments.

Re: Uncomfortable Truths in Software Engineering

#37
post #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.

great is a relative term. It's much better than feudalism, and certainly better than the most prominent socialisms that've been tried (USSR, China etc). However, it does not align incentives towards the things we think are "good", like maintaining open source software, securing software, etc - so it certainly isn't ideal.

Yea I mean nothing is perfect. While capitalism doesn’t lend well to maintaining open source software (which I find to be a surprising comment given that GitHub exists) it does lend well to things like having a house, or being able to save money for retirement, or to creating markets where you get products you want. YC for example has enabled lots of founders to create brand new companies and services we all use.

So I would definitely take the bad with the good here. The world’s most capitalist countries also have the highest standards of living (Norway, Sweden, etc.).

Re: Uncomfortable Truths in Software Engineering

#38
post #24
post #13

Earlier quoted context omitted.

Software is not charity. I will not work hard to deliver all those things out of the goodness of my heart. The ROI on those things isn’t great. If it’s easy to do I’ll do it, but none of those are trivial things.

I'll go further: I would love nothing more then some well-defined common standards to work towards. Weighty documents I can drop on product manager's desk and tell them the ways in which our customers and the government will legally have their way with them if we don't meet those requirements.

This is why I like working in highly-regulated industry. Technically correct is almost always what flies at the end of the day, because there certainly exists some audit item tracking the thing.

I absolutely loathe the audit process on one hand, but its a useful tool for getting everyone to play the same game on the other. It also means your solution is compliant in a lot of places if you can get it signed off in one.

Re: Uncomfortable Truths in Software Engineering

#39

I’d never heard of mobbing. That’s an awesome idea.

I am yet to see pairing work effectively for more than 20-30 minutes at a time, on a very specific problem, that really needs shared expertise. "Mobbing" sounds horrible 99% of the time.
Post reply on HN