Why should you care? I likely should’ve provided this question and its answer even earlier. You really shouldn’t and don’t have to. To put it simply, I  fell in love and want to share it. I feel there is value to journeys even when they are the very subjective and individual kind. Mine is of curiosity, puzzles and sometimes alogical leaps of logic and if one person engages with code as a result of this account, it will have been worth writing.

Like with many things there is a broader story here that I’ll take liberty to outline here briefly. In theory I will have started learning very early. As a kid, mimicking my father building tournament trackers for bridge and other programs in Delphi, I’ve engaged with truly Object-Oriented programming, making a program that changes shapes and their colours and a trying my hand  with a simple collection tracker ( I think it was coins then! ). That’s where  it fizzled, I didn’t know the language, be it English or Object Pascal nearly enough. I’ve moved on to other things. Few years later excel snuck its way into my life, writing mission summaries to “optimise fun” in EVE online (as one does. Duh. Drakes don’t buy themselves). Starting and mostly staying simple at that time, but then curiosity kept on driving me to explore, and over the years, as the life went on when an opportunity presented itself I kept chipping away, one quirk and method at a time. Using it with work whenever I could just because it made sense to automate things ( Thanks XKCD(https://xkcd.com/1205/), relevant as always ) and actions. 

I’ll interject and say, if there is one takeaway it’s that Excel is the Gateway drug into coding(Mine at least, there should be a few!). So if you don’t want your kids to get into writing some black magic fuckery in a dimly lit basement on an ergonomic chair, keep them away from VLOOKUPS.

It’s the VLOOKUPS that got me into ‘trouble’ (“Prefer single quoted strings..” -  I have linter induced PTSD, consider double quoting here an act of defiance. Rubocop isn’t real, it can’t hurt me outside of my IDE) . At work at the time I’ve found a department I was interested in joining, and they had SQL listed as “good to have” so I did what every sane person does and just dove in. It was interesting, SQL with all of its idiosyncrasies was , I was finding, genuinely fun to learn (In part thanks to how interactive and easy the process was with sqlbolt.com). Then, after I will have applied and moved to the department I wanted, I got more opportunities to make it all work, once again starting with the single minded enthusiasm of someone that likely should but doesn’t know any better I started writing my SELECT *’s. Until a project came along which required I learn, hard and fast. I found something I believed in, no one else really considered a problem, and needed data to make and drive my case home. In doing so I’ve conducted my first pieces of corporate data analysis on the bits and pieces I had to pull myself, and I was instantly hooked and starting to drive off the deep end.

It’s shortly thereafter when I was visiting a dear friend who just happens to be in the industry and I’ve  had the opportunity to pop the question. “If you were to start learning programming right now, what would you do? What would you use?”.  I, at that point in time, had no idea he’s had a hobby going. Teaching people to code. We’ve talked, agreed on terms, made arrangements and my “formal” training was underway. One of the main, key questions he will have asked, whether I wanted to be employable as soon as possible or learn about coding. I was then, and actually remain happy with my position, even if now its significantly different to what it was then. I was in no rush, I wanted to learn.

We’ve started slow, but quickly picked up steam. Reading back through notes, writing this, I’m overcome by nostalgia and sense of accomplishment. On 31st of October 2021, I’ve learned that Chrome had an option to inspect a website and developer tools.  Today as I’m writing this it’s the 26th. We’re closing in on a year, and I’ve been using this same function to optimise using turbo with my personal projects, becoming increasingly more comfortable with all these awesome technologies and am able to create and deploy my own web based pages, apps and projects. 

Since that initial meeting on the 31st last year we’ve had 40 “sessions” this past year. 

I won’t bore you with story and details of all of them. One of them however, moreso than others, was key to what has been my favourite pastime this last year. During the second session, Dawid has asked me to check out tryruby.com. Mentioned exercism.org and we’ve still had the plan for me to learn different languages and settle for something down the line after I’ve had more chances to engage with the basics. I ended up hooked on Ruby like it’s my first time eating apple pie that wasn’t defiled with cinnamon (hot take, I know), we never quite managed to get around to any other language after that during our lessons. I did ultimately get around to picking up javascript but that’s a story for a different time.

Above you see some of the first code I’ll have written in Ruby sometime in November last year, staying in the food theme. Explicitly returning things like a javascript wielding savage. Exercism has then become a driving force, even more so than both my mentor and I would’ve ever thought. The exercises started to be significant point of discussion in our meetings as with individual steps and completing the Ruby track one by one we’ve tackled all of the common pitfalls, and instead of listing the things we will have touched on one by one, which are many. Instead I’ll talk over the biggest, most memorable and teaching ( or should I say learning) for me personally elements of my coding journey to date. 

My first, biggest gripe and frustration was that my code was ugly, wordy and when trying to improve by checking other submitted replies I was more often than not running into what seemed incomprehensible if not impossible to me. First, initial exercises responded to with sometime clever one line solutions, which to me at that point were very discouraging especially as I was delving outside of my comfort zone on a weekly basis, spending hours on exercises, making trying to keep up with me (as in, keeping tabs that I don’t sharpen my code enough to cut myself) a full time job that no one could really fill. It’s at this moment where having a Mentor was a game changer. We’ve talked about my perception at the time. That “good programmers” have excellent, beautiful, optimal code come off their fingers like it’s nothing. Conjuring what us mere mortal programmers can only dream of.

Above graphic was shown to me by my Mentor in response, as part of discussion under one of John Carmacs tweets (https://twitter.com/id_aa_carmack/status/1466934223831506951) and I still love it to date.

My understanding as I look at this, and something I took and carry with me is that a working solution is okay (to start with) . It doesn’t have to immediately be perfect. All of the “fancy” stuff, its icing on top. Which leads nicely to the second lesson I got out of this one.

Refactoring is king. The code is hardly if ever perfect and even less likely to be perfect the first time you write it. Decoupling(ha!) myself and my self worth from my code and learning to embrace things like at a point in time explicitly returning things from a Ruby function. It’s when re-writing code, especially when you learn about “fancy new tools” or concepts aka. “I didn’t realise mapping was a thing”  or “oh sugar snaps gee wilikers I shouldn’t have this layers of classes rely on one another”, that the growth happens (at least it feels like that was the case for me). 

And the third, final and maybe most important lesson was the importance of Test Driven Development. The Red-green-refactor approach is a cherry on top of the discussion started from a place of frustration and feeling of inadequacy. And I can’t understate how important that has been for how I approached every next step of my coding journey after that, it’s from that experience that I’ve learned to understand when that feeling snuck in, impostor syndrome, inadequacy driven by frustration or struggling with a genuinely difficult concept that you feel you really should just “grasp”.

And by god, I needed that the first time I’ve butted heads with blocks.

My first run in with blocks was, how do I put it in a safe way, difficult. Yes. I might have switched languages a few times to look for sufficient profanities, as the concept at first was integration level elusive to me. And like integration, once it clicked, it was sunshine and roses. Kind of.

I’ll link here the last article I’ve read on the topic, which differentiates between blocks, procs and lambdas in Ruby nicely (https://www.rubyguides.com/2016/02/ruby-procs-and-lambdas/). While what follows will be related to more fundamental concepts I feel this is as good a place as any to plug that in.

Blocks in general were initially confusing to me, while now obviously a do-end closure then they were a driving force of many a frustrated sigh. There isn’t really a great revelation to be shared here when it comes to blocks themselves, they are, once you give them an honest chance and use them a bunch a great tool. Especially when it comes to working with an enumerable in place. 

The lesson here was a more elaborate kind, it was starting to show that frustration was getting in the way of solutions. This particular experience. Struggling with learning how to work with maps, selects, filters and reduces has taught me another key lesson. It’s important to take a step back and re-assess. In the heat of the moment, it’s easy ( For me! Although I’d not claim to speak for anyone else) to get lost in the problem and wallow in frustration, sighs and angry hand shaking. Taking a breath, or even a break often helps solve the most frustrating conundrums. 

Last large issue I’ve faced that jumps out at me looking at notes and reminiscing, was visualising how my code worked when there were multiple conditionals layered with loops and rescues sprinkled within. The “proper” term for such layering of conditionals is Cyclomatic Complexity, and struggling with algorithm questions where said complexity was getting “a bit much” has taught me one thing, while my mentor came in and helped me with other.

My finding was, that sometimes it’s easier to write things down. First iterations don’t always read like English, so going through code step by step and physically “processing” inputs has helped me where trying to swap bits and pieces of code didn’t. It also helped me take a breath, a step back, I’d say we’re seeing bit of a pattern forming here. When the work is conceptual and concepts become difficult nothing helps like a breath ( except maybe stack overflow ).

Second lesson was to separate out complexities. This more technical approach was provided by my Mentor. Break complex conditional chains into smaller, immediately understandable methods. It’s a good lesson that kept on re-appearing. It helps you understand your code, it makes it easier to read, debug and refactor. It’s a win, win, win, win kind of situations and how many of those do you see in the wild.

There were multiple of those lessons, about thinking processes, about myself and about the world arounds us that I’ve only discovered thanks to having decided a year ago that I wanted to learn. Even if I was never to have written a line of commercial code, the time spent will have been worth it.

A year ago, I was positively elated I can edit a local version of a website through my browsers dev tools. 

This is difficult to write, but important I feel. Today, a year later. I’m comfortable in a programming language, learning and using another and feeling more confident than ever in working with technical documentations or approaching any new opportunities and tasks in personal and professional projects because of the fundamental change in mindset that came along with hundreds of hours spent learning through iterating, and often failing in code. 

There is really one main takeaway I’d like to share and it’s more “self-help(ish)” than technical. 

I don’t think you’re “too old”, “not smart enough”, “bad at maths” or any other number of negative self biases you might have preventing you from trying to code. 

I started as I was exploring something based on curiosity. It’s through that curiosity that the blog you’re reading this on has been created. It’s this curiosity, the satisfaction and genuine joy that coding can bring that kept me coming back. It doesn’t mean I think everyone should aim to be a professional, but then again, do you have to aim at olympics to pick up a sport?

Writing code, helped me remember I love writing in general and has made me better, in general too. To me coding was and remains joy. I love it, and think its worth it for you to give it a shot!

I urge any and all of you to find your coding even if for you, it isn’t coding at all.

I’ll speak of the technical journey and resources a bit more in a post that will follow this. What resources, pages, articles and websites I’ve used and can in my limited capacity recommend. In the meanwhile, see you around and as always, thanks for the fish.