Stop, think and break it down
Week 1 completed. So much information to take in, so much to reflect on. First things first, BREATHE. I don’t know how many times this week I had to remind myself to stop, and breathe. I found myself joining the lunchtime meditation sessions everyday. Those sessions really helped. They were ideal especially in helping me have the right mindset for that afternoon’s pair programming.
Let me just say that, this journey so far has been exciting. I really appreciate the fact that not only am I learning a new skill, but actually submitting to this process, I’m learning a lot more about myself.
The whole concept of accountability to your own learning is really hitting home. My whole attitude to what I am learning, and what I am doing to improve my skills, all falls on how much effort and work I put in. For several years, my brain had been so used to having a lecturer teaching and showing me the one correct way of learning the set objectives, them marking my work to give me a grade that would justify whether I memorized what was “taught” to me. To stop myself from falling into my usual cycle of passive learning, I am learning and practicing a lot more accountability on myself. My learning methods have been tested this week, and I’m learning about how I actually learn. Note taking and writing up what I have learnt, peer discussions, diagrams, practice and even more practice are things I found have helped. Giving myself this responsibility has allowed me to fully appreciate the joy when I figured out errors and created programs that run. In a way, it’s as though the fun in learning has come back.
There has been a lot more self-led learning time than I had anticipated, and ensuring I set myself some goals and objectives have been helpful in ensuring that I am not wasting these days. One of the challenges I faced that week was setting myself some goals. I was finding this rather difficult, as I couldn’t figure out the goals I wanted. In the end, I decided on using the Makers course goals. Personally, I think if I am able to confidently say I can make software, I’m equipped for long term growth and I help my teams succeed, I have successfully accomplished the purpose of Makers.
I can make software, I’m equipped for long term growth, I help my teams succeed — Makers Course Goals
I think there were moments from this week where all the information I got became too overwhelming. There was a point after one of the workshops where as soon as the zoom call finished, I was thought “What just happened, I don’t get it, WHAT?????” I felt so uncertain about what we were just taught. I’ve read about imposter syndrome, but there were more times this week I had thought I was on the wrong career path due to the fact I felt I did not know enough, or even knew what I was doing. However, I took this as a learning challenge and allowed myself to look into the concepts that I did not understand, try out some of the additional coding challenges to help me build up my knowledge and feel more confident with what was taught. Yes at first it can seem rather daunting not knowing what it is you are doing, but using the resources you have around you can help ease those anxious thoughts. You truly are responsible for your own learning.
Test Drive Development. This brand new concept did take some time to get my head around. However, getting my flow of coding to consist of planning, then feature testing, creating a unit test to finally writing code to pass that test took a lot of getting use to. I remember thinking back to the pre-course weeks, I had hardly used irb to help me code, but this time round, I used it to help understand what I needed my code to do. Following a TDD method allows you to ensure the code you are writing actually fulfils what the client is asking, you only write code that you would need and you gain more confidence in the code you are writing as you know it passes the tests you specifically put in place.
One thing I found really helped me with this was having a diagram to visually see how this flow of development worked:
Users stories were at first difficult to understand, but once you break it down to nouns and verbs, then to objects then messages it became very useful in understanding how to start your coding. In a way you are firstly thinking about how you would set up your code. This was something I needed to work a lot on, as I was used to just jumping straight into coding. Taking that moment to stop and plan how you will tackle the problem, really helped in understanding the code you needed to write. Using things such as pseudocode, diagrams and even discussing it with your pair programming partner, really helped in getting the idea out of your head and onto paper.
This is where I really appreciated and developed a liking towards pair programming. The concept of having a person there to help keep an overview of your code, bounce ideas and even teach you on concepts you may not have known really contributed to self-led learning. It was both inspiring and nerve wrecking to pair programme. Inspiring when the both of you were able to figure out and fix the errors you were faced with and nerve wracking I think mostly for myself and breaking out of my shy shell. However, I took those moments and ran with it, I decided for myself in order to progress and get the most out of the sessions, I knew I had to overcome my shyness. So far after a few pair programming sessions I think I have improved a lot.
Some main takeaways so far, arrange breaks with your partner, take turns driving and navigating and build up your communication skills by ensuring both your partner and yourself understand what you have created. Having breaks in between your coding helps break the session into more manageable slots, and even helps productivity. Driving and navigating, learning these roles took some time to understand and implement. The driver is the one who is writing the code, focuses on the tasks at hand and the navigator keeps an overview of the code that is written and reviews the code as it is typed in. I think I am still getting to grips with both roles, but have found having good communication and a review talk after each session with your partner on what went well and what you can improve on helps you get better with this. Communication is definitely key when it comes to pair programming. Also ensuring you speak up when your partner is entering code you do not understand, and even talking through the process of your code is very helpful.
I had found that the weekend challenge this week went really well. At first I was confused and unsure about how to even start the challenge, but after breaking down the user stories, planning how I would tackle the code and using irb helped me understand what it was I needed to do. In addition, I thoroughly enjoyed being able to google and use the resources we have to complete the challenge. There was that sense of pride and joy when your code would pass the tests you created. Yes, some concepts are still difficult to get my head around, such as rspec and the different types of tests you could write, but I have found with more practice, it is becoming more understandable. When you actually take the time to document what you have learnt this week, you realise in a span of only one week, you have already learnt so much.
Although a lot has already been learnt this past week, I still have this uneasy thought at the back of my mind telling me there is still a lot to learn. For the remainder of these weeks, I think the things I could improve on would be to actually do more practice on the topics we learn that week. Possibly spend a bit more time doing the extra challenges, continue to have fun, not compare myself to others and just focus on this journey and my progress. My biggest challenge would still be learning to not let that voice of doubt and fear stop me from enjoying and making the most of this journey.
