I think the biggest difference is as defined by Martin Fowler:
"
When building communication structures between different processes, we've seen many products and approaches that stress putting significant smarts into the communication mechanism itself. A good example of this is the Enterprise Service Bus (ESB), where ESB products often include sophisticated facilities for message routing, choreography, transformation, and applying business rules.
The microservice community favours an alternative approach: smart endpoints and dumb pipes. Applications built from microservices aim to be as decoupled and as cohesive as possible - they own their own domain logic and act more as filters in the classical Unix sense - receiving a request, applying logic as appropriate and producing a response. These are choreographed using simple RESTish protocols rather than complex protocols such as WS-Choreography or BPEL or orchestration by a central tool."
Thank you! I don't want to live in a single housing period. Atm EV isn't an option for people living in the flats without access to the public infrastructure. If I bought a house I would have to commute 5x longer distance every day.
First of all I feel judged here - you don't know how much money and properties I own. I am earning my money outside Poland and I understand these car might be expensive for polish standards, but not in e.g. US. I try to avoid showing status, I wear normal clothes and avoid buying expensive stuff, but Porsche was my childhood dream - I love the design. Going back to the topic, I live in the flat as it's close to central, I don't want to live in the house.
I bought a car this year. I was thinking about Tesla or Porsche Taycan, but unfortunately in Poland there is no infrastructure to charge them. I live in the flat so I had to go with gasoline car. Maybe in the next 5 years.
I had friends doing microdosing and your post is 100% align with what I have seen. They also experienced periods of paranoia, after people weren't that impressed with their results.
The only times I had to rewrite the software was the time when initial documentation, didn't match what was actually delivered/expected from the client. Sometimes it's very hard to plan architecture when the whole concept change.
I am not sure what you mean by bullshit but I will try to answer this question.
Not really. I work in mid-size company driven by marketing and sales. Besides daily stand-ups which could be considered bullshit there is not much meetings. Lead developer needs to attend few more to scope projects coming from marketing but its not that bad. Most time we can focus just on coding. The worst part is probably UAT process, but when you deal with mature projects it always will be a pain.
Usually when I join company there is some big framework there, and bunch of people who jerk off to the new hype framework in given language. Companies believes it's best solution, because when they send people to conferences they see bunch of other people jerking to the same frameworks. I don't like on small projects with 1-2 developers and these days its the only solution to have normal environment.
It's not that these things are not clear for me, I build many successful applications using these technologies. Also in the past I was really happy using them, but lately I started to realise that it's usually just increase the time we need to spend building applications. I can't see what really I get in return. Especially debugging this kind of application is also hard, as we can not just set breakpoints in yml file.
" When building communication structures between different processes, we've seen many products and approaches that stress putting significant smarts into the communication mechanism itself. A good example of this is the Enterprise Service Bus (ESB), where ESB products often include sophisticated facilities for message routing, choreography, transformation, and applying business rules.
The microservice community favours an alternative approach: smart endpoints and dumb pipes. Applications built from microservices aim to be as decoupled and as cohesive as possible - they own their own domain logic and act more as filters in the classical Unix sense - receiving a request, applying logic as appropriate and producing a response. These are choreographed using simple RESTish protocols rather than complex protocols such as WS-Choreography or BPEL or orchestration by a central tool."
https://martinfowler.com/articles/microservices.html#SmartEn...