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

271–280 of 447 posts

Re: In Defense of Simple Architectures (2022)

#271

Post by waynesonfire »

isoprophlex wrote: post #242
rizzom5000 wrote: post #226

Earlier quoted context omitted.

> no intellectual challenge I tend to think that cargo cult programming and resume-driven development are the intellectual path of least resistance. Perhaps it's analogous to, "I'd rather rewrite this than understand how it works", because that requires less intellectual effort. Quality engineering is not achieved by the intellectually lazy, from what I've seen.

You're not wrong, but when you're inheriting a convoluted 50 file React shitfest that could have been a single HTML page and 20 lines of javascript... what are you going to do? Invest time in understanding that, or radically simplify in 20% of the time it takes to grok what you get thrown at you?

strawman. why do you even have a 50 file react shitfest to begin with? Hint: perhaps because someone want to pad their resume?

Re: In Defense of Simple Architectures (2022)

#272

Post by zer00eyz »

lovebes wrote: post #148
zer00eyz wrote: post #14

Earlier quoted context omitted.

You aren't looking for a job. You're looking for a lifestyle business. They are great. You will get time in the garden, that's awesome. Vacation someplace with no phones? Out of the question. Weekend in a 3rd world country with character and food and sketchy internet. Not gonna happen. You want to optimize for free time in the garden by all means you can do it, but you loose out in other places, you pick up other wor…

May I get some more information on how you went into lifestyle business? Looking to get into that as well.

I know several folks with niche business that pay various levels of their bills.

Software for youth sports, photography, asset tracking, vendor tracking, niche issues in CC Processing, facets of insurance and billing (coding).

Niche businesses happen all over the place, and finding one (for me) was a lot of trial and error, that niche business pays my "bills" and I do consulting work (sporadic, interesting and high value) to round it out (and keep me on my game).

Dont think of it as a business right away. You're going to "play", you want to build them quickly, you want to host them cheaply, you want to toy with selling them. Your managing disappointment and failure, your learning lessons and keeping it FUN. The moment you start dreaming that it's going to "make it big" is the moment you have to reel yourself back to reality. If you can say "what did I learn" and have a list of things you got from it then it was a success. At some point you just find one that clicks and it grows.

Re: In Defense of Simple Architectures (2022)

#273

Post by groestl »

rizzom5000 wrote: post #226
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…

> no intellectual challenge I tend to think that cargo cult programming and resume-driven development are the intellectual path of least resistance. Perhaps it's analogous to, "I'd rather rewrite this than understand how it works", because that requires less intellectual effort. Quality engineering is not achieved by the intellectually lazy, from what I've seen.

> I'd rather rewrite this than understand how it works

Sounds like "how should I know what I think before I hear what I say" ;)

Re: In Defense of Simple Architectures (2022)

#274

Post by groestl »

waynesonfire wrote: post #271
isoprophlex wrote: post #242

Earlier quoted context omitted.

You're not wrong, but when you're inheriting a convoluted 50 file React shitfest that could have been a single HTML page and 20 lines of javascript... what are you going to do? Invest time in understanding that, or radically simplify in 20% of the time it takes to grok what you get thrown at you?

strawman. why do you even have a 50 file react shitfest to begin with? Hint: perhaps because someone want to pad their resume?

I've seen this. Usually a combination of no economical constraints and technical curiosity on the engineers side.

Re: In Defense of Simple Architectures (2022)

#275

Post by fHr »

JAlexoid wrote: post #201
blueflow wrote: post #18

Earlier quoted context omitted.

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

As one of my friends, an SAP consultant, said - "The value of SAP isn't that it's actually good, but it's predictably scalable" As in - you can setup a process in Germany, then replicate it globally with predictable accuracy. And predictability matters a lot in stable low margin businesses. Walmart can't spend a few billion on a project that may have -100% to 400% return value, when. they have the option of having a…

It is realy funny how SAP is the one single big software company from Europe and it is an absolute dumpster fire.

Re: In Defense of Simple Architectures (2022)

#276

Post by TeMPOraL »

groestl wrote: post #273
rizzom5000 wrote: post #226

Earlier quoted context omitted.

