It's Not Hard, It's New

So it has begun! The full-time Makers course started on Tuesday. I woke up filled with the same nerves and tiredness as when you start a new school. Unfortunately, my lung decided on Saturday to hold a grudge against me and has not been fully co-operating. This is one of those issues I just have to get used to working around. Challenge accepted, lung.

Since I have now entered the full-time course and my free time has dramatically decreased, I have decided to structure the beginning of the blogs from now with The Wins, The Struggles, The Weekend Coding Challenge or The Project, and The Game Plan. These sections will detail areas I feel I have done well in, struggled in, what my weekend coding work was and how it went, and how I can improve, respectively. I hope this provides you, the reader, with a more clear overview of my journey as an aspiring dev, and to also remind myself that even in times when I feel I am overwhelmed and failing, that I am still making progress.

The Wins#

Pairing Parties#

Despite this week being a bombardment of new information which has resulted in many deer-in-headlight moments, where I nod along with my pairing partners comments while Becky is screaming ‘YOU’RE NOT A CODER, GET OUT OF HERE’, it has also been a really positive, and fun, experience.

I am starting to communicate more, and not feel awkward when I want to spend a few minutes quietly reading information. I am becoming less nervous about voicing that I feel we should be taking a certain approach. I have been open to say when I don’t understand something after the deer-in-headlights moments have passed.

I am less conscious of being the driver in these situations too. I have felt no judgement over my skills by my partners this week, and it is very much appreciated. Comments are not personal criticisms, heck they aren’t even professional criticisms; they are just comments to help you both achieve the goal you have been set.

It’s Okay to be Bad#

During the September 2020 Cohort introduction day on Tuesday, we were introduced to the lovely Dana, the Chief Joy Officer, at Makers. While her job title is extremely fun, her role is actually very important; ensuring the mental stability and development of the students during a very intensive period of time, oh and she teaches yoga! During her introduction, Dana instilled me with three pieces of wisdom which have rooted themselves deeply in my mind.

‘Make peace with being bad’

This week has certainly drilled into me that I need to make peace with being bad. (Actually, Dana’s exact words were ‘make peace with sucking’ but repeating that word often within a blog post gets pretty uncomfortable). Everyday I have faced a moment where I was utterly bad at what I was doing, but that is fine. I am going to be bad at software development, at least for awhile. The majority of people were too at some point. The point of learning is to go from being bad, to kinda being bad, to not really being bad, to being good, and then continuing to improve.

So I am trying to make peace with the fact that right now, I am bad, but that state of being isn’t permanent.

‘I’m in control even when I feel out of control’.

It has been very easy for me to fall into this realm where I feel totally out of control, and that feeling in itself makes me feel even more out of control. Feeling this way makes it almost impossible to be productive in any capacity.

I do however have the mental tools to control that feeling in both a technical and personal capacity. If I encounter a hard challenge, I know how to research the problem or reach out for help. If I encounter a difficult period in my life, I have developed the confidence to regain control by prioritising my needs.

These coping mechanisms may not completely remove the feeling of being out of control, but they are a way of controlling the ship until the waters have settled.

‘Am I 0.1% better than I was yesterday?’

I have little desire to actively try and be better than anyone else. I just wish to be better than my previous self. When Dana spoke about reflecting on our progress each day, she asked us to consider if we were 0.1% better than yesterday?

I find it very hard to judge my progress; I often only look for very large increases in skill or knowledge and judge my value based on that. Thinking this way, it may be months before I feel confident enough to say ‘I have progressed’ and that is incredibly demoralising.

Asking myself; ‘Am I 0.1% better than I was yesterday?’ allows me to reflect on those micro-improvements, and acknowledge that progress. Do I think today I am 0.1% better at coding than yesterday? Yes. In fact, I would say I’m probably at least 10% better than I was yesterday, but I am now in a place to celebrate that as a massive win, something I couldn’t have done if I was only looking for 100% increments.

