While developing the Platform of Trust Developer eXperience, I’ve come to situations in which I or someone from the team wonders would some idea be inline with the goals we have with DX. We don’t have a 2 year plan or fixed goal (numbers or such) that has to be reached for example 2021. But since we don’t have such a plan, people are wondering and sometimes reluctant to surface their ideas. People should have tools to evaluate ideas so that micro management is not needed. DX principles also aligns the thinking across the teams. Since we are a new companywe don’t have the legacy burden of product-centric thinking but instead service and customer oriented thinking has been build in to our activities.
To fix this we have created Developer eXperience Strategy. Actually that is too grandiose to describe what we have at the moment. We have guidelines or principles. The principle are really high level guidance just giving the direction where to go. There no speed or target elements, just the direction. It kind of resembles the API Design Guide, which we corverted a month ago to Platform Design Guide. That Design Guide is not dictating all the details. It contains some details occasionally, but mostly it defines boundaries and patterns.
Some companies include DX principles in the API Strategy, but we think DX is so imporant that it deserves to be addressed as such. If you look at the 5 principles as a whole (just the topics) you’ll notice that 3 first principles are about the developer and their daily life. This is due to customer or developer-centric thinking discussed above.
Similar thinking in Tech team
Another example is The tech teams which has their own version of principles. Tech team here refers to our group of hardcore developers. It acts as guidelines for internal developer experience Here’s just few points from it:
- Microservices should have clear functional areas they’re in charge of, e.g. “user management”, and do everything necessary for that, but nothing else.
- Each microservice’s database should be isolated from the others - can be hosted on the same server, but services shouldn’t “peek” straight into each other’s databases, but rather make API calls to each other so implementation details can be safely changed in the background, servers can be scaled independently, etc.
- Eat your own dog food - whenever possible, build our own systems based on our public APIs, and avoid building purely internal APIs to accomplish tasks. This way others can implement their own functionality via APIs when our UIs fail to provide them the power they need.
- No component should be a one man show – at least two people need to actively work on every component, to avoid big risk with a developer being unavailable to fix an issue
- Prefer MVP that works over something that’s perfect
- APIs should talk JSON-LD whenever sensible
- Clarity for fellow developers is a primary goal
- Always write the necessary tests for your code, writing tests “later” means never.
Five principles of DX development
DX development list of items is shorter than the Tech team’s and mostly not so detailed as some of the items in Tech team list are.
We have 5 principles to follow. The below principles define the strategy, high level guidance on Developer eXperience development. If you are wondering if your idea on DX development should be discussed further, then see if you can justify it with the below principles. If your idea implement the principles, then it probably is a pretty damn good idea and you should raise it in Slack.
1. Developer in the center
Understand the needs and workflows of our customer as well as their (developer) culture. We need to know who the customers are, how they use our services, what kind of frameworks and tools they use, are they hobby developers, professional developers or something else? We do not proceed product-first, we value customer-first approach more. Keep the developer personas uptodate. Increase the accuracy of developer personas all the time. If they succeed, we succeed. Thus for example guides are written from developer to developer eg managers do not define what exactly in the getting started guides. Managers review the results and DX lead makes sure all is inline with business goals.
2. Enable flow state to increase happines and productivity
Help developers to be more productive and happy. Developers are hunting flow state all the time. That is when they are most productive and challenges gets solved. Some say their DX should not hinder developer flow state, but we want to look it differently. Our DX must enable their flow states and make it easier get into flow state after a break easily.
3. Support workflows
As a platform we need to provide end-to-end support. Our DX must be fluent from data integration to UX of apps consuming the standardised data. We must understand how our customers use our platform in their daily work, what role it has, how we take away the pain. Identify the pain points and figure out the reliefs.
4. Self-service tools
Platform is developed with API-first principle. Our customer service is build with self-service first. We must enable stabiloity and availability 24/7. We don’t know when some developer around the globe is willing to try out our platform. Self-service is expected by our customers. Tooling is one of the fundamental elements which can make our customers happier and get things done when they need it. Tooling refers to CLI tools, API client test packages, excellent documentation, status information, libraries.
5. Be in the front-line in global level
Getting where we want to be, the top, requires experimentations and culture of fast failure. We can’t be in the frontline if we do not take calculated risks and experiments. Our benchmark are the global leaders of API and platform economy.
Some more to read from 100 Days DX
- #85 - Great Developer eXperience requires fluent internal workflow
- #84 - Theory of Economics of Developer eXperience
- #83 - The Space of API Design Decisions is missing
- #82 - Purpose of API Evaluation Framework
- #81 - Should We Move to Stack Overflow?
- #80 - Four data driven ideas for improving API documentation
While you are here...
Check out Platform of Trust in which I've worked to enable best possible developer experience!