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

In Defense of Simple Architectures (2022)

danluu.com

Post reply on HN
Print view View original

151–160 of 447 posts

Re: In Defense of Simple Architectures (2022)

#151

Post by bluGill »

devjab wrote: post #131
bluGill wrote: post #120

Earlier quoted context omitted.

Building like NetFlix is better than random unguided architectures that result from not thinking. It might not be the best for your problem though. If you don't need thousands of servers, then the complexity that Netflix has to put into their architecture to support that may not be worth the cost. However if you do scale that far you will be glad you choose an architecture proven to scale that large. However I doubt…

I mostly use Netflix as somewhere you’ve reached a technical point where you need to spread horizontally. As StackOverflow you can scale rather far without doing so if your product isn’t streaming billions of gigabytes of video to the entire world through numerous platforms. So what I mean by it is that many of will never reach those technical requirements. Sorry that I wasn’t clear. I don’t disagree with what you sa…

That is how I use Netflix or stackoverflow. Choosing either (despite how different they are!) is better than random unstructured building code with no thought to the whole system.

Re: In Defense of Simple Architectures (2022)

#152

Post by panqueca »

I couldn't agree more. Even when you decide to use a dead simple cloud provider (fly.io for example), you still have to spend time to understand:

- the CLI

- the cost model

- the cost optimizations

I'm tired of this endless looping. A cheap VPS + Docker is enough and in most of cases (it's even easier to scale/migrate)

Re: In Defense of Simple Architectures (2022)

#153

Post by dartos »

berkes wrote: post #60
TeMPOraL wrote: post #40

Earlier quoted context omitted.

On the other hand, at least someone was exploring new tech. In the exploration/exploitation problem, going 100% exploitation and only ever using the same boring old tech for everything is not the optimal choice either.

One reason why people hire me, is for my actual, production, experience in loads of stacks and architectures. Actual, production experience, is, IMO, a requirement to make decisions. No-one will make a good decision to ditch or embrace, say, microservices, based on a HN conversation and a few blog-posts. Nor will they make such a decision based on papers in science journals. But rather based on failures with monolith…

Be honest with me, how many jobs have you had that cared about your variety of experiences?

I’ve been applying to jobs for months and they’re all looking for go and python devs.

I have production experience with both languages, their common web stacks, and many others (ruby, js, php, c#, elixir, erlang, rust).

I’ve felt that even mentioning that I have experience with other stacks is a turn off to recruiters and EMs.

Nobody seems to care about breadth of experience nowadays.

Re: In Defense of Simple Architectures (2022)

#154

Post by Swizec »

TeMPOraL wrote: post #97
zer00eyz wrote: post #10

Early in my career one of the IT guys told me that one of the people on staff was "a technical magpie". I looked at him with a raised eyebrow and he said "He has to grab every shiny piece of tech that shows up and add it to the pile". This is where we are. I can't tell you how many times I have seen projects get done just to pad a PM or developers resume. Just because it was the lastest and greatest hot shit thing to…

> Workman like functionality isnt sexy, it wont be the hot bullet point on your resume, it wont get you your next job, but it is dam effective. So, not fun, not rewarding, no intellectual challenge, no career benefit. Why exactly should I want to do it? This isn't the goddamn United Federation of Planets, nor is the company a church - why exactly should I go above and beyond what I agreed to in exchange for my salary…

> So, not fun, not rewarding, no intellectual challenge, no career benefit. Why exactly should I want to do it?

It does help you get the next job. You’re just pitching it wrong.

Instead of “Built boring tech” try “Delivered $5,000,000 return 2 months early”. Watch your inbox blow up. Business leaders don’t care about what you do, they care about results. What you do to get those results is just an unfortunate cost and obstacle to overcome on the way to the outcome.

Re: In Defense of Simple Architectures (2022)

#155

Post by xnorswap »

throwaway2037 wrote: post #113
xnorswap wrote: post #79

Earlier quoted context omitted.

One answer to your question is C# / .Net. Combines excellent concurrency primitives, very good performance, and a deep reservoir of packages and libraries. Of course it's almost never worth switching languages for an existing product, you just get left with a mess of half-old and half-new tooling and invariably get left having to support both languages.

Real question: From your specific comment, are there any advantages of C# vs Java here?

I'm not familiar enough with Java to answer that question, you may well feel the same about Java, and it may well be true.

Re: In Defense of Simple Architectures (2022)

#156

Post by hiAndrewQuinn »

perrygeo wrote: post #115
bunderbunder wrote: post #87

I think a lot of this comes from the additive cognitive bias, which is really deeply entrenched in most of our thinking. Here's a concrete example, stolen from JD Long's great NormConf talk, "I'd have written a shorter solution but I didn't have the time", which is itself drawing from "People systematically overlook subtractive changes" by Adams, et al., 2021: Give people a Lego construction consisting if a large, st…

In software, it's clear why we don't prefer subtractive changes - complexity. If there's any chance that the code in question has non-local effects that can't be reasoned about at the call site, it's risky to make subtractive changes. Additive changes have the advantage of having a corresponding additive feature to test - you don't need to touch or even understand any of the existing complexity, just glue it on top.…

This is a big factor in why Haskell is widely considered a really fun language to refactor in. The enforced purely functional paradigm makes adding nonlocal effects much more annoying, so later contributors can much more confidently reason about the state of their code (assuming you can find any later contributors in such a small community!).

I don't know whether the Lisps have a similar "fun to refactor" quality to them, since while they are in the functional camp, they're totally different and more flexible beasts architecturally.

Re: In Defense of Simple Architectures (2022)

#158

Post by duped »

zer00eyz wrote: post #10

Early in my career one of the IT guys told me that one of the people on staff was "a technical magpie". I looked at him with a raised eyebrow and he said "He has to grab every shiny piece of tech that shows up and add it to the pile". This is where we are. I can't tell you how many times I have seen projects get done just to pad a PM or developers resume. Just because it was the lastest and greatest hot shit thing to…

One of the best jobs I ever had was under "technical magpie." Did we get shit done? No. Did I get paid a lot of money and always have new stuff to do instead of shoveling CRUD? Absolutely. It was a blast.

Re: In Defense of Simple Architectures (2022)

#159

Post by underdeserver »

paulddraper wrote: post #140
TeMPOraL wrote: post #97

Earlier quoted context omitted.

> Workman like functionality isnt sexy, it wont be the hot bullet point on your resume, it wont get you your next job, but it is dam effective. So, not fun, not rewarding, no intellectual challenge, no career benefit. Why exactly should I want to do it? This isn't the goddamn United Federation of Planets, nor is the company a church - why exactly should I go above and beyond what I agreed to in exchange for my salary…

Hopefully, hopefully your incentives are aligned with your team's success. If they are not, I am truly sorry.

In almost every business setting, your incentives are _partially_ aligned with your employer's. For instance, you usually both want to build a good product; conversely, you want to get paid as much as possible while your employer wants to pay you as little as possible.

If it's all above board, and the non-aligned parts are agreed-to, all is well.

Re: In Defense of Simple Architectures (2022)

#160

Post by jc2jc »

dartos wrote: post #144
01HNNWZ0MV43FF wrote: post #139

Earlier quoted context omitted.

No it doesn't. If your work is easy, the scale gets ratcheted up until it's nearly impossible. That's why web devs have so much trouble with the seemingly-simple task of parsing and producing text

What scale? How does easy work affect scale?

I believe he is saying they add expectations and responsibilities till you are back to equilibrium (i.e. over extended).
Post reply on HN