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

381–390 of 430 posts

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

#381

Post by dimgl »

davzie wrote: post #209
dimgl wrote: post #162

I think you're overreacting (and I think the comments here are overly negative). Web tooling is better than ever. I can very quickly spin up a full-fledged production grade app with very little investment. I don't worry about blockchain or NoSQL or any of that. I just use tools that make me a productive engineer and that's ultimately what companies are interested in. If you're worried about recruiters asking you if y…

Even as a British person, I am not sure if this is sarcasm and a wonderful example of a satirical take or not.

If you want it to be satire, sure :D

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

#382

Post by arinlen »

viraptor wrote: post #11

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…

> At some scale getting a bigger machine either doesn't make financial sense or is just not possible to implement efficiently.

You don't even need to get scaling into the picture.

You do not get any form of fault tolerance by deploying stuff in a single lonely box. If you care about reliability and resilience, you have to have multiple deployments up and running at the same time.

Also, you already have a distributed system if you have a browser calling your server.

And lastly, if you happen to manage an service used globally or regionally and perceived performance matters then you have no good alternative to have regional deployments.

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

#383

Post by thomaslord »

rollcat wrote: post #342
jread wrote: post #287

Earlier quoted context omitted.

When did you last use PHP? It's not the PHP of 15 years ago. It scales fine when properly written and deployed.

I didn't mean scalability in terms of performance, but scalability in terms of maintenance effort. It's easy to SCP some files in, but the moment you want atomic deployments, it gets unnecessarily interesting.

PHP is the only language I've set up production environments for, but I can't see any reason why it would be more complicated than other languages.

I have a PHP project that handles atomic deployments by pointing the web server at a symlink named "latest". New versions get deployed into their own folder in the "versions" folder, and then the "latest" symlink gets pointed to the new version. Super simple to set up, and as long as you delete old versions as you go (keeping, say 3 versions so you can roll back as necessary) that's pretty much all there is to it. This all gets triggered by a Gitlab CI workflow, so I can hit a button to deploy after merging changes.

Another PHP-focused way to handle this would be deploying into a new folder, then updating the nginx config to point to that folder and running `service nginx restart`.

You can also use one of the many other atomic deployment options that replace more than just the running code, at which point the only difference between deploying a PHP webapp and deploying a Java/Go/Rust webapp is what gets included in your new server/container when you build it.

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

#384

Post by quanticle »

taylodl wrote: post #354
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…

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…

Go to your favorite cloud console and provision it.Better yet, use a serverless architecture and don't even worry about servers! Your own data center? Right now there's a 4-6 month wait time for new servers and storage equipment, and an 8-12 month wait time for networking equipment. Not exactly agile, is it?

Sure, that all works, as long as you have infinite money. My last job was at a company that was heavily invested into a serverless architecture, using the full suite of AWS tooling. They did an audit of one of their codebases and they found that generating a particular piece of data cost $20, almost entirely in fees to AWS. The company's roadmap involved scaling up the generation of this data, so they embarked on a huge process of optimizing and refactoring, to try to get the cost down. This effort tied up probably 40-45 engineers for at least six months. Probably cost them roughly 3 million dollars in salary alone, let alone opportunity cost in terms of other projects not delivered. No one amongst the management ever seriously considered moving to an on-prem solution, even though it was blatantly clear that the only value the company's massive usage of AWS Lambda, SQS, RDS and other managed services was delivering was additional profit margin for Amazon's balance sheet, and resume line items for the engineers who now got to check off the "used Terraform" box when applying to their next job.

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

#385

Post by hcrean »

dec0dedab0de wrote: post #52

I generally agree, but two things I'd like to point out. If you're using python for the web you're already part of the complexity problem, atleast from the perspective of someone deploying php 15 years ago. I use python for web development, and I love it, but deploying webpages used to be copy an apache config and ftp/scp your files to some location. Now we need app servers and reverse proxies, and static files are s…

I have just finished three years of beating a department of 50 developers into breaking up a fifteen year old mono-repo. The rewards have been quite considerable.

Mono repos come with a particular challenge: If you have five projects {A,B,C,D,E} in the same mono-repo, you definitely do not want to be building B,C,D and E every-time someone commits code to project A! This is unimportant at small scales, but as the team grows, building and continuously deploying 'all the things' on every commit just doesn't work out.