> no intellectual challenge I tend to think that cargo cult programming and resume-driven development are the intellectual path of least resistance. Perhaps it's analogous to, "I'd rather rewrite this than understand how it works", because that requires less intellectual effort. Quality engineering is not achieved by the intellectually lazy, from what I've seen.

> I'd rather rewrite this than understand how it works Sounds like "how should I know what I think before I hear what I say" ;)

I mean yes, it works that way? Hence inner narrative, for those who have it, and/or talking to yourself via notebook or a text file.

Re: In Defense of Simple Architectures (2022)

#277

Post by TeMPOraL »

waynesonfire wrote: post #271
isoprophlex wrote: post #242

Earlier quoted context omitted.

You're not wrong, but when you're inheriting a convoluted 50 file React shitfest that could have been a single HTML page and 20 lines of javascript... what are you going to do? Invest time in understanding that, or radically simplify in 20% of the time it takes to grok what you get thrown at you?

strawman. why do you even have a 50 file react shitfest to begin with? Hint: perhaps because someone want to pad their resume?

Hint: because almost every web developer is a junior who doesn't know what they're doing.

Proof: that's literally what a significant positive growth rate of an occupation means - if the doubling period is N years, then at any given moment, half the workforce has N years of experience or less. I don't remember the estimate for webdev, but I think N was something between 3 to 5 years.

Re: In Defense of Simple Architectures (2022)

#278

Post by FromOmelas »

JAlexoid wrote: post #201
blueflow wrote: post #18

Earlier quoted context omitted.

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

As one of my friends, an SAP consultant, said - "The value of SAP isn't that it's actually good, but it's predictably scalable" As in - you can setup a process in Germany, then replicate it globally with predictable accuracy. And predictability matters a lot in stable low margin businesses. Walmart can't spend a few billion on a project that may have -100% to 400% return value, when. they have the option of having a…

LIDL famously burned around 500M € on a SAP rollout before pulling the plug.

Re: In Defense of Simple Architectures (2022)

#279

Post by berkes »

dartos wrote: post #153
berkes wrote: post #60

Earlier quoted context omitted.

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

All of them in the last decade.

But I guess we misunderstand each-other. None of them cared that I knew "a lot of stuff that isn't appropriate here".

For example, a recent gig, hired me because I'm not just another Rails "expert", but a Rails expert with Typescript experience, who built large CI/CD pipelines with containers and has built complex (is there another way?) AWS infrastructures etc.

Sometimes they need someone with that exact skill-set. In this case, they needed someone to help them move from yet another "upwork-delivered-rails-spagetti" to something that could actually be maintained.

I convinced them to drop the react/typescript frontend for now (it was terribly bolted on) and to forego building their own PaaS nightmare on AWS but instead just push to Heroku - for now.

My experience helped them make tough decisions.

Sometimes gigs hire me because I have a weird combination of experiences. But more often because my experience allows me to help them make decisions on architecture and such. Granted, I am often hired as "senior architect" or some such. And one of the first things I do, is convince them they should never again hire an "externalm interim architect", lol.

Re: In Defense of Simple Architectures (2022)

#280

Post by SamuelAdams »

devjab wrote: post #241
CharlieDigital wrote: post #132

Earlier quoted context omitted.

> Monoliths aren’t very useful in many organisations where you need to build and connect 300+ systems Seems like the mistake is building 300+ systems instead of a handful of systems. A Google team published a paper on this last year: https://dl.acm.org/doi/10.1145/3593856.3595909 > When writing a distributed application, conventional wisdom says to split your application into separate services that can be rolled out…

> Seems like the mistake is building 300+ systems instead of a handful of systems. But that’s not what happens on enterprise organisations. 90% of those are bought “finished” products, which then aren’t actually finished and you can be most certain that almost none of them are capable of sharing any sort of data without help. Hell, sometimes you’ll even have 3 of the same system. You may think it’s silly, but it is w…

> a high (I’m not sure what it’s called in English, but they change employees all the time).

To help you out, the word is attrition or turnover. Turnover would be more appropriate if the roles are refilled, attrition if the roles are never replaced.

https://www.betterup.com/blog/employee-attrition

Post reply on HN