Hacker News Reader

Comment by papito | Hacker News Reader

It's the second, younger generation of devs who are realizing that "complexity kills". Those of us who started in 2000's have already seen this. It's a natural cycle. We are seeing a spring-back to monoliths and away from micro-services and crazy tooling chains.

It was completely unnecessary, and most importantly, cost the industry a fortune. If you are older, you have been wondering why you need to work more to achieve less. To me this has been demoralizing, and actually put me through some tough cycles of depression. I no longer enjoy this job. I used to DO things and walk away from my desk every day having a sense of achievement. Now it takes 3 days to set up your microservices locally just to reproduce a bug, apparently because your system with moderate traffic needs to look like Shopify.

Bad example - Shopify is a monolith.

View on HN

I think technology choices should be made depending on the team. If you have 5 teams with 10 people each, then it is a great idea if your service is comprised of 5 microservices that talk to each other across team borders through well defined APIs. If it takes you 3 days to run your microservice locally, then you somehow didn't set up your development environment when you should have.

> If it takes you 3 days to run your microservice locally, then you somehow didn't set up your development environment when you should have.

The fact that setting up your dev env takes such complex rituals and incantations that need to be prepacked in a spellbook is itself a red flag.

A well-tooled development environment takes minutes to set up.

A well-tooled environment does not just spring out of an ether. Maintaining proper tooling in a distributed system often requires more work than the system itself. In a lot of cases, the business does not even consider this kind of time commitment, pushing the team to churn out features, and who eventually just bog down in insane complexity.

This strikes me as a, "poor carpenter blames his tools" situation. Obviously if a business does a bad job considering the needs of their engineers then the needs of their engineers won't be met, but that doesn't mean that the modern development environment is the problem.

Well, if the tool is a Swiss Army Chainsaw and you just need to cut a piece of paper, just maybe the carpenter is not fully to blame.

> then you somehow didn't set up your development environment when you should have.

This is great! ...in theory. But why do so many teams seem to have these kinds of problems? I think we have to come into these conversations with an over abundance of good faith that people are trying their best. Something in this microservice architecture conversation of the past decade isn't working as elegantly for a huge portion of the devshops that try it.

People should do lots of things, but that doesn't mean they always get done. There is merit to the argument that you may do things in a simpler way and adopt a different approach to cross team communication and complexity management. Your final sentence reads as a moral judgement equivalent to "your doing it wrong" without offering a solution.

We've had a decade of telling people they're doing it wrong and it's still being done with the same problems over and over and over again.

> If you have 5 teams with 10 people each, then it is a great idea if your service is comprised of 5 microservices

i've always thought a micro-service architecture should be decided and defined by the org chart and not technology.

This sounds like a symptom of you falling behind the technology curve more than a problem with the technology curve. Most people are achieving vastly more with newer tech than ever could have been done in the early 2000s. You've gotta be looking through some densely rose colored glasses if you think that that the web in the 2000s was just as powerful as the web of today.

I resisted learning a lot of it knowing that there will be a snap-back to simpler designs long-term, and it's happening now.

And when I tried, it went nowhere. After months of work on my side project with Electron, Typescript, and Vue, I was in the same place because every time I opened IntelliJ, it seemed all of my effort went into just having it build again.

Now I chose ArrowJS for my project, and it's been a delight. Look, I get it, but I would refrain from accusing the other person of laziness in this case.

Learnings from 5 years of tech startup code audits: https://kenkantzer.com/learnings-from-5-years-of-tech-startu...

The very first two points prove that it's not just me.

I don't think there is laziness in falling behind the technology curve - the things that worked ten years ago still work today and if you're shipping code then what you're doing is working. But new technologies aren't overly complex and they generally make a developer's life easier, not harder, but they all come with a learning curve. And the landscape evolves quickly, so in order to leverage them you have to stay on top of it.

This comment is arrogant and objectively isn't correct.

Your parent comment definitely came off as arrogant, but your reply doesn't come off any better. If it's objectively incorrect, then you can contribute to discussion by explaining how and why. A low effort drive-by dismissal isn't appropriate for HN.

This is anecdotal, but I have been in the industry > 10 years now and worked for a lot of employers. What they have required of me for the frontend has pretty much been the same more or less throughout. But recently, with the large amount of funding, companies have had a large blow up in payroll and a talent shortage. The talent shortage has resulted in some juniors getting hired that would not have gotten hired during the great recession. These juniors, on average, need to know a lot more now than back then due to the complex stack. This has resulted in a lot of breadth of knowledge but not a lot of depth. Over time , large teams of inexperienced people have turned what could be a simple frontend created by 1-2 developers in a large 15 developer behemoth that is difficult to maintain and keep secure. It is difficult to reason about for most newer developers so a lot of the time is spent handling edge case bugs instead of getting the job done. Usually their needs really aren't different. It's often just an intranet app or b2b. These don't have scaling needs and you can create reactive asynchronous websites without the complexity here and without reinventing the wheel. Sometimes, the complexity introduced by this complex stack is required (i.e. the app being created is complex). Everyone thinks their app is complex. It almost always is not complex, at least on the frontend, and it could have shipped earlier and with less bugs if the complex stack was not introduced.

> it takes 3 days to set up your microservices locally

Why do you need all microservices locally? Why wouldn't you set up just the relevant one, and proxy the traffic to the rest of the services already deployed? Or, failing that, why don't you have a docker-compose file that has already pre-configured your services to run locally?

What about the database contents?

Reply on news.ycombinator.com