Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Have we screwed ourselves as software engineers?

news.ycombinator.com

Post reply on HN
Print view View original

271–280 of 430 posts

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

#271

Post by pipeline_peak »

There are two separate arguments here, that growing complexity in software stacks is bad and adopting modern languages is redundant.

I don't know where you work, but the majority of enterprise jobs out there have always been focused on what's dominant in the industry. Today that is, as you say, Blockchain, NoSql, crypto, and micro-frontends, etc. While hearing trendy words like that make me want to hurl, that's how these run of the mill companies operate. They don't have time for an optimal bare bones approach, or building things from scratch. Again I could be completely wrong, maybe you work somewhere really cool that does more exciting work outside of business logic, react development, and dockers that dock other dockers into kloud goobernety docker sockets. But the point I'm trying to make is 90% of tech companies aren't very pretty, and as I'm sure you know that's part of why they pay so well and are stable.

Non developers in tech like recruiters always seem to focus on new languages as if they're inherently better. And in some ways they're unwittingly right, there's less issues with backwards compatibility at least, thus more room for new features that eventually become concerning backwards compatibilities. And of course in some ways they're wrong, newer languages are less mature, and some argue that programming hasn't really changed since the 70's. This isn't very reassuring when compelling features are GC, serialization, concurrency, and really dumb things like attractive syntax sugar that you care less about when you're in the woodwork anyway.

That Python to Rust talk does sound kind of stupid though. Almost like a higher up with enough power to make subordinates listen to them ramble about their favorite sports team programming language. I almost want to guess that whatever it was could've been done in C++ 20 years ago, but like I said, language wars are stupid and trivial. Interpreted languages are slower though, but that's pretty obvious.

I don't think we're screwing ourselves into something we're locked into, these are just dominant in enterprise roles.

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

#272

Post by tomc1985 »

goodpoint wrote: post #236
tomc1985 wrote: post #181

Earlier quoted context omitted.

There's a finance angle behind cloud stuff too that's irrestible for the bean counters: cloud stuff is operations expense, on-prem is a capital expense. Unfortunately these folks are heavily incentivized to favor OpEx I'm not a bean counter, all I know is those guys at my last job would rattle off about it like zombies. IIRC its a tax thing

Wrong. People has been leasing on-prem hardware for decades before the cloud existed. Depending on taxation rules you might want to buy or lease.

At this employer it seems most of the stuff in their datacenter was purchased.

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

#274

Post by psyc »

There’s no ‘we’. We don’t coordinate. We don’t design up front. Did Brendan Eich consult ‘us’ before he unilaterally made JavaScript the fucking ‘assembly language of the web’ for the following 25 years? No, he just got it in there, and the whole industry that burgeoned afterwards did whatever they could with what was already there. Who has time (or clout) to design a sane application stack and appropriate tools, when there’s money to be made?

There’s no we. There’s a million moths slapping into everything and being drawn to various bright, often false, lights.

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

#275

Post by deltaonefour »

ushakov wrote: post #158
ptudan wrote: post #150

Earlier quoted context omitted.

Three object oriented languages prove how there's sentiment against OOP? Or are you saying that Rust/Golang/React are simplistic in a world of over complexity. React I would generally agree with, the other two not really.

React is extremely complex internally

I think react was an attempt at simplification. OOP isn't the only thing that influences complexity. Simply switching a project from OOP to a more FP like paradigm doesn't necessarily make the framework simpler because of other confounding factors.

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

#276

Post by theirishgoodbuy »

reaperducer wrote: post #108
i_like_waiting wrote: post #75

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…

I see everybody around me moving to cloud, without really good explanation why. People just buy into the "cloud" marketing. They don't have the ability to think and reason, and so don't understand that "cloud" just means "renting someone else's computer." I built a complex in-house medical system. Quick, reliable, and liked by the users. I was in the middle of adding a major new feature when all of the management in…

At the risk of sounding cultish: I would argue “the cloud” is a bit more than just renting someone else’s computer. Hosting companies existed long before the “cloud”.

The difference is the abstraction layer. I would define “the cloud” as a layer that abstracts away the physical infrastructure. (Which works until it doesn’t but that’s a longer comment.)

You can even apply “the cloud” to your very own fleet of computers with the right software.

Like I said in the original comment, it’s a specific solution to a specific problem. Whether it’s right for your system I have no idea.

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

#277

Post by thebean11 »

dec0dedab0de wrote: post #121
pc86 wrote: post #97

Earlier quoted context omitted.

Regardless of how you're deploying things, having unrelated projects in the same git repository might be simpler (maybe?) but certainly seems worse at the same time.

Regardless of how you're deploying things, having unrelated projects in the same git repository might be simpler (maybe?) but certainly seems worse at the same time. Sure, if they're actually unrelated, or being managed by separate teams then split it up. Though I think the default should be to have one, and split it when there is an actual reason to, especially if it's for the same project. The example I gave wasn't…

> Sure, if they're actually unrelated, or being managed by separate teams then split it up

What if they become managed by separate teams? Or two projects in separate repos become managed by the same team? What about a service that basically everything else in the company relies on (for Google, accounts and auth for example).

