---
title: "The humbling experience of learning a new language"
image: "writing/social/bitwise-operator.jpg"
description: "The fuzzy head, the frustration and then the joy as it all starts to click. Some of my thoughts as I started to learn Ruby on Rails."
date: "2021-05-11"
published: true
category: "Learning"
---

A few weeks ago I started a new job as a Senior Developer at Shopify. Shopify are known for a few things: they help merchants across the globe sell their products at a [massive scale](https://twitter.com/Shopify/status/1387030179646685195) and they do it all on [Rails](https://rubyonrails.org/).

Shopify have a really interesting approach to hiring, they don't necessarily look at what languages you know they instead look at your ability to learn and trust that you'll put in the effort to learn their stack. Hint, I had never used Ruby on Rails before I joined.

After two weeks of onboarding I began the process of furiously cramming as much Ruby based information as I could get into my head, thankfully it seems as though a bunch of it has stuck around for now. I've taken a mixed approach, I've been watching the seemingly endless catalogue of content at [gorails.com](http://gorails.com/), taking a (brilliant) internal bootcamp course and reading [Web Development with Rails 6](https://pragprog.com/titles/rails6/agile-web-development-with-rails-6/) pretty much cover-to-cover (if you're learning Rails then buy this book, it's helped me a tonne).

Over the past few days I've realised a few things about learning a new programming language. First, Ruby on Rails is an incredible framework, it's really intuitive and has a tonne baked in, I'm genuinly blown away. Second, learning something new is tough, incredibly tough. It's been taxing and I've been really tired but at the same time exciting about leveraging this new language and framework that I'm learning. Lastly, there's a lot of crossover between languages and the concepts they use and I shouldn't have been as initimidated by learning something completely new as I was. The last one is interesting to me, I'm happy to learn about new databases, new AWS services and so on but something about learning a new language is straight up terrifying and it really shouldn't be.

After spending years just working in JavaScript/TypeScript and honing my craft there it feels strange and out of place being a beginner again but it's also exciting and has sparked a want to learn more which is something that's been missing for the best part of a year.



The fuzzy head, the frustration and then the joy as it all starts to click. Some of my thoughts as I started to learn Ruby on Rails.

The humbling experience of learning a new language

Lessons I've learn whilst managing development teams

---
title: "On decision making"
image: "writing/social/on-decision-making.jpg"
description: "Making a good decision might not lead to a good result, and that's perfectly fine."
date: "12/12/2020"
published: true
category: "Management"
---

In my day job, I'm what's called an "Engineering Manager" or an "Engineering Team Lead", that means that I lead teams of software engineers to help them build better products, write better code, build their careers and make better decisions. Because of my role, I have the privilege to make a number of decisions every day. They range from what features we'll work on, how we'll approach the work, whether code is introduced into our applications, what technology to use and so on.

Something that I continue to realise whilst working in this role is that decision making is hard, it's much easier to sit on the fence and not do anything. In fact, I think the latter is more akin to my nature. I remember when learning to drive my driving instructor said to me that it was like every decision I had to make about a specific manoeuvre or turn was being decided by a committee - "just decide!". However, I've got better at this. One of the ways I've improved is by focusing on the current context that the decision is being made in and then disassociating the result with the decision, as Seth Godin says:

> A good decision can lead to a bad result

And that is perfectly fine.

The decision that you make may well be correct for the circumstances you're in but later on, might not lead to the result that you really wanted - a good result. I can think of several decisions that I've made - especially technical ones for applications I work in - that fit this perfectly.

Recently I've been wrestling with myself on a specific technical decision - whether we should continue using a particular technology or not at work. For each pro there was a con - I was on the fence. Concerned whether the use of the technology would yield the result that we wanted in ~12 months, I was focusing on the wrong thing. I had to decide whether this was the right decision in the context we're in now. In my case, I asked myself a few more questions:

- does this technology add value to our customers right now?
- does this technology speed up or slow down our teams right now?
- if we weren't to use it, what else could we focus on? Where else could we provide value?

In the end, after toiling away, coming up with my decision and then a quick discussion with my peers we've opted to not use that technology. It's definitely the right decision, but we'll soon see if it gives us a good result.

Decision making is hard, but we can make making those decisions more comfortable by:

- taking a step back and looking at the context we're in to help understand whether this is the right decision
- looking beyond just you or your team even if it's a technical decision - is this decision right for our customers as well?
- remembering that a good decision can yield a bad result and that's fine


Making a good decision might not lead to a good result, and that's perfectly fine.

On decision making

---
title: "On shipping"
image: "writing/social/on-shipping.jpg"
description: "What makes the difference between a good and a great team?"
date: "2020-09-06"
published: true
category: "Management"
---

An ex-colleague of mine - a product owner in our team - said something that’s stuck in my head. A simple phrase that has dictated my approach to projects and product development ever since. All he said was:

> Great teams ship

3 words. That’s it. Great teams ship.

We were having a conversation at the time on what we could improve in our product development processes and the steps we had to take to improve the quality of the applications we were building - we were also discussing a slump we were in with one of our internal projects. Our team at Equals was doing really well, we were a good team but in order to become great we had to ship more.

Our quality was increasing drastically, we were investing heavily in building great components and interfaces, we were covering a lot of ground across multiple applications in multiple products, however, we had to ship more.

You could have the most highly tuned onboarding flow and that’s good, but if its not in your customer’s hands then it’s not that great. You could have the most beautifully optimised sorting function for displaying thousands of items of data at once but if its not in your customer’s then it's not that great. You could have brilliantly refined components but if your customer isn’t interacting with them yet then that’s not that great. You get the point.

## Going from good to great

This was tricky, there was only a few things we had to change but the things we had to change were deep down. It’s technical, it’s cultural and it requires investment. There’s no one-size fits all but here’s how we did it.

1. Set an expectation that we will always deploy no matter what. If your core feature has to be behind a feature flag then that’s cool, deploy anyway to get some of the minor bug fixes live. This helps sets the habit. Pick a day, maybe a Wednesday or Thursday and stick with it.
2. Invest in a pipeline that’s fast, but more importantly consistent. If you’re going to ship frequently (at least once per week, ideally more) then you need to trust your pipeline.
3. Empower everyone in your team to handle releases.
4. Make sure everyone understands the customer benefit behind every single feature. Great product developers care about their customers, show them why their work matters.

The main one you need to focus on is point one, it's also the one you need to keep an eye on and keep in check. If you want to be great team you need to get features into your customers hands, you need to be able to react quickly to market and customer behaviour, you need to know that what you're building is impacting real people. There's only one way to do that - to ship it.

Great teams ship.


What makes the difference between a good and a great team?

On shipping

Occasionally I write about interesting or helpful coding methods or ideas that I've been learning about

---
title: "Bitwise Operators"
image: "writing/social/bitwise-operator.jpg"
description: "What's a bitwise operator and when do I need them?"
date: "2020-12-11"
published: true
category: "Technical"
---

I recently needed to determine if the index when looping through an array was odd. I've had to do this a million times and everytime I have to look it up so I'm finally documenting it.

There are a number of ways to do this but one of the shortest ways is to make use of AND bitwise operator (`&`). For example:

```ts
const array = ["this", "is", "an", "example"];

array.forEach((arr, index) => {
  const isOdd = (index + 1) & 1;

  if (isOdd) {
    // ...
  }
  // ...
});
```

## How does this work?

MDN says this about the AND bitwise operator:

> The bitwise AND operator (&) returns a 1 in each bit position for which the corresponding bits of both operands are 1s.

So, it turns the number into binary (zeros and ones) and checks if the first bits are both `1`, if they are then this returns truthy (`1` or `0`).

For example:

```ts
const one = 1; // 1 in binary
const two = 2; // 10 in binary
const three = 3; // 11 in binary

const isOdd = (number) => {
  return number & 1;
};

console.log(isOdd(1)); // returns 1 as 1 === 1 (1 in binary is 1)
console.log(isOdd(2)); // returns 0 as 0 !== 1 (2 in binary is 10)
console.log(isOdd(3)); // returns 1 as 1 === 1 (3 in binary is 11)
```

Odd numbers will always start with a one, whereas even numbers will always start with a zero which is why this works.

The AND bitwise operator isn't the only one, there is also [OR and XOR](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators#Binary_bitwise_operators). Let's take a look at the XOR operator

## XOR Operator (^)

It took me a while to understand what the XOR operator does, so before I try to explain it lets look at some examples.

```ts
console.log(1 ^ 1); // 0
console.log(1 ^ 2); // 3
console.log(2 ^ 2); // 0
console.log(2 ^ 3); // 1
console.log(3 ^ 3); // 0
console.log(3 ^ 4); // 7
```

Let's look at how `1^1` returns 0.

`1` in binary is `01` so we are comparing `01` and `01`. The XOR operator takes the two binary numbers and it returns a new binary number where the first binary number has a `1` and the second doesn't. In the case of `01` and `01` they both match so we return `0`.

Let's look at `1 ^ 2`.

The number one as we know is `01` in binary and the number two is `10` so the operator returns `11` which equals three. We got `11` back from the operator as the first bit of `01` is `0`, whereas, the first bit of `10` is a `1` (and the same for the second bit).

Here's a table of some numbers converted to binary so that you can do your own calculations for the others

| Number | Binary |
| ------ | ------ |
| 1      | 01     |
| 2      | 10     |
| 3      | 11     |
| 4      | 100    |
| 5      | 101    |
| 6      | 110    |
| 7      | 111    |
| 8      | 1000   |
| 9      | 1001   |
| 10     | 1010   |

### How can this be applied?

Say you have an array of numbers and each number has a pair, except there's a problem. It turns out one of the numbers doesn't have a pair and we need to find it so we can add it. The XOR operator is perfect for this.

```ts
const pairs = [1, 1, 2, 2, 3, 4, 4]; // 3 doesn't have a pair

const singleNumber = (nums) => {
  let num = 0;
  for (let n of nums) {
    num ^= n;
  }

  return num;
};
```

Let's step through what this is doing line by line by adding a console.log and viewing the output.

```ts
const singleNumber = (nums) => {
  let num = 0;
  for (let n of nums) {
    num ^= n;
    console.log(`for ${n}, num equals ${num}`);
  }

  return num;
};

// => for 1, num equals 1
// => for 1, num equals 0
// => for 2, num equals 2
// => for 2, num equals 0
// => for 3, num equals 3
// => for 4, num equals 7
// => for 4, num equals 3
```

We can see that when a `num` === `n` then `num` is set to zero as the bits all line up. In the case of three however, it doesn't have a pair so it's never set to zero. When the time comes to add the bits equaling four we end up adding three and four together, in the last step we subtract that four which then returns three.


What's a bitwise operator and when do I need them?

Bitwise Operators

---
title: "Welcoming the challenge of Open Learning"
image: "writing/social/open-learning.jpg"
description: "Making time to develop and grow in the open"
date: "2020-11-29"
published: true
category: "Technical"
---

I was having a conversation with my girlfriend - who is also an engineer - a while back on the struggles of keeping up with technology. Arguably, it's the hardest part of our job. Rarely do you get the chance to experiment freely during work hours so unfortunately it can be left up to individuals to do in their own time. I don't agree with this as it really restricts those who have obligations such as children and families, however, that's the situation we're in.

I'll be honest with you internet - my learning hasn't just slowed over recent months, it's completely halted. It turns out when you mix a global pandemic, being stuck in doors all the time whilst having to build business critical and time senstive products it can be incredibly draining on you mentally. Thankfully, work is easing up, we're heading into christmas and all of a sudden my desire to improve, broaded and deepen not just my programming knowledge but general knowlegde has increased. So here I am writing a blog post about how I want to start learning in the open. Mostly so that I have a public commitment to myself.

So, what do I want to learn in public?

It turns out a whole lot, from different languages to best practices.

**Programming languages:**

- Rust
- Reason
- Python
- Scala

**Databases:**

- Deepen my knowledge of SQL
- Deepen my knowlegde of DynamoDB

**Infrastructure:**

- AWS CDK

**Product:**

- I want to spend a bunch of time learning about engaging with customers so that I can better understand their needs
- How to measure the success of a particular feature or product

**General**

- **Computer Science** - I regard myself as a pretty good developer. I've built production mobile apps, web apps and backends, and I've got my dream job as an Engineering Lead, however, I don't have a CS degree and I genuinly feel that this holds me back from achieving what I want to achieve. So, I'm going to work out how to gain a good, robust CS and maths knowlegde without going to uni. Looking at you **freecodecamp**.
- **Functional programming with JS**. Why not?
- Continue to deepen my knowledge in all things GraphQL. I've been working with GraphQL for a few years now, however, my skills and knowledge are stagnating.
- Spend more time watching conference talks on YouTube.

As well as dedicated and intentional practice I'm going to force myself to start reading more articles to help broaden my knowlegde.

### What's the first step?

Well to get started I've signed up to egghead again (on a monthly sub just now) and that's been great, the short informational videos are ideal to my learning style and are helping me build up a habbit. Next up I'm going to just work on areas of my coding abilities that I don't normally work on and we'll go from there.

Wish me luck Internet.


Making time to develop and grow in the open