Live data from Hacker News

Ask HN: Have we screwed ourselves as software engineers?

news.ycombinator.com

361–370 of 430 posts

Re: Ask HN: Have we screwed ourselves as software engineers?

#361

If you believe that's all there is to those ideas, maybe you need to step away and think about them for a while. Sure, there's going to be some resume padding happening in larger orgs. But all those ideas solve real problems too. I think you're just in a very negative space if you start with "Distributed systems" as something overly complicated. At some scale getting a bigger machine either doesn't make financial sen…

> But all those ideas solve real problems too. All of them, except for blockchain. That one can go die on the trash heap of history.

I'll never understand the bitter hatred toward blockchain at hackernews. Are you guys just mad you knew about bitcoin when it first started but didn't get any? You can't possibly truly believe blockchain solves zero problems can you?

Re: Ask HN: Have we screwed ourselves as software engineers?

#362
post #157

Software Engineers are generally intelligent people. Intelligent animals need stimulation or they get bored and depressed. I think collectively, "let's move to Rust" is at least partially because we're not challenged enough by writing the same CRUD app for the 20th time in the same language we've been using for the last 5-10 years, and we want to leave our mark in a new ecosystem by implementing whatever is missing.…

On the web backend side, I find that rust has a nice future in support of other backend. considering the difficulty to manage websocket in PHP or memory with NodeJs.

Re: Ask HN: Have we screwed ourselves as software engineers?

#363

Earlier quoted context omitted.

Promotion based architecture is self fulfilling prophecy at least in BI/ data world. I see everybody around me moving to cloud, without really good explanation why. Only reasonable thing I can see as an pattern is that cloud experience on top of data things gets paid 30% more. It made me consider cloud a lot. I was considering switching to cloud, just so I can put in my CV "experience with migration to cloud". For ne…

No one has given you a good explanation for why to move to the cloud? Let me fix that for you! :) I work for a Fortune 200 company who has their own data centers and has for decades. We just completed the construction of two new data centers about four years ago at a cost of $110 million dollars. Those new data centers are now at 70% of their capacity for power requirements . You should take a look at the specs on In…

Open source clearly does not mean packaging your own software. This casts a shadow of doubt on the rest of your valid points.

Re: Ask HN: Have we screwed ourselves as software engineers?

#364
post #322

Earlier quoted context omitted.

I like the analogy, but it strikes me as missing the upside (and other potential causes of problems the author may be seeing). Bisquick is a great solution if you have only one problem. I want more solutions like Bisquick: easy to map to the problem (pancakes -> Bisquick; not pancakes -> not Bisquick), hard to fuck up, low marginal cost above the inputs. It's great! In the converse, we have lots of custom software so…

I think you're speaking to a different (but still legit) problem. The OP is asking about the nature of confusing complexity, as it might appear to a new programmer. The capital implications of making real, profitable software from interlocking systems of alchemy is indeed not a solved problem - but I would say that it's interesting point of alignment between capitalists and beginner software programmers! Everyone wan…

> Everyone wants lower maintenance costs, in terms of both time and brainpower. The $500k+ FAANG superstar programmer is a byproduct of the fact that alchemy is much harder to master than chemistry.

I think I've lost the analogy here a bit, could you help me? I thought "alchemy" were general purpose systems meant to get you off the ground.

I'm nominally one of these "$500k+ FAANG superstars" (though I'm not actually a superstar) and nearly all of our engineering time is spent wrangling home-grown abstractions built specifically for our business needs, which don't feel like "alchemy" in this analogy. Certainly a few teams are more involved with AWS services, linux, and dev-tooling but that constitutes maybe 5% of the company.

Would you still describe this other 95% as "alchemy"? If so, why?

Re: Ask HN: Have we screwed ourselves as software engineers?

#365

You are experiencing what I call "The Bisquick Problem". Bisquick is basically flour with some other stuff, like salt, premixed into it, and sold in a box in the USA. So instead of just buying flour and salt, you buy them together, which makes some things easier (like making pancakes), but it complicates literally everything else. You can't use it as flour, or as salt. With software, the problem is even greater. You…

This is a very helpful view on things. It definitely seems like evolution is taking place. Many of the new solutions are a mixture of other solutions with a certain aspect being the most important. NextJs, Remix, RedwoodJs are all its own solution in adding what the creators feel are missing from React in terms of server side functionality. Eventually there will be a clearer picture of which tool to use for various t…

The problem usually isn't the next layer of abstraction. NextJs and Remix are just fine (I don't have experience with RedwoodJs). The issue is that developers tend to put "Here be dragons!" in their mental map of whatever is two levels down the abstraction chain from where they live.

When those layers are small additions, people end up not understanding (or even fearing) components of their stack that are quite close to the surface. It's hard to do quality software engineering when you can't reason about the foundation of what you're building.

But if you lived through the process of adding new layers or if you take the time to learn more layers of your stack, you'll be able to make the most of the tradeoffs inherent to adding the latest framework or library.

Re: Ask HN: Have we screwed ourselves as software engineers?

