Before starting with developer experience, let us first understand what a platform team is.
Gergely Orosz in his blog "Pragmatic Engineer" has aptly described platform teams as the building blocks that product teams use to ship business-facing functionality. Products are built on top of platforms, which platforms enable product teams to move faster.
Platform team can operate at multiple levels be it providing infrastructure, central tooling to manage deployments, configuration, testing, ab experimentation etc.
Usually, customers of a platform team are internal engineering teams, hence Developer Experience becomes the central aspect of all the products that a platform team ships.
As developers we like the flexibility and power to configure systems according to our need. So naturally when end-users are 'developers' it feels okay to ship products with an assumption that developers will be able to navigate through technical challenges. This often ends up with multiple layers of configuration, difficult integration/testing & inefficient documentation.
This is in contrast with when end-users are not developers. We then tend to focus on simplicity and delight.
When talking about Developer Experience, there is a thin line which differentiates it from general user experience. There is a need for simplicity yet giving options for extensibility and smart configurability. Delight often gets neglected but that is equally important.
A high-growth engineering organisation is like a well oiled machinery where Platform team is the central part which can directly impact the performance of other engineering teams.
Lets take an example of a very simplified happy path
Context - Nilesh from Growth engineering team, needs to launch a rewards micro-service for its users.
Steps Nilesh takes in order to make his service live
- Nilesh goes to an internal developer dashboard
- selects a new application with language of his choice
- Selects required dependencies like database, cache etc
- Nilesh, gets a link to a newly created git repository with a boiler-plate code containing
- Basic folder structure with teams default language/framework version
- Lint setup with teams best practices
- Docker compose file with dependencies
- CI/CD pipeline with pre-defined stages like lint, test and deploy
- Nilesh, writes code and CI/CD deploys it to provided environments along with dependencies
Now compare this with the process you need to follow at your workplace.
In this example, there are lot of things happening in background right from the selection to deploy. But imagine the number of steps Nilesh had to skip in order to make his service live.
- Adopting a consistent and thought-out structure in their own language
- Not going through a hassle to raise a request with DevOps teams for dependencies
- Asking for git platform rights to create a new repository
- Pre-selected language version that the team uses, no more inconsistent versions
- Configuring linting manually
- Time-taking to and fro with DevOps team to deploy your service
Not every organisation would have resources and time to achieve this level of automation but this helps realise the impact in terms of productivity and developer happiness.
Developer Experience is not about providing 100% automation, but simplifying the overall process like better documentation, easy integration/testing and decentralising decisions.
Hope you found this interesting.
Interested in reading more about platform teams? Happy to chat about it further. Reachable at adityachowdhry9.
Credits - Image by Freepik