An Experimental Mindset – Learning Quickly, Reflecting Deeply @ Makers

An Experimental Mindset – Learning Quickly, Reflecting Deeply @ Makers

It’s been just over six weeks since I embarked on my programme at Makers and wow has it been one crazy ride! As I’m sitting on the train, I reflect on what’s been happening, trying to digest it all. Settling into a new environment, new routine and meeting new people has been an exhilarating experience. So what’s been going on you might ask?

An Experimental Mindset – Learning Quickly, Reflecting Deeply

From an earlier blog, I spoke about putting on that child-like mindset, the boundless state of mind where creative juices run with the desire to experiment and make stuff!

Here’s the quote from my blog:

“When I was 5, I got my first computer and wanted to be a computer hacker. I imagined myself working undercover as a secret agent, making potions and hacking through computers, like Disney’s Kim Possible saving the world from monsters!”

The truth is, this childhood feeling never really left me. It was just hiding away, waiting to be re-discovered.

Over the past couple of years, I realised that at times when I thrived, it was a matter of having the courage to take risks and the resilience to bounce back from setbacks. It was only during the past week at Makers where I began to feel comfortable with the unknown and live out my experimental mindset. It was only by doing this that I felt like I was riding the wave. Learning quickly and reflecting deeply has been really effective to my own well-being and personal growth.

undraw_creative_experiment_8dk3.jpg

What’s it like to learn coding?

The fast-paced learning at Makers means I might be introduced to a concept (or even multiple concepts) in the morning and then apply them to solve problems in no time at all – iterating towards weekly goals. This took a bit of getting used to. Instead of waiting for the ‘perfect’ time to apply theory to practice, it was about being pro-active and jumping off the diving board, testing ideas out straight away. Having a boundless, experimental mindset makes learning engaging and is helping me and my peers to generate more innovative solutions – totally great for solving tricky problems.

At times, this required me to dig deep. I am a perfectionist at heart and this meant I felt uncomfortable when I did not understand the ‘whole’ concept straight away. Though, when I let go of this side of me, I experienced something called ‘Beast Mode’, this mode describes the feeling of being ‘uncomfortably excited’. This is the ideal state of mind to test ideas out without fear of failure. Having this experimental mindset is key to riding the wave with confidence, something I want to harness and continue.

It’s not just about writing code, it’s about the process

It is time to put the ‘human’ back into technology. It is so easy to think that technology is all about writing code like something from ‘The Matrix’, but it is all about the people and processes. Whether it is creating a sustainability application to improve people’s relationship with their environment, or an app to aid learning in museums, technology is empowering and transformative.

Here are a non-exhaustive list of some of the processes I encountered over the past couple of weeks and why I think they are important:

User Requirements

Great ideas are generated all the time, but how can these ideas translate into something tangible? It all starts with the User Story. User Stories, describe from the users’ point of view, what they want to do, why they want to do it and how they will achieve it. A User Story has a beginning, middle and an end. Agile teams use stories to flesh out user requirements, conducting proof of concepts, assessing the technical feasibility, sketching out designs and creating a feedback loop to improve the overall approach. Even when a feature is released to the end-user, more feedback can be sought to further improve the product and user experience. It takes a multi-disciplinary team to make this happen, not just developers.

undraw_user_flow_vr6w.jpg

Modelling/Diagramming/Object-Oriented Program Design

In technology, to solve a problem, you have to start by modelling the world you’re trying to simulate which is an abstraction of reality. It is impossible to model every single data flow/relationship between things perfectly and instead, you go for a model which captures enough to successfully help you understand things a bit better.

Diagramming describes the process of visualising the domain (the world you’re trying to model). There are plenty of tools and techniques available such as flowcharts, wireframing and class diagrams, just to name a few.

Test-Driven Development

Test-driven development is the process of developing code from the test first. At the start, it is a change in thinking, but it is such a powerful process. Rather than diving straight into the code, the aim is to write the test first which is derived from the business requirements and write the simplest code to pass that test. Once the test is satisfied, some refactoring is done to tidy up the code. This is called the RED-GREEN-REFACTOR loop. By writing the test first, this guides the development of the code to ensure alignment to the requirements.

Testing in Web Apps / User Experience

Combining test-driven development to a web application is like adding another layer to the cake. I’ve been using Capybara for feature testing on Sinatra applications. This enables testing from the user perspective as they navigate through the application and captures the business logic and acceptance criteria for satisfying the user requirements.

It is not uncommon to find combined testing approaches throughout the whole software development lifecycle. For example, in my Ruby-Sinatra application, I may start by writing a feature test which tests out the business logic and how the end-user may interact with the application, and on top of this, I may refine the logic further through unit tests which lead me to passing the feature test. So far, I’ve been using RSpec for Ruby and Jasmine for JavaScript. Of course, test-driven development is not the answer to everything and can be combined with other approaches to reflect and iterate on the requirements and code development. A powerful way of checking that the business acceptance criteria is satisfied is getting feedback from the users and undergoing a User Acceptance Testing (UAT) phase and building this into the Agile development process. Collaborating in a team, you may have to test your builds are working, as well as system integration testing and penetration testing for security purposes – so testing is not something to be underestimated!

Something I want to explore over the next couple of weeks are progressive web apps and how they improve user experience.

Pair Programming

By engaging in pair programming sessions, I have been able to learn from others and improve my ability to verbalise my thoughts and the confidence, respect and patience to work with others. Having experience working in an Agile team and tutoring, pair programming is very familiar to me; it’s been great to reinforce this at Makers.

undraw_pair_programming_njlp.jpg

“…being ‘uncomfortably excited’. This is the ideal state of mind to test ideas out without fear of failure. Having this experimental mindset is key to riding the wave with confidence.”

Thank you to Undraw for providing the images used in this blog! 🙂

Byeeeeeeee,

Kim

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s