#366

You are experiencing what I call "The Bisquick Problem". Bisquick is basically flour with some other stuff, like salt, premixed into it, and sold in a box in the USA. So instead of just buying flour and salt, you buy them together, which makes some things easier (like making pancakes), but it complicates literally everything else. You can't use it as flour, or as salt. With software, the problem is even greater. You…

This is a very helpful view on things. It definitely seems like evolution is taking place. Many of the new solutions are a mixture of other solutions with a certain aspect being the most important. NextJs, Remix, RedwoodJs are all its own solution in adding what the creators feel are missing from React in terms of server side functionality. Eventually there will be a clearer picture of which tool to use for various t…

They say the only two ways in business to make money are bundling and unbundling. This is surprisingly applicable to software frameworks as well.

Re: Ask HN: Have we screwed ourselves as software engineers?

#367

Earlier quoted context omitted.

No one has given you a good explanation for why to move to the cloud? Let me fix that for you! :) I work for a Fortune 200 company who has their own data centers and has for decades. We just completed the construction of two new data centers about four years ago at a cost of $110 million dollars. Those new data centers are now at 70% of their capacity for power requirements . You should take a look at the specs on In…

Open source clearly does not mean packaging your own software. This casts a shadow of doubt on the rest of your valid points.

It does if you're not paying for it. There are plenty of companies that will gladly handle the packaging, assure all the interdependencies work well together, and even support the effort. They also do release management, ensuring that everything is on the most recent version that all works together. That has a cost. You can either pay someone to handle that work for you (smart - you and many other companies are sharing that cost) or you can do that work yourself (not so smart - now you shoulder all the costs).

Just as an example, consider Hadoop and its ecosystem. Another example is Elasticsearch. There's work involved in making these platforms production-ready and keeping them and their dependencies up-to-date and ensuring all your applications in your portfolio are using the same set of software. Most organizations are not prepared to take that on. So they turn to a vendor who will do it for them for much cheaper than they could do it themselves.

That's why the saying is "free as in freedom, not free as in beer" because open source software is not free as in beer. At least not when factoring in the total costs.

Re: Ask HN: Have we screwed ourselves as software engineers?

#368

Earlier quoted context omitted.

I think you're speaking to a different (but still legit) problem. The OP is asking about the nature of confusing complexity, as it might appear to a new programmer. The capital implications of making real, profitable software from interlocking systems of alchemy is indeed not a solved problem - but I would say that it's interesting point of alignment between capitalists and beginner software programmers! Everyone wan…

> Everyone wants lower maintenance costs, in terms of both time and brainpower. The $500k+ FAANG superstar programmer is a byproduct of the fact that alchemy is much harder to master than chemistry. I think I've lost the analogy here a bit, could you help me? I thought "alchemy" were general purpose systems meant to get you off the ground. I'm nominally one of these "$500k+ FAANG superstars" (though I'm not actually…

I would say that you've paid the opportunity cost of learning the interlocking systems that compose into your application, and the processes required to update, test, and deploy it. This composition occurs across various boundaries, inside and outside the process, the network, and so on.

The FAANG-ist is one that can pay that opportunity cost quickly and completely, such that they are able to reason about the system with confidence, particularly when it comes time to reverse a feature or bug request into a set of commits. Or, more likely, a set of experiments and commits based on the outcome of those experiments. Given that there is no unified language of application design, doing this requires detailed, specific knowledge of every sub-system involved, the abstractions their authors used, and the ability to translate between them such that you can imagine the entire causal change from input to output. This is hard, and it's why you make the big bucks. (Interestingly, I first wrote "bugs" instead of "bucks". :)

Re: Ask HN: Have we screwed ourselves as software engineers?

#369

Earlier quoted context omitted.

> Everyone wants lower maintenance costs, in terms of both time and brainpower. The $500k+ FAANG superstar programmer is a byproduct of the fact that alchemy is much harder to master than chemistry. I think I've lost the analogy here a bit, could you help me? I thought "alchemy" were general purpose systems meant to get you off the ground. I'm nominally one of these "$500k+ FAANG superstars" (though I'm not actually…

I would say that you've paid the opportunity cost of learning the interlocking systems that compose into your application, and the processes required to update, test, and deploy it. This composition occurs across various boundaries, inside and outside the process, the network, and so on. The FAANG-ist is one that can pay that opportunity cost quickly and completely, such that they are able to reason about the system…

I think I understand your perspective now, thank you for such a good explanation! Also, my bugs are indeed big /crying

Re: Ask HN: Have we screwed ourselves as software engineers?

#370
post #327

Earlier quoted context omitted.

> There are many complex systems that maintain or increase their complexity. Increased complexity is only achieved with additional energy input. im suggesting that if energy (read: money) going into the system decreases rather than increases, there will be a reduction in complexity.

Consider a counterexample: an open source project that loses favor / funding / contributors. Does it become less complex? Probably not.

when it comes to software, it is easier to engineer a complex solution over a simple one. so in that sense, i would agree with you.
Post reply on HN