Flutter taught me Flutter wasn't the point

In an earlier blog, I wrote about adopting a growth mindset. I described my experiences with the mentality of the different schools I've attended, and how fixed mindsets are so profoundly present in today's society. I also mentioned my ambition of changing my own way of thinking, and was hopeful of using Baseflow's culture as a sandbox - a safe environment in which I was encouraged to experiment. It is now two years later, and a lot has changed.

Of course, many things have progressed in the world of tech lately, but that's to be expected. For me, the biggest change occurred within myself. I noticed that many people were interested in what this change actually looks like, particularly on a practical level. I won't be going into the abstractions and concepts of the growth mindset. Instead, I will use a recent example to demonstrate what applying a growth mindset means for me in the context of software development. I will explain my reasoning, what emotions I typically feel, and will also reflect on how I would have approached things 2 years ago. These comparisons are where the progression really shines.

‍

Learning Flutter

Recently, I've been tasked with "learning Flutter". This immediately raised a few questions and objections for me; for example, the word "learning". That word still scares me. Then there's the word "Flutter" - I had no idea what that was. On top of that, "Learning Flutter" is a very vague assignment in itself . I knew I had some work to do before even beginning to work on the task. Due to the lack of context and purpose, I had to set some boundaries and goals for myself. This insight was new: a first sign of progression.

2 years ago, I would have felt overwhelmed and daunted when learning a language and framework from scratch.

Following a top-down approach, I decided to find out some basic things about Flutter first. What's it for? How is it used? What tooling does one need? What does idiomatic Dart look like? Baseflow has a solid number of Flutter experts, and is continuously developing Flutter training through the Baseflow Academy. I knew I could tap into this in-house expertise. I asked a few coworkers for advice (helping eachother is at the core of our culture) and sources and was given some great hints, articles (both internal and external) and examples within our own codebase. Now, I had enough information and encouragement under my belt to start - "Hello, World!" style.

2 years ago, I would have started without asking for any help, believing I should be able to learn it all by myself. Asking for help would have been a sign of failure.

Very soon after, I had made simple app with a couple of widgets and states. I had a lot of questions during these tutorials, so I used AI as a personal teacher. Although I believe there's no such thing as stupid questions, being able to ask anythingg without judgement can really help lower the threshold. In my prompts, I deliberately requested the exclusion any code snippets yet; I want to be able to produce code independently first and fully comprehend what's happening. As for my learning journey, I knew this was just the beginning, but I consciously decided not to worry about what's next. No blinking cursor syndrome for me!

2 years ago, I would have felt obsolete and redundant due to the capabilities of AI.

I did realise that the way of working in my sources and test app would probably differ wildly from the way of working at Baseflow, so I decided that this was a good moment to have a look at our codebase examples, as pointed out by coworkers earlier. The repos I inspected adhere to the clean architecture principle, and use Cubit for state management.

2 years ago, I would have felt intimidated by the complicated code, and would have questioned my capabilities to understand what was happening.

Looking into this codebase, I found myself thinking and feeling many things. I recognised patterns within myself and realised I was walking into a familiar trap. Rather than using my ancient strategies and tactics, I appreciated this moment as an opportunity to cut a new path through this process. For me, this started with defusing the situation: I told myself that nobody, not even the absolute pros, understands 100% of a new codebase straight away. I saw it for what it was: an unrealistic goal. I convinced myself I only needed to understand the relevant parts for now: the basic scaffolding and structure of a clean architecture app. The rest would come later. This internal dialogue helped me calm down on a cognitive, emotional and physical level. But then the ultimate question came up: "So, what's next?". It is important to note that this question occurred out of curiosity, not panic.

2 years ago, I would have avoided the complicated code and remained stuck in the gap between having finished the beginner's tutorials and actual hands-on working knowledge.

I was right in assuming I wouldn't be needing a profound knowledge of enterprise-level principles. As a starting point, I fed AI the directory structure of a repo with clean architecture to help me generate an empty project with respect for the architecture we use at Baseflow. It very neatly explained what was unnecessary for now, and what was essential. Once I had this clean slate boilerplate code, I began to think about an idea for an app. To keep the complexity limited, I decided to make a todo app - an extremely common choice, but also a guarantee that my AI teacher has been sufficiently trained on this, hopefully keeping hallucinations to a minimum, and hints and advice relevant. A todo app leans into mobile development and states, which is perfect. To keep things interesting, I implemented a customised sorting algorithm as a service to fully leverage the clean architecture principle. I upgraded it to a Git project for good measure, and asked coworkers for feedback.

2 years ago, I believed that making mistakes is bad, and should be avoided at all cost.

‍

"So, what's next?"

Having created a solid project has given me the confidence to build upon it. To this end, I created several tickets in Github's tracker. I've learnt to keep the scope of the features limited and doable. I have no idea how to begin implementing them, but I'm quite sure I can do it, since the same divide and conquer strategy helped me tackle the complexity of clean architecture and Cubit.

Reflecting on my Flutter journey so far has given me valuable insights. I am doing a lot better now compared to when I started working as a software developer. I can recognise unhelpful or even hurtful patterns and take action. Actively seeking help from others comes much more naturally now, and is instrumental in my learning journeys. I've learned that failing is not only fine, but also extremely helpful. I am aware of my weaknesses, without diminishing my potential or myself as a person and developer. I'm very much aware of my lack of experience and knowledge, but I'm also very confident this will all come in good time.

At its core, developing software is challenging enough. It makes no sense to complicate it even further by making it personal; drawing personal conclusions from failure is one of the biggest obstructions to maintaining a growth mindset.

If my blog resonates with you, here's a few questions that could be helpful when you find yourself in a similar situation:

• What is the smallest piece of this problem I can understand today?
• Who around me already knows something about this that I could learn from?
• What would this situation look like if I approached it with curiosity instead of judgement?
• And perhaps the most important one: what would I try if I was not afraid of getting it wrong?