Better to just keep things in a monorepo IMO, even if they seem unrelated.

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

#278

Post by jamesmcintyre »

Does software evolve? Do we evolve it?

1. Legacy codebases accumulate not only a ton of "normal" tech debt but larger codebases within larger orgs have the battle scars of a sort of "forced evolution". Bandaids on bandaids, pulling in new frameworks and patterns all requiring often heavy transplants. Like a future archaeologist finding artifacts of the steam engine, combustion engine, nuclear reactors and lithium batteries you can infer the good intentions but unlike the original implementors you can clearly see, with hindsight's 20/20, the "unforeseen" side effects they couldn't (or were just incentivized not to). Unlike those societal-scale energy innovations the microcosm of human engineering optimism and naïveté that is your organization's legacy codebase had a more rushed "artificial" evolution that was likely a casualty of the kind of short-sighted, rushed product-roadmap dynamics we're all too familiar with. Less a million-year evolved shark and more a "cute" purebred pug. Can we go right to the shark? Probably not. We'll make hundreds of thousands of pugs before we ever get to the shark. In the meantime the optimist will see these pugs as forcing-functions that help evolve the encompassing ecosystem at-large to be more conducive for the entrant of a "shark".

2. You ask "have we screwed ourselves?" and I think this might imply too much confidence in the perception of how "separate" we are from these iterative codebases. To go back to the evolution metaphors, we're just introducing mutations under real-world conditions. Each product of that evolution is a reflection of those conditions more so than the potentially great ideals any single stimuli in the petri dish possessed at the time she took part in the engineering. By the very nature of large-scale, cooperative engineering we bake-in our collective foibles and the engineering disciplines we hold at any given time are just one, usually smaller, dynamic at play.

3. I may sound pessimistic, over-deterministic or that I think our efforts are futile in light of larger dynamics but I'm not, I'm sipping coffee right now, I'm good. Acknowledging that we have an outsized perception of our affect in these situations may help relinquish you from the oftentimes infuriating pain that accompanies the mundane banalities of daily software engineering. Champion the better ideas, sure, but maybe with a good-humored flexibility that comes from knowing today's great ideas are just memes bootstrapping the evolution of tomorrow's much greater ideas and in this chaotic soup there's some beauty.

Trust me, this is not the Zen outlook I'm able to stay within at all times (or even most of the time) but I want to try to and also remind myself why I thought all this software stuff was cool in the first place. I'll end with a quote I'm reminded of.

“For the simplicity on this side of complexity, I wouldn't give you a fig. But for the simplicity on the other side of complexity, for that I would give you anything I have.” ― Oliver Wendell Holmes

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

#279

Post by biorach »

tomc1985 wrote: post #199
biorach wrote: post #107

Earlier quoted context omitted.

People still do deploy production ready systems using RoR, Django/Python or whatever "sweet spot" framework you want to mention. Some run quite successful businesses. You can't generalise from your experience over the last few months. > Programming used to be about writing code to solve business problems. The shift to DevOps has been a massive productivity drain and most stacks are now incredibly brittle. Some busine…

God I am sick of these apologetics every time someone expresses skepticism. > Get it wrong another way and you end up overwhelmed by traffic, unable to scale in response and forever fighting fires. To nitpick this specifically, over my 12-year career toiling over this stuff there has never been a scenario where this has required a radical rework to solve. Boring-ass B2B shit rarely requires that level of engineering…

> God I am sick of these apologetics every time someone expresses skepticism

That's a highly obnoxious response to a measured and reasonable comment.

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

#280

Post by dec0dedab0de »

winrid wrote: post #216
dec0dedab0de wrote: post #176

Earlier quoted context omitted.

Oh I agree, I still get chills when I think about troubleshooting PHP. I was really just making the point that the effort to deploy python as a webapp these days would have been considered overly complex to the average developer 15 years ago. Just how some of the current stuff seems to the OP, so maybe not all seemingly complex stuff is bad.

The debugging story around PHP is better than other major scripting runtimes like Node. With PHP and kcachegrind you can really understand where you're spending CPU easily. The tools for Node work but just aren't there yet. Another nice combo is Java + Mission Control.

The debugging story around PHP is better than other major scripting runtimes like Node. With PHP and kcachegrind you can really understand where you're spending CPU easily. The tools for Node work but just aren't there yet. Another nice combo is Java + Mission Control.

Fair enough, but I was thinking more along the lines of debugging logic. With python I can open up a local repl or jupyter, run the affected functions/methods, and from there I can get a nice traceback, modify code, or monkey patch something to figure it out. If I can't reproduce the bug locally, I can run a repl directly on the server to see how the code runs differently.

My frustration with PHP is just memories of making an edit, refreshing the page, and crossing my fingers. Then once it's working forgetting to save it anywhere else because there wasn't a repo to begin with. I know the tooling has got much better, and PHP developers actually use deployment pipelines these days, and it was mostly caused by myself, and my co-workers not knowing any better. Still just how I remember it. And I don't think I'm the only one.

Post reply on HN