Flutter culture and how to preserve it

Filip Hracek
Flutter
Published in
6 min readJun 7, 2019

--

[Emily Fortuna and Filip Hracek wrote this article together.]

A big part of what makes Flutter so delightful and productive is its community. We really want this to continue, and so we thought we’d share some of our observations about the current culture, and some ideas on how to preserve it.

Being open

There are three senses of the word open we’re thinking of here: open as in open minded, and open as in accessible, and open as in Open Source. While the Open Source angle is great (and makes our package system a veritable rainforest biome of abundance), culture-wise we’re thinking primarily about the first two. It has been wonderful to see the Flutter community welcome newcomers and help them learn the ropes, answering questions with patience and thoroughness. This helps our community grow and feel inviting to everyone, regardless of your background. We love seeing how Flutter developers share code snippets and have a willingness to dive into debugging others’ problems.

Of course, open-mindedness is applicable to much more than just newcomers. There often can be more than one way to implement an idea, and we appreciate tremendously that the Flutter community gently corrects issues as they arise or allows different ways of implementing algorithms as the case may be. That, again, is powerful.

Some amount of standardization is good. A small team should probably have a standardized code style. But it’s really easy for tech communities to get a little overzealous about the “right” way to do things. Different teams will have different code styles, and that’s okay. Different apps will use different state management approaches, and that’s also okay. Some people will use tabs instead of spaces, and that’s (*visibly struggles for 15 minutes*) okay.

Again, it’s easy to overlook how natural it is for tech communities to become rigid about some ideas, to gain immutable institutional knowledge and defend it with fanatical zeal.

Yet in the Flutter community, we haven’t seen any of that.

Approaching questions with a beginner’s mindset, that is with openness, gentleness, curiosity, thoroughness, and a lack of preconceptions serves everyone. Not only does it encourage newcomers, it furthers the understanding of Flutter veterans, who may have only had a partial understanding of a subject area. And, simply, it makes other folks more receptive to your ideas. We are thrilled to see these positive qualities often on Stack Overflow and various Slack channels. See also, vulnerability as a superpower.

Being modest

We see Flutter developers being helpful to newcomers without looking down at them. This is extremely powerful.

It’s very natural to want to look perfect in front of others. But if taken too far it leads to a culture of masks and unrealistic expectations. Things like this, when left unchecked, can spiral out of control via feedback loops. It can start with little snide remarks and next thing you know, you have widespread imposter syndrome, insecurity, anxiety, and cruelty.

We hope we’ve shown through the various Flutter Boring Show episodes that we make mistakes. (Because we certainly do make mistakes!) The Boring Show’s concept is about showing the development process with all the errors, blind alleys, and synapse lapses along the way, without editing.

This is one of the core qualities our team looks for in prospective Flutter Google Developer Experts (GDEs). We expect Flutter GDEs, the people who are some of the most knowledgeable about Flutter on the planet, to demonstrate humility and empathy. We don’t want Flutter to be represented by a group of smart but patronizing people. Thankfully, we never had any trouble with any of the prospective GDEs. The message of humbleness always resonated without us even having to explain what we mean. That’s a testament to our community.

Fortunately we see this in the Flutter engineering team as well. To call just one example, Ian — one of the founders of Flutter and former editor of the HTML spec, among other things — is as humble an engineer as anyone we know. You can see him here being uncertain about the workings of Slivers. That makes us respect him more, not less.

Being respectful to other technologies

It’s easy to get so attached to a technology to the point that all others look like a bad idea. Especially when they’re competing technologies.

Flutter doesn’t need hype or zealotry. There are very good reasons to use Flutter such as wanting to take advantage of Dart to write a reactive UI quickly, having a fast responsive app that works on iOS and Android (and the web and desktop), and having a rich package ecosystem easily within reach.

But some people also have use cases that are not a good fit for Flutter, and one of the best things you can do as a Flutter enthusiast is to persuade these people to not use Flutter. You will save them a lot of pain and disappointment. And that person will respect you more for knowing the technological landscape extensively enough to provide an even-handed recommendation.

Unfortunately, Filip has already seen some derision from the Flutter community towards other technologies. But it hasn’t been widespread, and others in the community have stood against it. That makes us optimistic.

Why preserve this?

This community culture is an enormous strength of Flutter. Let’s be real: the developer experience of any technology is a sum of both the technology itself and the community around it. If a community consists of just fanatics, jerks, or hypers, no amount of technical superiority will make us join it.

A healthy community is one that grows. There can be hidden costs behind a community growing while simultaneously becoming more insular. Yes, some new folks are joining, but can you imagine how many additional people might join if that community if it were more welcoming? We want to preserve these qualities that brought us to this community and continue to open it up for those that join after us.

How to preserve this?

There isn’t a top-down way to preserve these values. Flutter is an open community. Its values will be preserved through the day-to-day decisions of its members. Small things like how you welcome new members, how you share your knowledge, how honest you are about your latest mistake, how nicely you talk about a competing framework. All those things are the Flutter community.

By focusing on openness, modesty, and respect to others in the ecosystem we will continue to foster a great developer experience for everyone. We hope that by identifying and naming what we see in the community, this article will help preserve it. After all, it’s hard to preserve something without realizing we have it.

What we don’t mean

  • We don’t mean we shouldn’t be showing best practices and great code. You can be excellent in your craft without looking down on others.
  • We don’t mean we shouldn’t have any standards and “primary ways to do things.” You can have standards without being dismissive about alternatives.
  • We don’t mean we shouldn’t be enthusiastic. You can be enthusiastic without hating on competing technologies.
  • We don’t mean we shouldn’t be excited about Flutter. You can be excited and still know exactly when and why Flutter is not a good tool for the job.

As Flutter continues to grow in popularity, we are at an important point in our community’s history, and you are a crucial part of it! Let’s grow in the right way to continue to foster a great experience for everyone. When interacting with other folks on the internet remember to let the qualities of openness, modesty, and respect to other ecosystems guide your responses. Flutter has a Code of Conduct and, as we mention there, should you experience anything that makes you feel unwelcome in Flutter’s community, please contact someone on the team such as one of us. And if you’re new here, welcome! We’re so excited you can join us.

--

--

Filip Hracek
Flutter

I’m a pro­gram­ming buff with formal train­ing in jour­nal­ism. I build games, teach pro­gram­ming, explain things, and create silly soft­ware experiments.