> The best way I've found is to have it write small functions, and then I tell it to compose them together.
Pretty much how I code without AI, except making my brain break the problem down into small functions and expressing them in code rather than as a chat.
It's not really like your examples because MCP has been around for about 1 year whereas those others have been around for decades and are completely ubiquitous throughout the software industry as a result.
I strongly agree with almost all of this except the last part about project managers - a good one is invaluable, an ok one can still be helpful. The majority probably are neither (and their ability to be good at managing projects depends a lot on other org functions - not necessarily within their control) but way better than 90%+ that the author suggests.
Interesting (but perhaps not surprising) none of the top comments mention meeting or learning how to work with the people who build, operate, and maintain the software product that they're managing.
Understanding the dynamic (ie. inherent tension) between engineering and product/business is a really important part of a software job no matter what your role is.
> You launch your local service locally, you consume whatever you need to consume straight from a cloud environment, you test the contract with a local test set, and you deploy the service. That's it.
If your services are mostly stateless and/or your development team is very small that can work. If not, you will quickly run into problems sharing the data. Making schema changes to the shared cloud services. Cleaning up dev/test/etc data that has accumulated, etc. Then you are back to thinking of provisioning isolated cloud environment per dev.
What was the point of microservice architecture if you can't develop each service individually in the first place? Sounds to me like the architecture you're talking about isn't an actual microservice, and it's just ball 'o mud over TCP instead of as a single monolith.
At a previous place of work I worked with a monolith structure, and it was actually perfectly fine. Development got done separately on several large substructures in the monolith, and devs could install the whole project locally and run it just fine.
I'm really wondering why we're all using microservice architecture if we're all convinced that to actually develop on them, devs need to reproduce 50odd of those services locally for debugging. Then what was the point?
Resume chasing and trying to paper over the fact that you don't understand architecture, plus bad tooling that e.g. doesn't properly support incremental compilation and so makes monoliths painful.
No one does microservices for resume chasing anymore, because everyone is already doing it for practical reasons. I never came across a monolith that wasn't in the process of peeling responsibilities to either microservices or function-as-a-service. For project managers to open their eyes, all that's needed is something like a deployment going wrong due to a single bad commit, or things scaling weird because a background process caused a brownout, or even external teams screwing up a deployment after pushing bad code.
You can always spin up several services locally or if you have a development cluster run the service you are working on locally against development services.
You're going in circles. That is what the commenter is replying to. You often can't just go off dev because other people use it while you're testing, and you're back to just launching everything yourself.
> If your services are mostly stateless and/or your development team is very small that can work. If not, you will quickly run into problems sharing the data.
No, not really. The size of your teams have zero to do with whether your services can corrupt data. That's on you. Don't pin the blame on a service architecture for the design errors you introduced. Everyone else does not have that problem. Why are you having it and blaming the same system architecture used by everyone else?
> Making schema changes to the shared cloud services.
What are you talking about? There is absolute zero system architectures where you can change schemas willy nilly without consequences. Why are you trying to pin the blame on microservices for not knowing the basics of how to work with databases?
In all the times I had to work on schema changes, the development was done with a db deployed in a sandbox environment, and when work was done we had to go with a full database migration with blue-green deployments along with gradual rollout. Why on earth are you expecting you can just drop by and change a schema?
> Cleaning up dev/test/etc data that has accumulated, etc.
Isn't this a non-issue to anyone who works with databases? I mean, in extreme scenarios you can spin up a fake database with your local service, but don't even try to argue this is the justification you need to launch dozens of services.
The truth of the matter is that this is extremely simple: if you want to work on a service, launch that service locally configuring it to consume all dependencies running in a non-prod environment. That's what they are for. If you have extremely specialized needs, stub specific dependencies locally. That's it.
> Striking during election week is kind of a crappy move to pull
Hard disagree. They're exerting what little leverage they have. Also there's plenty of places to get reliable election coverage besides NYT so who cares?
You can absolutely work as a professional writing code for 20 years and never work on a large software project or a project with a large team.
I worked on a small team at a government contractor that never used version control and deployments were an rsync from the lead engineer’s laptop to the cloud, this was in 2020.
There’s a lot of industries like bioinformatics or journalism where there’s people who are adept at writing code but who are not doing software engineering.
Pretty much how I code without AI, except making my brain break the problem down into small functions and expressing them in code rather than as a chat.