Stephen Fluin, Angular DevRel Lead: Why Аre Developer Advocates Important and How to Build a Strong Dev Community

Stephen Fluin is a developer relations lead on the Angular team at Google. It is his responsibility for making developers, in organizations across the world, to be successful with Angular and to reflect the needs of the community on to the Angular team. That way, as they evolve the product, they make things better in a way that serves the community.

Very soon he will meet the Bulgarian and CEE tech ecosystem as DevReach, the popular developer conference is coming up, starting on October 19th and continuing for five days. Due to the COVID-19 pandemic, this year’s edition will be virtual but true to its spirit to be an event from developers for developers, it will still provide numerous opportunities for learning and collaboration.

Spanning five days, DevReach will bring together renowned industry experts and influencers for hands-on sessions and exclusive interviews about the latest app dev technologies and best practices. With each day dedicated to different technology and framework, attendees will also be able to dive into live coding with Blazor, React, Xamarin/MAUI, and Angular. 

It’s day four of the conference organized by Progress, October 22nd, when Fluin will join the Angular party and codе together with other participants. In the meantime, we decided to get to know him and explore the latest trends in the Angular ecosystem, why are developer advocates important, and what are the best ways to build a strong developer community.

Trending Topics: Why are developer advocates important and what kind of companies should have them?

Stephen Fluin: I think developer advocates and developer relations, in general, are very important. The bigger a product gets, especially with developer products, the further away you get from your customers. When you require really advanced skill sets that are specialized in things like compilers, you end up further away from the people who are building applications and using your tools. 

Developer relations can be an important bridge where folks in this job have one foot in both universes. Both the challenges that come with building and shipping large software products for developers as well as the understanding and the empathy of what it’s like to build with the product every day. 

On a more practical level, can you give us some tips on building and maintaining developer communities?

I’d come back to communication as being essential. First, from the standpoint of listening – understanding what people are asking for, why they are asking for it, and understanding the context they have. 

One of the things we all often ignore is that software engineering is super complex. You never see the tool the same way the people that use it do. For example, are the users junior developers doing something for the first time? Or they’ve been doing development for 30 years, but now they are in a brand-new domain? Understanding all the ways in which people find you and relate to you is important. It puts you in a mental box that can help you advance their journey. We are all on a journey as engineers, there is always more to learn, more to do, and there are always ways we can get better. 

The other side of communication is trying to be clear. Clear about what something is, what it isn’t, where it’s going. One of the big challenges we have in the industry as a whole is that most of your customers will be in what I call ‘the silent majority’. This means they are not reading every blog post you write and not following every move you make. And they shouldn’t be – they should be focused on their goals and priorities. It’s very easy to forget that. You may have said something seven times and think it’s completely clear, but the community is probably not in the same mental space. They may have not heard those things. They don’t know how you see the world. 

So, trying to build this bi-directional empathy really creates a strong connection with the community.

After communication, number two would probably be the presence. Developer communities are all over the world. Some are focused on new technologies, some are focused on old technologies, some are within companies, some are external, some are informal. The more you can do to be present and available to those folks, the more you can help them grow and be successful. 

What’s the current state of the Angular ecosystem? Are there any recent developments you are particularly excited about?

I am really excited about the momentum we are building right now. We recently released version 10 and we are about to release version 11 and we really don’t know what’s going to be in it. That’s really interesting for us – we do time-based releases rather than feature-based releases. At the date, we will release everything that’s ready and continue working on everything else that’s not. 

We just published our first roadmap, which shows the direction we are taking. One thing that’s very important to us is staying in sync with the ecosystem and offering the latest integrations – everything from TypeScript to Webpack. Because as a healthy ecosystem, none of these tools are static. We are all moving forward and investing in keeping in sync with that ecosystem. 

One area we are really talking about is the end-to-end testing strategy. Even in the last couple of years, the landscape has changed. Previously, we have been relying on tools we built ourselves like Protractor, but we think there is an opportunity for working more with community innovations like Cypress.

We are trying to reflect on what’s happening in the ecosystem and what’s the future we want to build towards. If we use a soccer analogy: “Don’t run towards the ball but towards where the ball is going.”

Another thing we are investing in right now is what we call a Project Ivy. We have been working on Ivy for over two years and during that time it was very hard to accept community contributions and to respond to issues. Since Ivy has shipped, we re-focused a lot on that idea of how we make sure we are spending time on all the community contributions that are coming in. 

Can you tell us about the software development processes and methodologies you use around Angular? 

Every line of code we write in Angular goes through the same open-source process. We use Github, we have one monorepository where we have everything – http, forms, Angular’s build tooling, Angular’s website. All these things live in the same repository. Every engineer on our team has to go through the same peer-review process.

In terms of software development methodologies, we are closest to Kanban. We have a backlog of efforts, and everyone’s working on the highest priority item within their skillset, and we move from there as we go. 

What advice would you give to young software engineers, at the very beginning of their career?

This advice will be a little controversial because everyone has different learning styles. But what I have found is that motivation, passion, engagement, energy – these pieces of the puzzle are the hardest to get and the most important. So, when you are young early in your career, don’t worry about learning as much as doing. 

Instead of saying, “I have to go and learn all these programming languages, frameworks, and tools,” focus on: “What’s a cool thing that I can build, a thing I wish existed, what’s a piece of my life I can automate or enrich?” Focusing on the value in your life and the value you provide to others is going to necessarily drive you to pick the right skills and you will practice them in a way that you will remember them. It will give you that mindset for solving problems for life rather than open-ended directionless learning.

+++ Learn more and register for DevReach here