So the first naive solution is say "we can enumerate all the things that need to be built for project A". This rapidly breaks down when someone figures out they can abstract a shared dependency for A,B and D into some other part of the mono-repo.

So now we enter build dependency tools, first Make then some other flavour, then we jump straight to Bazel because someone read about it in a Google publication, then to some custom build scripting because Bazel didn't do this hyper-specific workflow thing someone wanted... In the end maintaining a mono-repo build process becomes a hyper-specialised job function that is almost always kicked to the wayside.

In small companies, fewer developers than you can count on your fingers, or truly huge Googles that have their own VCS flavour, it can be shown to work well: But I have yet to hear a story of something in the middle succeeding with a mono-repo.

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

#386

Post by sakesun »

tabtab wrote: post #284

I rant about the excess complexity of our CRUD dev tools all the time. Example: https://news.ycombinator.com/item?id=31217253#31240227 It's roughly 3x the complexity and labor compared to the 1990's desktop-oriented IDE's like VB, Delphi, PowerBuilder, Clarion, FileMakerPro, etc. I realize deployment (installing, updating) was harder compared to web apps, but I'm not sure it has to be either-or in terms of simplifyin…

Wholeheartedly agree.

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

#387

Post by selfhoster11 »

bko wrote: post #6

I don't disagree with you and your examples are definitely over-engineering / busy work. In my experience a lot of it is driven by the desire for young engineers to learn a new language. If someone paid me to move something to Rust, I would do it. I heard good things about Rust and I would love to get paid to learn it. But has being a software engineer become easier or harder over the last 30, 20, 10, 5 years? I wasn…

> I wasn't an engineer for that long but my impression is that programming today is a lot easier. Dev tools, compilers and linters are very good.

What sticks out to me when I'm looking at some older code editors/IDEs, is how crazily spartan they are - to the point where they are just inconvenient to use.

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

#388

Post by gfodor »

phkahler wrote: post #340
gfodor wrote: post #183

Earlier quoted context omitted.

I’ve never liked this best-tool-for-the-job mental model with software engineering. A given project has multiple needs, and unlike more physical tools there is a very high marginal cost for each incremental tool you use. So there is a huge balance between many well suited tools or a few but more generalized, less fit tools. This isn’t to say there’s an obvious place where to strike the balance, but the “best tool for…

>> I’ve never liked this best-tool-for-the-job mental model with software engineering. I don't either. As photographers say, the best camera is the one you have with you. Same thing, the best tool for the software job is the one you already have and everyone knows how to use. Why anyone would want to introduce these high-end fads to an organization without proper reasoning is beyond me.

That’s definitely part of it. Another part is just the various multipliers you get from having a small number of tools. Team mastery, more mobility of personnel (no/low ramp up times), unexpected opportunities for re-use, high quality onboarding due to narrow scope, etc.

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

#389

Post by t312227 »

hardee wrote: post #375
rollcat wrote: post #342

Earlier quoted context omitted.

I didn't mean scalability in terms of performance, but scalability in terms of maintenance effort. It's easy to SCP some files in, but the moment you want atomic deployments, it gets unnecessarily interesting.

Atomic deployments with PHP is basically as simple as "git pull" in a temporary working directory and copying it to a release directory..

for your "personal blog" git pull can be used as deployment - don't forget to exclude the access to the .git directory in .htaccess ...

but for "serious" applications / deployment-routines this is never an option ... you have to use some kind of deployment & configuration mechanism.

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

#390

Post by mattmanser »

native_samples wrote: post #351
mattmanser wrote: post #129

Earlier quoted context omitted.

In that case it was a simple .Net core MVC stack, Vs an angular/Web API stack. For some inscrutable reason you can no longer do a simple 3 page form with a results page without making a SPA these days without getting someone claiming you're doing it wrong, it's nuts. Worse still, the angular app has all sorts of weird bugs. Auto-complete somehow screws with the validation of inputs, back button doesn't work properly…

What is it you don't like about GraphQL? It seems to do what it was designed to do pretty well. I take it the issue is more with the pseudo-databases it's used as a front-end for?

Because it's now the 'right' way to do data.

Even though it's not 90% of the time.

Post reply on HN