Raising Issues#

This is a win for my confidence more than anything. I submitted my first issue on Github! I encountered an unexpected behaviour on a website I like to use, and was able to replicate it a number of times, so went ahead and submitted an issue for it! It was quite a new experience with the submission etiquette, and I was very close to writing ‘This is my first issue, be kind!’ but I was quite happy with the level of detail I gave.

It could be a case where it just effects me, and if so I worry that I may have wasted someones time, but hopefully (but also hopefully not?) the maintainers are able to replicate the issue and fix it.

I have been told this is the first step to becoming a contributor, which is something I would love to be able to do in the future!

Peer Groups#

In addition to my mentor group, I also now have a peer group with 3 other members of my Cohort. We have a check in each morning to see how everyone is doing and to discuss the wins and challenges we face, along with some specific learning objectives. It’s been really nice to have a set group to go to and confide in, and, since the course is remote for everyone, to just be able to connect with others properly on a daily basis. It’s been a help at conquering the shielding loneliness!

I am a Cube Master#

Nothing more to say here than I solved my first Rubik’s cube this week!

The Struggles#

Tear Driven Development#

I have spent weeks, no, months, trying to teach my brain how to do things with code, and how to understand it. As of recently, I felt I have had some breakthroughs. Hashes do not scare me as much, neither does an Array of Hashes, which once felt like a mythical beast that would be more at home at Hogwarts. I am not, in any way, close to being a fluent programmer, but I was certainty clearing snow off the path on the way to the destination.

Then TDD, the metaphorical, once in a lifetime snow storm, comes and dumps everything it has in those grey fluffy clouds all over my path. That’s okay though, I still have my snow shovel.

TDD feels, right now, like the first time I opened my MacBook and said; ‘Right, I’m gonna try learn to code today’. It feels uncomfortable and foreign, and it’s returned me back to this state of having no idea what I’m doing. It’s so frustrating.

I had my first experience of TDD, using the RSpec framework, during the last week of the Makers pre-course. The FizzBuzz challenge was relatively simple, as I understood the concepts I needed to use, and I knew how my program was supposed to behave. Now, just one short week later, I am not only having to use the TDD method, but TDD a program that is a lot bigger than anything I have completed before, while pair-programming with new (and really lovely) people, while also being introduced to many new concepts, such as raise_errors.

It all feels very overwhelming and hard, but is it actually hard, or is it just new?

Breaking down the user stories, the requirements we negotiated with the client, and only implementing exactly what is asked for has been the largest challenge. This is a very new concept to me. I struggle to stop myself rushing ahead and building what I think they may ask me to build in future requests, rather than just what is being requested now.

This has caused me to do more work than I needed to do, as I may implement something I think the client requires, and either turns out to be different from what the client wants, or not necessary at all.

I have also struggled to know how to write the tests which test for what I want something to do. I’m sure the more I do it, the easier it will become, and during the weekend challenge I felt like I was making progress. Part of the issue is not knowing the correct syntax, or knowing what I actually want output.

I also found myself in a bit of ‘I finally have a test that fails, and I have written code to make it pass, now I can’t ever touch that code again’ mindset, but the weekend challenge, again, has helped with that.

Despite the whole tear part of TDD, and the lack of enthusiasm shown for it from some of my very experienced dev friends, I’m finding that it is helping me really consider what I code, and what my code is supposed to do. I just need to get better at that!

Priorities#

I don’t feel like there is enough time in the day. How can I feel like this on the first week? There was a public holiday in the UK this week on Monday, which meant we only had 4 days (3, if you don’t count the introduction day where no coding is done) to achieve what needed to be achieved. I suppose it’s good in the fact that I have not been lulled into a false sense of security. This course is intense, and intense from the get go.

Each week we have learning objectives, and every day (I believe) we have self-study time to work on these learning objectives. This week we had four main goals; TDD a program, pair using driver-navigator style, learn how to debug effectively and describe object-oriented principles such as encapsulation and the single responsibility principle (SRP).

