2024/05/18 - DevEx Brain Dump 1

Context

At the start of 2024, I had the chance to switch over to a freshly formed Developper Experience (DevEx) division within my workplace. Now that a couple of months have passed, I'm looking to dump various little thoughts and observations that have come to me with this new role. Hence the "DevEx Brain Dump 1".

So what do we mean by DevEx?

Before going further, I want to mention the implications of DevEx in this context. Since my employer is a cybersecurity SaaS provider, the tools and features we enhance aim to improve day to day experience of developpers that are external to the company. I'd love to focus on internal tooling, but that is a different story (maybe a subject for a separate post eventually).

Thought 1. Variety makes things spicy

The main point our customers have in common is that they are working in tech. On the other hand, where they work and what they do varies radically:

  • Do they work in an 8 person startup? Or an 1000+ employee organization?
  • Are they an early career engineer that is faced with a vulnerability for the first time? Or an engineer with 20 years of experience and multiple battlescars?
  • How dynamic is their work? Do things change every day or does it take half a year to get something shipped?
  • How regulated is their domain? Can we expose information safely on third party integrations?

As you can imagine, these personas have different assumptions and operational needs when it comes to our tools. Some individuals may need simplified views of vulnerability scans, others may require a fuller picture of their security posture. Developper experience is quite subjective in this case, a good experience for one person is a horrible one for another.

So how can a team of engineers build anything that moves the needle for the experience? Is there even a quantifiable metric that tells us we are doing a good job?

One word: feedback. Gathering feedback is crucial since friction points tend to be on an individual level. Here are some approaches to be considered:

  • Closed Beta interviews with specific customers
  • Feature announcements
  • Feedback forms (Google Forms, in-app popup dialogs, etc.)
  • Open support and FAQ channels (public Slack channel, Discord, etc.)
  • Analytics instrumentation (mean time to fix, usage/interactions metrics, etc.)

Of course, any one of these processes that can be automated probably should be!

Thought 2. How do we define a vision?

Defining a vision for a product, feature, or platform is far from being a simple problem in general. Nonetheless, it is especially vague when faced with something as fuzzy as DevEx. In my experience, when building software features and setting requirements, it often boils down to:

  1. Make it work
  2. Make it better

The first step tends to be pretty straightforward. You have an idea of what the feature should do, you design, you implement, rinse and repeat. The second step, on the other hand, requires your solution to have already been used in the wild. Hopefully, you should already have an idea of how to improve it (since you built it).

When working in DevEx though, the majority of the job is that second step. This involves a couple of steps that are a less evident:

  • Understanding decisions that were made prior to your work (often by other folks)
  • Adapting your desired outcome to the existing solution
  • Handling performance limitations and bottlenecks of existing architectures

Sourcing tribal knowledge becomes quite important and requires some cross-team communication before getting started. In this case, you may also encounter friction between different visions of where the product should go.

Thought 3. Fundamental needs

Here's a fun little realization that this role has forced me to face about my own expectations as a developer!

What are the needs of a developer when it comes to a tool? Many factors are at play depending on the individual, yet I find the two that jump out to me are:

  • Reliability:

    • More than anything, I don't want to debug the tool itself. I will abandon any developer tooling if it adds friction to my workflow. If I am to adopt a tool, I want it to work and to keep working. If it doesn't, I don't need it.

  • Obviousness:

    • My favorite tools tend to be obvious. I don't need to scratch my head too much about their workings since they are explicit and follow standard patterns. If it is a CLI tool, I would expect a -v flag to provide verbose output. If it is a web interface, I expect the ... icon to give me more options.

The imortant takeaway from these two fundamental needs is that they are a return to the basics. Even if a tool is delightful to look at, if it isn't easy and doesn't fulfill its purpose, it is useless. A strong focus on additional bells and whistles is wasted effort if the base functionality is not already there.

Before jumping on improvements, establish a baseline and discover if it is sufficient before going any further!

Thought 4. Mindful of the noise

A good chunk of my work up to now in DevEx involves delivering richer platform content to the native tools used by engineering teams. Alerting users of vulnerability detections within their Slack, GitHub, or AWS integrations is quite useful but can have some nasty side-effects.

The line is very fine between useful and annoying.

As an example, let's take a comment posted to a GitHub pull-request by your tool. Platforms tend to send out emails for these types of events. This is something that is out of the control of the team building the integration and telling your customers to silence their notifications is far from a solution. Without proper design of the quantity of information provided, your wonderful new feature can quickly become a spam bot.

A very important aspect to keep in mind is to provide just enough configurability to your users. Dynamic configuration has the benefit of pushing the responsibility onto the user for this type of annoyance. When faced with the question Why is your product so noisy?, which of the following would you prefer to send back in a support ticket:

  • "This volume of information is by design."
  • "You can simply enable X in the settings for less disturbances if you wish."

Probasbly the later right?

Thought 5. Passion driven development

DevEx fundamentally begins with internal adoption. How are you supposed to empathize with your customer's qualms with the product if you do not use it yourself? Have you encountered the same difficulties?

As a developer, dogfooding your product will inevitably make you realize how bad it is. This kicks off the following beautiful cycle:

Why does this suck -> Who the hell built this -> Oh yea, it's me

Same effect as frowning at a line of code after a couple of months and realizing that your name is the one in the Git blame. My realization bases itself in the fact that using your own product makes you by default a stakeholder in it's success.

  • "This sucks, I have to fix it"
  • "This sucks, I should fix it"

Notice the subtle difference between both sentences above? The first comes from an obligation, whilst the second comes from an interest. If engineers are interested in and use the things they build, they will naturally fix the experience problems they come across in a selfish fashion. This also provides the added benefit of turning your engineers into marketers. Pride in your work is always fun to show off.

This infectious aspect of passion driven development keeps the team healthier and engaged. Who would want the drag of having to fix another bug on a tool that doesn't matter, right?

Thought 6. Shifting priorities and roadmaps

As a final thought, I propose a small rant. Ever spent a couple of weeks or months working on a project and suddenly the business decides it wants something new? This impacts many fields and the workaround I have always seen has been to cut corners and ship something functional.

How does this work with DevEx though? Just functional is not sufficient if you want to retain marketshare of developers. Following the 80/20 rule, what makes a delightful developer experience is the fact that your engineers have the time dedicated to completing the final touches. Granted that perfection doesn't exist, but tackling the last 20% of the work is essential since here lies the small friction points your customers will encounter and complain about.

So how can we live with the issue of shifting business priorities?

  • Target delight from the start.

    • Although not so obvious when you are working on top of an existing solution, this may be possible if you are greenfielding a project.

  • Leverage compounding improvements.

    • At every line of code, question yourself if the experience for a developer will be improved. Chaining a bunch of micro-decisions can have a lasting effect on the overall outcome. (there may be a bit of influence from Kent Beck's Tidy First here)

Roadmaps aren't easy to divert when things get shuffled. Yet, by making your long term vision decisions on a smaller increment of work, you give yourself flexibility for the future.

In the end

req := fetchBrainContents(ctx)
httputils.DumpRequest(req, true)

Dumping these shower thoughts has been a fun exercise. Maybe I'll revisit this format during a following checkpoint as I operate within DevEx, who knows. Till then, cheers!