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

191–200 of 447 posts

Re: In Defense of Simple Architectures (2022)

#191

Post by robertlagrant »

blueflow wrote: post #18
robertlagrant wrote: post #12

Earlier quoted context omitted.

I understand that's your opinion, but could you show me some badly designed user research results to make this conversation more data driven?

> more data driven Any other engineering discipline. What are common practices in IT would be negligence in other disciplines and might get your permit/license removed. IT is the only sector where companies like Cisco or SAP can exist despite the horrible reliability of their products.

Can you explain it in a different way? I have no idea how it relates to my comment.

Re: In Defense of Simple Architectures (2022)

#192

Post by JAlexoid »

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…

In my experience the boring "I delivered a project very fast with X,Y and Z and saved the company $100mil" will win over "I rearchitected a massive system to run on microservices"

At a certain point in your career, you'll realize that the business manager can override any technical hiring manager. Because at the end of the day delivering results is sexier, than bells and whistles in your resume.

Re: In Defense of Simple Architectures (2022)

#193

Post by JAlexoid »

Swizec wrote: post #154
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…

> 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 an…

Exactly. People forget that the final and most important decision for hiring will be at a less technical and much more bean-counting level.

That's the reason why CS graduates with only bells and whistles in their CV have hard times getting a relevant position - glitter over your resume doesn't deliver value at all.

Re: In Defense of Simple Architectures (2022)

#194

Post by camgunz »

from-nibly wrote: post #51

This is what I tell engineers. Microservices aren't a performance strategy. They are a POTENTIAL cost saving strategy against performance. And an engineering coordination strategy. Theoretically If you have a monolith that can be scaled horizontally there isn't any difference between having 10 replicas of your monolith and having 5 replicas of two microservices with the same codebase. UNLESS you are trying to undersc…

> Microservices aren't a performance strategy. They are a POTENTIAL cost saving strategy against performance.

Yeah they were a way to handle databases that couldn't scale horizontally. You could move business logic out of the database/SQL and into Java/Python/TypeScript app servers you could spin up. Now that we have databases like BigQuery and CockroachDB we don't need to do this anymore.

Re: In Defense of Simple Architectures (2022)

#195

Post by camgunz »

bluGill wrote: post #141
dns_snek wrote: post #89

Earlier quoted context omitted.

How do you square that with the fact that shit usually hits the fan precisely because of this complexity, not in spite of it? That's my observation & experience, anyway. Added bits of "resiliency" often add brand new, unexplored failure points that are just ticking time bombs waiting to bring the entire system down.

Not adding that resiliency isn't the answer though - it just means known failures will get you. Is that better than the unknown failures because of your mitigation? I cannot answer that. I can tell you 100% that eventually a disk will fail. I can tell you 100% that eventually the power will go out. I can tell you 100% that even if you have a computer with redundant power supplies each connected to separate grids, eve…

Absolutely yeah, these things are hard enough to test in a controlled environment with a single app (e.g. FoundationDB) but practically impossible to test fully in a microservices architecture. It's so nice to have this complexity managed for you in the storage layer.

Re: In Defense of Simple Architectures (2022)

#196

Post by jakey_bakey »

from-nibly wrote: post #51

This is what I tell engineers. Microservices aren't a performance strategy. They are a POTENTIAL cost saving strategy against performance. And an engineering coordination strategy. Theoretically If you have a monolith that can be scaled horizontally there isn't any difference between having 10 replicas of your monolith and having 5 replicas of two microservices with the same codebase. UNLESS you are trying to undersc…

Surely one could split a shared monolith into many internal libraries and modules, facilitating ownership?

Re: In Defense of Simple Architectures (2022)

#198

Post by Jtsummers »

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…

> no intellectual challenge

If it's not intellectually challenging, you're not working on interesting systems. If you have to find interesting tools to find intellectual stimulation, consider a different system to work on.

As an example, I got to learn astrodynamics as part of my last job. Maybe not intellectually stimulating to everyone, but it didn't require me to learn the latest tooling just an interesting area of math and physics. The tooling and the language for the software wasn't that interesting, but that's fine.

Re: In Defense of Simple Architectures (2022)

#199

Post by JAlexoid »

duped wrote: post #158
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.

Yes, it's basically being in college - while being paid. If your resume is full of those kind of roles, I'd disregard your resume and many experienced managers will as well.

Remember that your resume will not hold much value, when you give off "we built this thing with friends in a garage" in your resume and little else.

Have you supported anything in production? No? Explain why should you be a candidate for anything other than an entry level position as a SwE.

Re: In Defense of Simple Architectures (2022)

#200

Post by dakiol »

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…

Don’t we get paid the big bucks precisely because we have to fix stuff like this? I mean, if maintaining and fixing software were easy, I guess we wouldn’t be earning 6 figures.

In software engineering We have all these principles and patterns and whatnot precisely because we have to deal with a pile of things that don’t work well together.

Post reply on HN