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

121–130 of 430 posts

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

#121

Post by dec0dedab0de »

pc86 wrote: post #97
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…

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 an exaggeration, 14 repos for one project. It was originally built and managed by one person who had them all in the same directory and would open them all in his IDE at once and basically worked on it as a mono repo. After that person quit, when others needed to figure out which repo to clone to fix things it was a nightmare.

I know monorepos can be extreme like google, but I just mean one per team, or at least one per project. You shouldn't have to worry about versions of your libraries when there is only one project using those libraries.

Edit:

For example, a project I did the layout for has a python backend, with a spa frontend, and some ansible playbooks for deployment, integration tests, and a few libraries only used by this project.

Each of those 5 things has a top level directory and we deploy a test server for every branch, plus most of us run a local server. We never have to worry about versioning between our own projects, because if they're in the same branch that's the version to use. If we split it into separate repos, then everytime we added a new field to the api, and needed to update the frontend and tests, we would have to manually specify which versions of all the repos go together to build a test server, or to even run a local dev server.

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

#122

Post by gilbetron »

It's always been complex, and getting more complex, it is likely that you are just becoming aware of the complexity, when you thought it was simple. There's also the phenomenon of companies using tools/techniques that others are using without understanding why others are using them. I work for a company that needs k8s, kafka, and distributed systems. The previous company I worked for did not need that, at all, and so they didn't. The company before that didn't need them either, but thought they did and tried to move their single, relatively simple ETL pipeline to k8s, and it was a disaster.

But companies that need those tools, really, really need them. We don't use "nosql" (hate that term, it is a really dumb term anymore, sql use or not is completely orthogonal to the problem, "non-relational" or "non-OLTP" is better) databases because we think they are cool tech, we use them because traditional, relational, OLTP databases don't work for our use cases. But if someone comes to me and asks what database they should use, I always say "postgres", unless they can present a compelling reason postgres won't work.

The problems we face are tremendously complex, though, and only getting more complex. We fight back with tools, but there are years where the tools are failing to keep up.

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

#123

Post by erulabs »

Explicit tools are complex on the face - implicit tools are complex in implementation.

Kubernetes is complex and FTPing some rb files would be simpler: until one of about 145 different situations arises that kubernetes forced you to accord for ahead of time.

Whenever you find yourself complaining about the complexity of a tool: ask yourself “am I smarter than everyone in my industry, or do I possibly not understand the problem entirely?”

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

#124

Post by jokethrowaway »

pc86 wrote: post #106
mattmanser wrote: post #67

Earlier quoted context omitted.

No, it definitely has got worse, I've been doing this 15 years, the sweet spot was the Rails revolution. Before that a lot of frameworks were a bit too much magic, and not enough understanding of how browsers, http and html worked. Simple MVC stacks went to all languages, jQuery front-ends doing enough but not a lot. JavaScript enhanced easy to reason about server-side stacks. You used to spend a couple of days a yea…

Serious question - if it was so much better then, why are approximately zero new companies building a Laravel/Rails/whatever app and using jQuery for the front end? If it's that much of an advantage I would expect at least someone who is trying that (because surely some are) to succeed with their lean, mean tech stack. Why wouldn't you have just written the project in that standard MVC stack instead of a modern one?…

Indie makers famously do just that. Pieter Levels is making millions with PHP and jQuery.

I consult primarily in node and react with all sorts of transpilers mess and shitty packers. The stuff of nightmares - we waste so much time making things work - but simplifying the stack will never get traction among the not-anymore-technical principal engineers or even amongst the other developers who need a fancy cv for their next gig.

My side businesses use python, django, jQuery, old node.js without modules, rust, svelte.

Engineers hired in big companies want to work on shiny technologies and build their cv.

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

#125

Post by johnflan »

theirishgoodbuy wrote: post #34

The way I look at it is: there are more tools in the toolbox than ever before. Which makes our judgement (the thing they really pay us for) even more important. Kubernetes, for example, is a specific solution to a specific problem. The solution is complex but so is the problem. If k8s give you the right trade-offs for your situation, then it’s not busy work. Of course, there are plenty of project where judgement Is t…

the auld mortgage driven development strategy

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

#126

Post by zaphar »

pc86 wrote: post #97
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…

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.

Why does it seem worse? This is perhaps just each of our individual biases and values hiding behind a preference but I can't identify an objective reason why it's worse other than Jenkins or devtool of choice not handling it out of the box.

Don't get me wrong. CI/CD and other dev tools not handling monorepos well is a totally reasonable objective reason to not use monrepos. But it's also mostly about the tool not the monorepo concept itself.

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

#127

Post by jokethrowaway »

pc86 wrote: post #112
bko wrote: post #91

Earlier quoted context omitted.

> I recently worked on a project with 2 devs that took 3 months with a modern stack. The prototype in a standard MVC stack I'd made to demo to the client took 2 days. Can you expand on the modern stack and that standard stack? Is the "standard stack" you propose easier to work with now than it was 15 years ago? I guess the "standard stack" is just out of fashion? My preferred stack (aws serverless BE, nextjs front en…

Is being in one language really that much of a benefit? I've worked on several large production apps with node backends and I'd rather use almost any other backend language. And I take issue with saying you "have to know" GraphQL, that's a pretty specialized tool for pretty specific problems. Most things are not graph structures.

Maybe I'm biased because I've been using node.js for 10+ years but node.js has a decent API.

Simple, slightly opinionated. You just need to be careful of dependencies and what kool kids are doing these days. GraphQL is a complete nightmare.

If you don't transpile anything and are conservative with your dependency you're golden.

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

#128

Post by rollcat »

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…

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

The problem with deploying PHP is that it immediately gives you something for very little effort, but the effort scales incredibly disproportionately once you outgrow your need for the bare functioning minimum.

I personally prefer the "modern" approach of dropping a single, statically compiled binary, which exposes a listening HTTP socket. In case of Go or Rust+Actix, this could sit directly on port 80, but as soon as you add HTTPS, ACME, virtual hosts, etc the story is basically the same regardless of language/framework choice, PHP included.

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

#129

Post by mattmanser »

bko wrote: post #91
mattmanser wrote: post #67

Earlier quoted context omitted.

No, it definitely has got worse, I've been doing this 15 years, the sweet spot was the Rails revolution. Before that a lot of frameworks were a bit too much magic, and not enough understanding of how browsers, http and html worked. Simple MVC stacks went to all languages, jQuery front-ends doing enough but not a lot. JavaScript enhanced easy to reason about server-side stacks. You used to spend a couple of days a yea…

> I recently worked on a project with 2 devs that took 3 months with a modern stack. The prototype in a standard MVC stack I'd made to demo to the client took 2 days. Can you expand on the modern stack and that standard stack? Is the "standard stack" you propose easier to work with now than it was 15 years ago? I guess the "standard stack" is just out of fashion? My preferred stack (aws serverless BE, nextjs front en…

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 as you lose all your data, URLs dont work, etc., etc., etc. There's also all sorts of craziness like the whole admin frontend is bundled with the client-facing part as the front-end developer didn't know how to split them up.

Utterly preposterous.

The problem is often that very skilled Devs give advice about incredibly specific stacks that only someone of their abnormally high-skill level can maintain.

Throw in a few juniors or a few mediocre developers and the whole project turns into a complete and utter mess.

And don't get me started on your stack that's mainly inappropriate for most applications.

GraphQL. Talk about the next NoSQL fiasco in the making. Perhaps you missed the whole saga of everyone doing new development in NoSQL and then a few years later we had the flurry of blog posts about "Why are we losing data? I didn't realize ACID was so important..."

Post reply on HN