stankmut

If the APIs are meant for public consumption, requiring feature parity makes a lot of sense. But when it’s for internal use by your own developers, waiting means you are making a bunch of new API endpoints no one will ever use. People will write more and more code using the older endpoints and those endpoints will start getting changes that your new ones will need ported over.

I think if you are going to force people to use new endpoints, you’ll need them to either write the endpoints themselves or have a team member who can write it for them and account for this while planning. If getting a new endpoint requires putting in a JIRA ticket with a separate backend team, 4 planning meetings, and a month wait, people are just going to stick with what currently exists.

It was basically the same thing. In the code base, there was only v3 and v4. I never bothered to check what happened to v1 and v2, but I suspect they were used in an older, archived code base.

Job posting requirements are done by a game of telephone where each person down the line is less technical than the previous.

A manager is able to hire a mid-level engineer, which their company defines as 4+ years of experience. An engineer tells the manager what technologies they use, bringing up fastAPI at some point. The manager then gives this list to someone who writes up the job posting who just puts ‘requires 4+ years’ on every bullet.

Nearly every job posting that asks for more experience than is possible or for something weirdly specific happens this way.

In my experience, having to write new v2 (or in my case v4) endpoints for most new features was expected.