Take the time you need
Photo by Ben White on Unsplash
Since writing my reflection from week 1, I realised during these past 4 weeks that I just needed to take the time to comprehend what has been happening. The past 4 weeks took a lot more out of me than I realised. Learning new concepts everyday, then trying to complete weekend challenges was intense, to say the least. Makers did notify us of this from the start, but I don’t think I truly felt the intensity, until I realised I wasn’t reflecting on my weeks. Time really flew, and before I realised it a whole month had gone by. So now is a good time to actually look back and reflect.
Week 2
As long as you try your best, that is all that matters.
I did not get a chance to fully reflect on week 2, mostly because the weekend challenge from week 2 had left me rather distraught.
During the afternoon pairing sessions, I was rather happy about being able to use week 2 to further practice my Test Driven Development process. This was something I found helpful as for that week, I wanted to try to do the Oyster Card challenge without looking too much through the walkthroughs. This was easy enough until you come across an error you did not know how to fix. Luckily, I recall my pairing partners for that week were helpful in allowing me to bounce ideas off them and guiding me down correct paths.
One concept I knew I needed to look further into was testing behaviours not states. Some things I needed to remember and understand to be able to implement behaviour testing are encapsulation, who or what is the user of the code written, and what job is this code doing for that user. By testing for behaviour you make your code more maintainable and also make it easier to refactor your code without having to change the tests you have previously written.
Photo by Tracy Adams on Unsplash
I was enjoining having that week to work more in using a TDD approach to writing my code. This really helped me to understand how to start my code, and helped me use the errors I was getting to guide me on how to fix and implement what I needed. Other things I was able to pick up on this week were using irb to write feature tests and guide me to know what I wanted my code to do and show; RSpec and how to write RSpec test and not needing to know the proper syntax for RSpec, just needing to know that there is a concept and knowing how to Google for this; and setting a constant in a class.
We learnt about domain modelling, and how to use the user stories to help us think about how we would be coding. I found that learning about this was really useful especially for the weekend challenge, as it gave me an idea on how I could tackle my coding.
I had finished week 2 on a really good note, I felt that I had understood what had happened that week and even felt more confident in tackling the weekend challenge. I had really enjoyed the week as I was able to prove to myself that I had understood what we learnt that week and last week. However, the weekend challenge was a whole different story.
I had thought I understood the weekend challenge, yes it did take me a lot longer to figure out how to go about creating the classes that would link with one another to create a functioning takeaway. My initial thought for this was to go as basic as I can. I thought about how you would create a method that would allow the user to see the menu, then order from the menu, order more that one variety of dish from the menu, then how would you show how much the total is. This was all relatively straightforward. The thing I found myself struggling with was the Twilio API. I tried to follow the instructions to set up the Twilio to send text messages, but I could not figure out how to get it to work, or how to hide my personal details. I tried to research about this but nothing was making sense to me and I just could not figure out how to go about this.
Photo by Daniel Mingook Kim on Unsplash
That small part did affect me a lot more than I realised, as I started to question why Makers were not just teaching this to us, but getting us to do something we have no idea how to use. I realised that I needed to change my perspective on this. The growth mindset came to mind. I needed to remind myself I was only on week 2 of this course, and everything that did not make sense then would make sense the more I go down this path.
Looking back, I can now say that I may have approached the whole Twilio API wrong. Now having a bit more experience, Twilio does not seem as scary and actually more fun. Fun to be able to just trial and error and learn from my errors instead of just throwing in the towel because I did not understand it.
Week 3
Don’t Panic and don’t compare
Week 3 started off with us learning how to code review. This is both really discouraging yet inspiring. The biggest discouragement I had found was that I felt as though my code was not good enough and did not make enough sense to show another developer. In addition, imposter syndrome was running high, making me feel as though others were much better and knew more than me. However, I knew I needed to throw this ideology out of my head. My code is good enough, I understood what I needed to do with each challenge, and got my code to work. After code reviewing a peer’s code and having my own code reviewed allowed me to understand the benefits of code review, and inspired me to write better code and learn from my peers. Code reviews allow us to write high quality code and improve our code. It is also really fascinating to see how someone else tackled their coding and how we all approach the same topic differently. I really needed to remind myself to not compare to others, and just remind myself was I a better developer than I was yesterday?
Photo by Vince Fleming on Unsplash
This was one of the more interesting weeks. We were learning how to build a simple web app. Finally!!! I was really happy about having a visual front-end to actually see the code I had written. I really enjoyed the pairing session in week 3, we created a simple mortal kombat style game. It was just the bare bones, but it gave an idea into how these basic web page apps are built.
Week 3 we learnt about servers and clients and how HTTP servers worked. We were further learning about the relationships between these and how they interact with one another to provide the webpage users see. We were also introduced to Sinatra and Capybara. I think the hardest thing to grasp this week was learning how the MVC model works, to show how a web app is actually made, and how to use TDD to develop these apps. We learnt how to use Capybara in our feature tests, and how these stimulate a user interacting with a website. I finished this week feeling a little lost and unsure about how confident I was with everything that was taught this week.
Photo by Campaign Creators on Unsplash
I found myself in the same boat as last week’s weekend challenge. Even though I felt like I understood everything that was happening in the afternoon paring sessions, I found myself so lost and confused on how to do this weekend’s challenge. I was using the same walkthroughs as the afternoon’s session, but I found myself being stuck and not knowing how to link the unit test, feature test, app.rb and classes together. This honestly made me feel rather stuck. I was starting to have thoughts about how behind I was, why I didn’t know this stuff already and whether I would ever be able to ever catch up. All these thoughts somehow overtook my week and every free time I had was just filled with these negative thoughts.
All of this made me realise, I needed to take more control back on my learning. I decided that from this week I need to do more daily coding, and actually read up on the concepts that I feltl unsure about. In all honesty, I was trying to just stay positive and trust the process, but those lingering thoughts kept entering my mind. Rather than breaking down and crying over this, I recalled thinking to just breathe and start doing the extra weekly practicals.
Photo by JESHOOTS.COM on Unsplash
At first the weekend challenge was going well. I knew what I was doing, but I got stuck and just did not know how to solve my errors. This was the first time during these weekend challenges that I felt an actual mental block, I realised I just did not have the mental capacity or motivation to fully complete the weekend challenge. So rather than further stressing over this, I submitted what I had done and called it a day.
I recall my mentor talking about this “click”, where everything just starts making more sense. I remember hoping that this “click” would happen soon. Everything just felt a little overwhelming with the constant overload of new ideas, but comparing it to previous work stress, this was different. I did not shy away from this stress, I still woke up everyday willing and wanting to tackle what I needed in order to achieve that “click”. Yes, I had been struggling, and had felt as though I was not absorbing a lot, BUT I decided to take this as an opportunity to show myself what I am capable of learning and creating.
Now looking back at the weekend challenge, I realised I needed to understand the Model -View-Controller design flow better, and needed to tackle my debugging more effectively.
Some tips I learnt to help with my debugging process:
- Read the error message to understand what the error is
- Look at the stack-trace (line number, file where the error occurred, follow the flow)
- Get visibility (p)
- Have a process: tighten the loop i.e. narrow down to source of the problem
- Run code in a REPL
- Stack-overflow, google
- Documentation
- Chrome dev tools
- Ask someone (peer, coach, stack-overflow)
- Take a break
With this I realised the weekend challenge was again not as difficult as I had made it out to be in my head. Lesson learnt. I now feel more confident that when I have a chance to go back and redo that weekend challenge I would be able to solve it.
Week 4
It’s not hard it’s new
Week 4 started off on a much better note compared to the previous week. Again we started the week with another code review. As I did not complete the weekend challenge, I was looking forward to this review session to see how others had tackled the challenge. This was a really productive code review, as both my reviewer and myself were able to discuss our code in detail, talked through what we actually wanted our code to do, and even helped each other figure out how to tackle our errors.
Photo by Charles Deluvio on Unsplash
I found these afternoon pairing sessions really helpful. At the start of the week, my pairing partner and I both agreed to take our time fully understanding everything we were doing before moving on to further chapters, this included doing extra research there and then. I found this really helpful, as I was able to note down why we took the steps we did with every chapter. Another pairing partner showed me a different way of pair programming which I found really helpful for this week. We both worked on our own code, while sharing each other’s screen. This allowed us to both write the code, I found this really helpful as I was able to write the code out and fully understand what we were doing. Another partner helped me see and understand the MVC model better by both of us creating sequence diagrams to understand the flow of our app. My last partner that week, had helped me see that I was overthinking the CRUD and to simplify how I wrote my tests to understand how the delete part of CRUD worked.
I found that I was able to learn a lot more this week, and understood how web apps are created. Things I learnt this week: object-relational mappers which is learning how to interact with databases using our language of choice; SQL which is the language used to interact with databases from your command line; HTML forms and how these are used as the template of what users see on a webpage; CRUD cycle and how they are the basis of every web app; Class Responsibility Collaborator(CRC) a form of domain modelling that shows how classes interact with one another with the use of database; database relationships such as one-to-one, one-to-many, many-to-many and many-to-one.
I had ended week 4 on another really good note. I was feeling more confident with my coding, and felt I could actually tackle the weekend challenge. This attitude did help. I found myself being able to properly plan my coding for this weekend challenge, and for the first time actually produced really good code that I was proud of. I was on a good high and was feeling that maybe that “click” was happening sooner than later. Makers mantra “It’s not hard, it’s new” made more sense this week. I understood everything a lot more, because we had a second week to further understand the new concepts of web app developing.
I do want to go back to this weekend challenge. Even though I had done really well, I feel like with my additional knowledge and experience now, I can create a much better chitter than the one I had previously created.
Week 5
Show up, make the effort and the rest is a bonus
Hands down I must say this week has been my most favourite so far. This week was our first week working in a team to create our own mock Airbnb. We had to plan and create our own MakersBnb from just headline specifications. This was really exciting, as this was sort of an insight of how we would be working in the real world once we graduate from Makers.
At first, when I found out we were doing group work I was a bit uneasy. This was probably due to the past unsuccessful and horrible group projects back in school and university. So going forward, I decided to go into this week with an approach of I will put in my effort and wish for the best.
We started off the week by have a morning session where we created a Trello board to help us keep track of our workflow, we discussed and noted our personal goals and team goals, and set the main objective for this week was not to create an fully functioning app, but more on having this week to consolidate and have a chance to work on concepts we were all struggling to fully grasp from the past 4 weeks. We also discussed our MVP and how we would approach this. The rest of our afternoon consisted of us creating and breaking down our user stories and creating our sequence diagrams. We also decided to run a trial Git Workflow to ensure that we all understood how to create branches, checkout different branches, merge and solve any merge conflicts. I remember finishing off the day feeling really motivated and excited to create our web app.
As a team, we agreed to have stand-ups every morning to separate our tickets, and allow each other to pick the tickets they wanted to work on. Our tickets were broken down to link with one another’s personal goals. This was really helpful, as it allowed us to work on the things we were not comfortable with. We had a check in with the coach, this was good as it allowed us to see if our approach was good. This check went well, as the coach mentioned how well our planning was. We were told that our tickets did seem ambitious, which did come back to bite us later.
As we had paired off throughout the day, we ensured that our communication with each other was open. This allowed us to reach out to each other when we needed help, and allowed our team dynamics to really flow. Every afternoon, no matter what stage we were at, we had decided to hold retros. These retros allowed us to share knowledge, explain to one another what we had done, helped give fresh eyes to any debugging issues and ensured that we all understood the state of our app. It was also really rewarding to be able to move tickets into the done section of our Trello board. We discussed what needed to be added, and created more tickets to work on for the next few days. We even created a knowledge sharing tab that allowed for any notes made throughout the week to be shared and accessed by everyone.
Some additional things i learnt this week were using a rakefile to set up your database; bcryt gem to authenticate and encrypt user’s passwords; learnt a more efficient way of writing feature tests and how to use a TDD approach with this; debugging tricks like save_and_open_page to help show you what the error is and how to go about fixing this.
Our team was able to create an amazing functioning mock airbnb app, but with every accomplishment it is good to look at what can be improved for next time. So looking back I think our app would have been a lot better if we had more time to properly plan our domain models, to ensure that no tests needed to be re-written and to ensure that pairs would not produce duplicate code. We could have planned around blockers a bit better and used our stand up and retros to rewrite our plans to help solve our blockers more carefully; we could have also added a bit more features such as adding pictures to our listing, so users could have a visual look of what listings looked like, and maybe if we had started our css a bit earlier so that we did not need to rush on the last day with making our app look aesthetically pleasing. If we also had more time, it would have been nice to actually explore different gems to see how they work, and how we could have implemented them to our app.
Overall, I thoroughly enjoyed this week and really like the insight of how development teams worked. I found that I really like working in a team as it helped remove a lot of the stress of coding by yourself, it also made the whole week a lot more fun as we were all interacting with each other while coding and just enjoying the whole experience. I found that this week really relied heavily on communication and making the effort. As we were all working on accomplishing our personal goals along with our team goals, we found that we were making the most of this week by consolidating all of prior learnt knowledge and in the long run we had the added bonus of creating an amazing web app. Shout-outs to my teammates: Finn, Matt and Kane — thanks for the laughs and for the work you all put in to creating an amazing app ❤️
Some things I hope to bring with me the next time we have a group project are to plan as much as you can, create sequence diagrams, domain models and just plan everything as this planning really does help with the approach to your test and coding later on. Have fun and don’t take things too seriously, developing is a lot more fun when you enjoy what you are doing and it is a team effort, so make the effort to actually be part of the team, show up and participate, it will all pay off later. Communicate, communicate and communicate again, working with different people can lead to a lot of assumptions so open up, speak up, ask questions, offer help and share ideas. All of this really does play a part in making sure the team dynamics work well together. I was really fortunate to have had a wonderful first group project and I hope I have many more amazing group projects in the future.
