I see your point. But accidental complexity is the most uncomfortable work there is to me. Do programmers really find so much fun in creating accidental complexity?

Removing it, no matter whether I created it myself, sure, that can be a hard problem.

I've certainly been guilty creating accidental complexity as a form of procrastrination I guess. But building a microservices architecture is not one of these cases.

FWIW, the alternative stack presented here for small web sites/apps seems infinitely more fun. Immediate feedback, easy to create something visible and change things, etc.

Ironically, it could also lead to complexity when in reality, there is (for example) an actual need for a message queue.

But setting up such stuff without a need sounds easier to avoid to me than, for example, overgeneralizing some code to handle more cases than the relevant ones.

When I feel there are customer or company requirements that I can't fulfill properly, but I should, that's a hard problem for me. Or when I feel unable to clarify achievable goals and communicate productively.

But procrastrination via accidental complexity is mostly the opposite of fun to me.

It all comes back when trying to solve real problems and spending work time solving these problems is more fun than working on homemade problems.

Doing work that I am able to complete and achieving tangible results is more fun than getting tangled in a mess of unneeded complexity. I don't see how this is fun for engineers, maybe I'm not an engineer then.

Over-generalization, setting wrong priorities, that I can understand.

But setting up complex infra or a microservices architecture where it's unneeded, that doesn't seem fun to me at all :)

> a fun addict

Interesting term. Probably pretty on-point.

I’ve been shipping (as opposed to just “writing”) software for almost my entire adult life.

In my experience, there’s a lot of “not fun” stuff involved in shipping.

I like your idea of doing some amount of uncomfortable work every day, internalizing it until it becomes second nature. Any tips on how to start? (other than just do it) :)

You know what, you're right.

I should get off HN, close the editor where I'm dicking about with HTMX, and actually close some fucking tickets today.

Right after I make another pot of coffee.

...

No. Now. Two tickets, then coffee.

Thank you for the kick up the arse.

I'm at this stage. We have a good product with a solid architecture but only a few paying clients due to a complete lack of marketing. So I'm now doing the unfun things!

I dont quite follow. I understand mono vs micro services, and in the last 3 weeks I had to study for system design and do the interviews to get offers. Its a tradeoff, and the system design interview is meant to see if one understands how systems can scale to hypothetical (maybe unrealistic) high loads. In this context the only reason for a microservice is independent scaling and with that also fault tolerance if an unimportant service goes down. But its really the independent scaling. One would clearly say that a monolith is good for the start because it offer simplicity or low complexity but it doesn't scale well to the hypothetical of mega scale.

I worked for a company once where the CEO said I need to start using Kubernetes. Why? We didn't really have any pressing use cases / issues that were shouting out for Kubernetes at all.

His reasoning was all the big players use it, so we should be too...

It was literally a solution looking for a problem. Which is completely arse backwards.