Knowing what to prioritise, how much time to give to an objective, and being confident enough to know when to step away from an objective, has been really challenging. Naturally, I want to be able to know everything we are set to learn in detail, but the time constraints means that probably isn’t possible. My mentor has guided us that we will consistently revisit these principles as the course goes on and not to worry about getting it immediately, which brings me some comfort. Now I just need to remind myself that not being able to recite things off the top of my head does not mean I am falling behind the curriculum.

The Weekend Coding Challenge#

Catzkorn Air and Airports#

Each weekend we are assigned a solo coding challenge, which we submit for code review during monday mornings. This weeks challenge was creating a TDD airport using a number of user stories. The challenge builds on a lot of the skills and concepts learnt during the week, as well as introducing some new ones like method stubbing.

I first sat down on Friday night and started writing and diagramming out my stories. I felt pretty confident with how I wanted my plane, airport, and weather programs to interact with each other and what methods they would need to have. Then I made a massive mistake.

I accidentally clicked on a link that I misread, in two places, that was a code guide on how to finish the challenge, with example answer code. I didn’t read it all, I just saw the first answer snippet then thought, ‘Oh no I am not meant to be reading this!’ before seeing the massive DO NOT READ letters at the top of the page. That small snippet was all it took for me to think my ideas about my testing strategy, objects and methods was all wrong, and start to write my tests to fulfill the example code.

I felt dejected, the code I was writing didn’t feel as fluid as the plan I had originally created, and I was jumping between the user stories to fulfill what I thought I could technically do, and adding features which weren’t requested at certain stages. This wasn’t TDD, and it wasn’t achieving what I wanted to achieve.

So on Saturday morning, I scrapped my code and started again, how I originally intended to, using the program structures I wanted, and following the user stories strictly. I’m so glad I did. I learnt an incredible amount about TDD and writing tests in the 5 hours I dedicated to this task. It may not be the same code that others will produce, or the same structure, but it fulfils the user requirements and I’m quite proud of how it reads.

View my code here!

The Game Plan#

Write Those Stories, and Stick to them.#

To improve my TDD skills, I am going to spend more time physically writing and diagramming my user stories, and then sticking to them (within reason). The more confident I am in knowing what I want to achieve with my code, the easier writing the tests, and subsequent program, will be.

But tears will still be shed in the future, I’m sure of it.

Time to Block#

I need to try spread my time over my learning objectives and I want to give myself the peace of mind that I am effectively working towards the overall course goals. To do this, I am going to block time for study towards individual learning objectives within my self-study sessions and have an additional unassigned block. Anything I feel needs more time can be alloted into this block for further study.

It may not be a perfect method, as some topics may need longer in the initial phase than others, but it does mean I won’t get lost in rabbit holes of topics and completely neglect others.

Commit, Commit, Commit#

Until the weekend challenge, I was most certainly neglecting to commit my code often. During the weekend challenge, I committed to commit every time I created a test that errored as I expected, every time I got a test to pass, and every time I refactored code. This has given me all these snippet’s of code to go back to, which has been very handy!

I want to keep this habit up, so I’ve put a bright pink post-it note in front of my keyboard that says COMMIT. COMMIT. COMMIT.

Now I Sleep#

I am writing this end paragraph as one very, very tired individual. I knew this week would be hard, as I have been out of the rigid structure and intellectual challenge for quite some time, but I wasn’t prepared for quite how mentally and physically taxing it would be.

But it feels good. I feel like I have accomplished something and I woke up on Saturday excited to work on my coding challenge. Next week can’t come soon enough, but maybe I can have a little sleep between now and then.

I hope that these posts will become more technical in time. I have some anxiety around writing technically, especially about topics that many on the internet will know far more than I. I had this same anxiety with my PhD field. I think I just need to rip the band-aid off.