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

301–310 of 430 posts

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

#301

Post by dec0dedab0de »

thebean11 wrote: post #277
dec0dedab0de wrote: post #121

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

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.

If there are multiple teams committing to the same repo you need controls over who has permission to commit to which directories and maybe a policy for handling merge conflicts across teams. I'm not sure what the tooling is like around that, but I could see the benefits as long as someone very high up was on board and had enough of a technical mind to keep order.

As far as two repos becoming one or one repo becoming two, you can split and merge repos while keeping the commit history.

edit: Do you have experience working somewhere with a monorepo that stretched across multiple teams? if so, what was it like?

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

#302

Post by i_like_waiting »

dtech wrote: post #267
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…

It's a bit dismissive to just focus on scaling as a cloud advantage. You also have lower maintenance, easier redundancy, lower chance of outages, easier backup and more such non-functionals. A 200GB DB costs about $50/month on AWS (other providers are less), that's not an interesting amount of money for most businesses.

Thats way off. With 64gb ram we have around $50 month on hetzner yes. But from asking around the other BU with very similar size and usage to ours, somehow they are paying around $2600-5000/ month on azure

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

#304

Post by maerF0x0 »

graderjs wrote: post #28

It's another way to favor incumbents with huge resources: it's an anti-competitive psyop to raise barriers to entry and stymie startups in endless shiny thing chasing, because the incumbents are scared of the disruption, so those big players that move a bit slower, seek ways to slow down the scrappy players that can move fast, while those "fast movers" get drunk on the koolaid of buzzwords manufactured on blogs from…

> nobody's allowed to question it otherwise it's civil flame war.

With enough years in this industry I'm starting to see how much of the culture is just "cargo cult Silicone[sic] Valley!" -- People are doing things just because the latest/greatest unicorn did it that way, and frequently there is a form of Zen/Chan disregard of meaning or learnings from the past. "Move fast and break things" often plays out as "Disregard knowledge and act like there wont be consequences" . I frequently see threads/posts on HN by experienced people laughing that "we've known this since the 70s" in reference to The Mythical Man Month, or other bits from Computer Science, and yet most managers think they know better than decades of industry experience.

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

#305

Post by tabtab »

deltaonefour wrote: post #258
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.

All three are moving away from OOP. Functional components in react. Zero classes in golang or Rust. It's actually quite an obvious paradigm shift. No classes with these languages yet every language prior to this has classes. Yet I don't understand why people still insist on calling go and rust object oriented or why they try to argue this point when there is such an obvious change. I mean sure you can twist the langu…

Functional can be tricky to debug, as the frowned-on "intermediate state" of imperative programming makes for great x-ray examination points during debugging.

The backlash against OOP is partly because existing OOP engines are limiting in many languages. Passing, grouping, and custom-scoping of "blocks of code" (BOC) should be more flexible so that we are not forced into hierarchies or spaghetti scoping. We need new languages that make managing and scoping BOC more flexible. I want to define the scope, not let Nadella or Bezos do it. The distinction between a lambda and method would then be fuzzier. BOC's would no longer be forced to be one or the other. (One these days I may make a proof-of-concept language.)

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

#306

Post by tabtab »

api wrote: post #42

It’s hard for managers sometimes to keep this stuff out even if they want to. Engineers like to play with tools and always always always over-engineer. I try hard to walk my talk here but I catch myself doing it too. Simplicity is much harder than complexity. It requires more thought and deeper conceptual integration. Right now I am rethinking some older things and trying very hard not to second system effect it. On…

> Simplicity is much harder than complexity.

Amen!!! The skill of practical parsimony is way under-valued. Warren Buffett said one of his top "skills" is saying "no" to financial gimmicks and peer pressure.

Somebody e-shoot the packrats.

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

#307

Post by brightball »

0xdeadbeefbabe wrote: post #265
brightball wrote: post #117

I think the market is always right. As complexity increases in areas as you describe, it will create opportunities for solutions that simplify things. IMO, it's one of the reasons that Phoenix LiveView is so appealing for people because it removes so much complexity from building otherwise complex tooling. I actually just had to come face to face with this because I've been developing a lesson plan to teach my son to…

> I think the market is always right. How long does it take to be always right? A lot of these comments at best imply significant lag, and at worst imply the market is perversely wrong.

It means that enough options exist to solve the use cases that people have and if there's any type of gap that isn't being addressed, enough people will see the opportunity and address it. People will flock to that solution if they feel it's beneficial.

Pretty much always works if there's not interference.

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

#308

Post by thebean11 »

dec0dedab0de wrote: post #301
thebean11 wrote: post #277

Earlier quoted context omitted.

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

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. If there are multiple teams committing to the same repo you need controls over who has permission to commit t…

> As far as two repos becoming one or one repo becoming two, you can split and merge repos while keeping the commit history.

I don't have experience doing that but it sounds like a huge headache to me. Any tooling, deployment processes, links in documentation, cross-repo references etc would need to be updated right?

The company I was in before my current one used a mono-repo for the whole company, I thought it was pretty great! We had ~150 engineers, so not Google-scale but still many individual teams and services. Similar to the Google strategy, a pull request / code review would be against master, and then it would be merged directly to master. The tooling would automatically rebase your change on master before merging. Deployment would happen automatically or manually (the team could decide) and would be pinned to a git commit hash. If automatic, the CI tool would detect if there were any changes to your binary that required deployment (so a totally unrelated PR would not trigger a deploy). You could manually deploy an older commit hash if you wanted.

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

#309

Post by RiyaadhABR »

javajosh wrote: post #159

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 tasks like internal tools, eCommerce, B2B or cross platform applications.

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

#310

Post by l30n4da5 »

mattmanser wrote: post #67
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…

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…

> Moving everything into hard to debug http calls has been a disastrous productivity sink.

I'll admit for the vast majority of web apps out there, this is not needed, but there is definitely a scalability concern if your entire stack is a single ruby on rails mvc application.

Post reply on HN