How can I level up my Flutter game?
Recently, someone reached out to me, asking for tips on becoming a next-level Flutter developer. Here are some pointers for a level-up that I learned during my time at Google, as a Freelancer and at Workerbase, and as an interviewer in the interview panel for Flutter developers.
This article is for you if perhaps you consider yourself a solid junior developer, have written a few Flutter apps, know the difference between stateful and stateless widgets, and want to step up your game but don’t know where to start.
The internal organs of Flutter and Dart
The first step towards becoming a more sophisticated engineer is to understand how the language you use works internally. If you want to fly a plane, you need to know the mechanics and physics of how planes work.
Inform yourself about the intricacies of the language. You should be able to explain Isolates, Event loops, widget- and element trees and widget lifecycles, rendering, etc. Make sure you are able to compare these techniques to other languages you know.
Having this knowledge should give you the tools to know how to speed up and optimize the code (things like tree shaking, and deferred loading for web), but also explain some behaviors of the code that you might encounter while debugging.
Bugs, Everywhere
This leads to another point: familiarize yourself with advanced debugging tools and techniques. Besides knowing how to use the Flutter-shipped debugging tools, you should also work with loggers, especially when working with many users. This helps you understand why and when client apps crashed. Sentry for example offers pretty nice features for this.
Don’t be the construction worker, be the architect!
Next up, you should equip yourself with the tools to make the decisions, not only execute them. In many junior positions, you are not the person who decides the architecture of the app. So, your next step should be to at least understand why these decisions were made.
Inform yourself about common architecture patterns, know the differences and their strengths/weaknesses, and make sure you can decide on one or the other depending on the requirements and scope of the app. It is a tight balance between over-engineering the code and having too little structure. Very Good Ventures has a pretty nice introduction to this topic:
Practice cleanly separating the responsibilities of your code. Does this render on the UI? Put it into a views folder. Does it rather contain logic? Put it somewhere else. Just make sure you don’t create a mess between the layers.
Choosing the right architecture is a very essential skill especially when freelancing, since using the right architecture can make or break the maintenance of the code.
Code health
The code you write should be easily maintainable. What does this mean?
Image a new developer coming to your team. Your code should be written in a way that the onboarding time (the time it takes from starting the job until the new person can contribute meaningfully) is minimal. This contains a few points:
- Write readable code over overly complex code. If complex code is just the better solution, make sure it is documented clearly. This means the reader can understand not only the purpose but also the working principle of that code snippet after reading the comment.
- Maintain readable file lengths. This includes extracting shared code into their own files, and splitting up very long code into smaller chunks, especially when using nested widgets.
- Use appropriate and consistent namings. In general, I like to encourage people to follow the effective Dart rules, and to have a baseline agreement of how Dart code should look.
- Practice writing testable code from the beginning. This means, making your classes mockable and considering the different parts you want to be able to test when designing your architecture. Make it a habit to write tests when submitting code.
- Document everything that is necessary, but not more. Rule of thumb: if you only double what the code says in the comment, don’t comment. I like to use dartdoc, for example, to auto-generate pretty nice-looking docs from comments, again, following the documentation rules in Effective Dart.
Stringception
Something we did not like to see in coding challenges is hardcoded Strings for two reasons:
- It is easier to maintain the user-sided Strings from one place, rather than having to search for all those Text widgets in the UI folder (it plays into the separation of responsibilities, too).
- In a globalized world like ours, supporting multiple languages is as important as ever. Familiarize yourself with intl and localization and make it a habit to use that for new projects, it will make your life easier!
The full picture
A good Flutter developer should expand their skills beyond the scope of Flutter. This also goes two ways:
Often, more sophisticated apps require some native coding via platform channels as well. Make sure your native skills are good enough to implement simple things or understand external packages so you can fix issues yourself.
Gather some full-stack experience: Maybe set up a backend in one of your pet projects yourself, come up with your own API definitions, know the basics of how databases work, design your own UXR-based design mockups, etc. A plus if you know some accessibility rules. Doing this at least once helps you tackle these connections with other teams much easier because you understand the challenges and can avoid them before happening.
Pets and Projects
Experience only comes from a lot of practice. A very good way to practice Flutter is to have a few pet projects (projects you do in your free time), in the best case they are openly accessible (Github?) and showcase your best skills, so you can double them as a portfolio.
Another big recommendation is to participate in as many hackathons as you can. The learnings you have there, with a limited amount of time, and resources, and the large variety of requirements you will encounter really force you to sharpen your coding skills, and also makes for some impressive projects in the CV.
Lastly, contribute to open-source projects. Especially with Flutter and Dart, being so community and open-source-driven, it gives you the chance to understand the inner workings, and contribute to them. Here is a series of some example projects you can start looking into for practice!
Ready for the level-up?
Here is a short summary so you can find out which of these points need more work:
- I can explain how Dart and Flutter work internally, and compare them to other languages. I know how to parallelize heavy code.
- I can utilize loggers and debuggers.
- I can explain and compare different architectures for different scenarios, preferably with practical examples or my own projects.
- I can explain and compare different state management approaches and preferably have tried them out myself.
- I have a testing, internationalization, and documentation strategy every time I start a bigger project. I know which parts to comment on and how to mock code.
- I have experience in writing or maintaining native code and full-stack protocols.
I hope a few of these pointers help you to start your level-up process! Feel free to ping me on Linkedin if you have more questions or suggestions.
