If you’ve worked with data products and think things can be WAY better, if you think communicating ideas is as important as writing code, if you want the challenges and impact that come with working in a small startup, join us on the DevEx team at Materialize!
Read on for the general idea, or skip to the second half for the specifics of developer experience at Materialize.
General Principles of Developer Experience
Other areas of software engineering are a few steps ahead of the data space when it comes to the “state of the art” of tooling, processes, and developer experience.
This gives us a trail to follow, but we need to take care to follow the underlying principles, and not cargo cult the programs resulting from those principles.
Developer Productivity
When companies talk about a focus on simplicity, UX, docs, good CLIs and APIs… These are all just means of improving the same thing: developer productivity.
One way to frame the role of DevEx:
Focus on identifying and acting on opportunities to improve developer productivity.
Everything the team does can be evaluated on its effect on developer productivity.
This works equally well for scenarios where we are introducing a technology to developers: Is it REALLY changing their workflow in a way that makes them more productive? And scenarios where we are improving the experience for existing users: Are we removing drudgework, are we helping them level-up their usage effectively?
Empathy
If you were assembling a team to be uniquely qualified to improve productivity, who would you look for?
Some of the companies with the best developer experience have an innate advantage: the builders of the tool are the same kind of developers as the users of the tool. (Bonus points if the tool is used to build the tool, like GitHub!)
Most of the revolutionary startups in the developer tooling space were born out of firsthand experience the founders had as practitioners.
But these aren’t prerequisites for success, they’re just different ways of guaranteeing that a company is good at empathizing with their users.
It’s unrealistic and close-minded to expect to only hire experienced practitioners who could also be customers. The data space is growing too fast, we need to bring more people in!
Whether we hire people from careers as practitioners in the space or not, we maintain empathy by placing a huge emphasis on operational knowledge, on learning the craft, on becoming experts in the real-world usage of our products and the surrounding ecosystem.
A developer experience team maintains empathy with their audience, helping identify opportunities to improve their productivity. The next bit is about acting on those opportunities.
Education
Education (documentation, how-to guides, interactive tutorials, conceptual articles, videos, demo code and applications, meetups, student programs, forums, etc…) is uniquely important to developer experience for at least a few reasons:
- It is a powerful channel for improving developer productivity
- It is a way of reaching developers that don’t know about your product and growing your user base.
- It is wholly owned by the developer experience team.
DevEx has an intentionally broader scope than other team structures like Advocacy or Documentation. It ties back to that productivity mandate: If there’s one form of education that is more effective at increasing developer productivity, use it!
Code
It’s silly to draw an artificial wall between people teaching code and writing code. In the past it happened as a result of developer companies not adequately paying educators (so anyone educator who could get a job writing code did.)
We have a simple solution: Pay DevEx on the same scale as engineering.
Encouraging the developer experience team to write code has so many benefits:
- Empowerment - If devEx sees an opportunity to improve productivity that depends on some code being written or updated, they have more power to make it happen.
- Credibility - The team gets real-world experience with the ecosystem they are teaching.
- Career Optionality - Many career paths develop “ruts” where the longer you stay the harder it is to change. When you’re also writing code you're reversing that trend: The longer you do it, the easier it is to switch to an engineering track.
Where do you draw the line with code?
When should DevEx hand things off to engineering? This is unfortunately a bit of a "you know it when you see it" non-answer. But to make it clear, follow this rule:
Never create a current or future burden on engineering without buy-in from engineering.
For anything that does have greater engineering burden, the typical cross-functional processes should take over, where the business case for the devex request is written up and handed to engineering where it’s prioritized alongside other engineering work.
But the same cloud-based developer tools and services have created an environent where a developer experience team can create a lot of value without burdening their core engineering team.
Specifics of DevEx at Materialize
Materialize is a disruptive technology, it doesn't fit cleanly in an existing category, and it's still in the "early-adopter" phase. These factors mean that developer experience is absolutely vital to the success of the company.
Without a developer experience team, success hinges on people buying into the big-picture vision deeply enough to blaze their own trail and convince their coworkers to follow.
This almost always involves a short-term productivity loss as they adopt and learn the new technology.
DevEx is about building "on-ramps" to Materialize, especially early on when the core concepts are not widely understood.
We have a strong opinion about the guiding principles listed above, but we don't have all the tactics mapped out yet.
Some specific on-ramps we are focusing on now:
- Extending integrations like dbt.
- Develop and share new patterns, architectures and operational practices for data engineering on a streaming paradigm.
- Task oriented how-to guides that cover using Materialize with specific upstream and downstream systems.
- Broader educational content fundamental concepts and idioms in streaming systems, like windows, sinks, exactly-once semantics, durability.
Team Structure
The team is small right now (3 people) so the most important attribute of our first hires is ability to learn and grow. We’re open to hiring technical writers and DevEx Engineers at all levels.
Here is the structure we know so far:
It’s not practical to expect everyone to be experts in Materialize and all the different niches where it can be used, so in Documentation the focus is mainly on knowing Materialize, and in DevEx we’re planning to have each individual focus on a specific niche (e.g. data engineering, analytics engineering, application development.) Integration Engineering may be a team we add later, but it may also be handled within the engineering org.
Where to go from here
If you're already familiar with Materialize and excited about its potential, take a look at the open positions here and if you see one you like apply on the job site, if you don't see a position that exactly fits your experience just contact me directly!
If you're not yet familiar with Materialize, but you like the idea of this developer experience team structure, read this why Materialize reading list and get in touch with me if, after reading the WHY bit, you're excited about what we're building here.
Top comments (0)