Sami Birnbaum

AI-led or Human-led Coding? We have to choose.

Thu, 24 Apr 2025 00:00:00 +0000

It is time we take a closer look about how we code with AI and the ramifications on our industry.

I should never have clicked the button

Something really challenging happened to me at the back end of last week. In retrospect it probably wasn’t surprising, but it was challenging nonetheless.

I had been working on a feature to add some permissions to a codebase, a relatively trivial feature. It was a codebase that I only started working on a couple of weeks ago so I took the time to understand the problem and get familiar with some of the architecture.

Within 3 hours I had a PR up and was confident in my changes.

As I went to close the corresponding GitHub issue I saw a button that I had not seen before on the GitHub UI: “Code with Copilot Agent Mode”.

I should never have clicked it! I had completed the feature anyway and was only on GitHub to close the issue, but my curiosity got the better of me…

And so I clicked the button. Little did I know that this would lead to a weekend of ruminations, questions of self-worth and angst.

Instantly, GitHub opened a new tab in the browser to an online instance of Vistual Studio Code for the given codebase. But it didn’t stop there. The editor then gave birth to a right-sided panel with Github Copilot in Agent Mode.

I watched aghast as the GitHub issue description was injected into the right-sided panel prompt and the Copilot Agent proceeded to get to work creating files, editing files and running terminal commands to add the same feature that had taken me hours, in minutes.

Queue existential crisis and a long weekend of ruminating about how life would never be the same.

I should add one caveat here that technically speaking the Copilot Agent did not complete the task, it did get close but it required me making some changes and prompting it a few times here or there.

However, I could not shake the question, should I be using a Coding Agent going forward? I know it would take some time getting used to but maybe with enough context and prompt engineering this is the new way to code!

I ruminated on this for far too long over the weekend, but I decided to collate my thoughts so hopefully it prevents someone else having to ruminate in the future.

AI is not going away

My initial reaction was to try and negate AI entirely. My mind considered AI to be a threat and so it felt reassuring to try and remove AI entirely from the picture.

I did this by conjuring up thought processes about AI just being some sort of hype or even better the world simply running out of energy to support AI infrastructure allowing the way we code to return to what it once was.

Whilst this felt reassuring, the sense of calm was short-lived because this did not seem realistic or likely.

I therefore had to come terms with AI being a part of how we code. The horse has bolted and cannot be returned to the stable.

So what are my options?

Human-led coding with AI support

This acceptance allowed me to reframe my concerns.

I probably will be using AI when I code, but perhaps there are different ways or methodologies of coding with AI.

I thought about how I currently use AI when I code, before I clicked that dreaded Copilot Agent button.

I tend to take time to understand a problem so I can consider an appropriate solution whilst taking into account the bigger picture and overall code architecture. We can call this the planing phase.

I then utilise TDD and outside-in testing to consider the best place to write my first test that will help me drive towards the most efficient solution. We can call this the implementation phase.

In either of these phases I may reach out to an LLM to ask a question about a concept I do not understand or to help me with some syntax, but it is I who chooses to reach out when I feel the LLM will best benefit me.

I like to think of this as Human-led coding with AI support.

AI-led coding with Human support

The other, recently discovered, way of coding with AI using the Copilot Agent looks rather different. It tends to start with an AI prompt and the AI sits in the driving seat going through the planning and implementation phase simultaneously.

Your role is to check over the AI’s work and make corrections here or there.

A helpful way to think of this is AI-led coding with Human support.

Being able to verbalise and conceptualise these 2 different ways of coding was really helpful. I could now see two approaches to coding with AI.

Human-led or AI-led.

But which one will you choose?

It is important to acknowledge that both options are valid.

Both can be used and will be used by different people. They are both options available to software developers, and like any choice about tools and implementations both have their advantages and disadvantages.

However, on a very practical level, one needs to make a decision about which one to use. This was my next conundrum to grapple with:

Should I be a Human-led or AI-led developer?

Do I have to choose?

But before I answer that question I think it is worth considering why you need to make a choice. Why do we have to be the ones to make a choice about how we code?! Surely we can just ride the wave and see where things go?!

The answer to this question hinges on the assumption that AI companies have our best interests in mind.

They don’t.

Let me use a social media example for a moment.

Whilst social media does a lot of good, the companies behind many of these platforms are primarily interested in money and this often correlates with screen time. They are not producing these applications for the betterment of society but rather to increase screen time of their users.

Social media is neither inherently bad or good. However, the onus is on us as individuals to decide how we incorporate social media into our lives. If you use social media without clear boundaries or choices you will probably find yourself using it in unhelpful or unhealthy ways.

The same, I believe, is true for coding with AI.

AI is encroaching more and more into our craft and the way we work. It will continue to do so, for the same reason social media continues to do so, money. It will not be done with deep thought for the betterment of software, our craft, or the craftspeople.

Therefore, making a decision about how to use AI becomes a choice you have to make, boundaries you have to consider, it cannot be something that is left to prolificate unattended.

Should I be Human-led or AI-led?

It is a difficult question to answer because I can only do so based on the knowledge I have in front of me now in an ever changing landscape. It is also difficult because very often in coding the answer is “it depends”.

Whilst these are both true I think it is helpful to establish a general rule, notwithstanding the exceptions.

I believe we can do this by looking at key values within software development.

Speed 🏎️

I think about what life would look like as an AI-led developer. Immediatley, I think about completing features far quicker, the speed with which code could be written and features could be shipped.

But I wonder if, in this case, looks can be deceiving.

Because AI code requires checking, a craftsperson who cares about their work and the impact on the wider codebase as a whole will not be able to avoid having to understand the problem properly and the ramifications of the solution.

I don’t think you can avoid that “planning phase”. All you can do is delay it until later.

Arguably, it is harder to understand a problem or a solution after it has been written (think code reviews and understanding old code).

However, AI-led development lends itself to this.

Human-led development is arguably less cognitively intense as it allows the planning phase to happen sequentially and not retroactively.

And be careful not to misunderstand me here, Human-led development still involves the use of AI. I am not arguing to down AI tools. However, Human-led development allows you to utilise the speed of AI for smaller tasks along the way which shouldn’t require intense checking.

Knowledge 🧠

I don’t have a metric for this but I believe my assumption is reasonable.

Imagine an AI-led developer who spends most of their time doing code reviews and making tweaks. They are working with a preconceived notion of how to solve a problem and are evaluating that specific problem. They are utilising different parts of their brain in comparison to the Human-led developer.

The Human-led developer has to start the process with creativity and critical thinking. They may have 5 different options of how to build a feature in front of them. Some of those may involve different technologies and perhaps architectural changes.

In order to make an informed decision they will have to have a broad enough knowledge-base to weigh up the best approach.

This sort of creative and broad thinking, I believe, forces a developer to have a better understanding and deeper knowledge of the whole software ecosystem.

AI-led development does not lend itself to this as it proposes a solution which will naturally create a bias towards pursuing that solution.

In smaller features this may not have an impact but overtime I believe there will be a vast knowledge gap between AI-led and Human-led developers that will be fairly self-evident and when it comes to working on bigger, more diverse software projects. You will want that broad-knowledge and versatility which AI-led development does not foster.

As I said, it is a hard metric to quantify but I think over the next couple of years we will see the impact of this within the software developer community.

Prompt Quality ✍️

The knowledge factor also plays a big role in the quality of your AI prompts.

You may have heard people say that an LLM is only as good as the dataset it was trained on. Whilst this is true, there is another truism that should not be ignored.

The output of an LLM depends on the quality of the prompt.

Consider the following 2 prompts for a performance issue:

“I have a query that is slow, how can I make it faster?”

“I have a query that I believe is slow. I am not sure if the slow performance is happening in application memory or at the database level with the SQL query. Here are the results of the EXPLAIN ANALYZE query I ran. I would like to first be able to benchmark the query at the application and database level so I can determine where the transaction is the most expensive and also so I can measure any improvements. I am also wondering if there are some other options available within Postgres, perhaps creating a View, because the table I am querying has lots of records, what do you think?”

As you can see, there is a major difference between the 2 prompts. The former is not a bad prompt and will likely yield some results, but the focus is more narrow on the database component.

However, the latter utilises a broad knowledge base to include the application speed and also opens up the LLM to using a different approach.

This is another reason why knowledge is important and my theory is that Human-led developers will write better prompts because they have maintained a broader understanding and critical thinking habits.

Scale 🏗️

But lets say you really love doing code reviews and reading through legacy code and you enjoy the path of least resistance, so you are willing to forgo the knowledge gains.

I still feel that at some point you will run into limitations with AI-led development.

Anecdotally, I have played with AI-led development on a personal side project and what I found is that the complexity of the code increased as the codebase got bigger and more features were added.

As a consequence, the LLM started to provide less accurate results and solutions that did not work. This led to even more complex code and a codebase that was very difficult to work with.

From my experience, this forces you, at some point, to return to Human-led development.

Code Quality 🧑‍💻

I have often considered why this is and I think it comes down to the biggest challenge of writing software.

The biggest challenge is not writing code, it’s writing code that is resilient to change.

Just ask Sandi Metz who has written books dedicated to this topic.

At some point the requirements will change and therefore the code that you (or someone else) has written will be required to change.

The biggest cost will be your ability to make that change.

Have you ever heard someone say we need to rewrite this software all over again?!

The reason rebuilds are required is because the cost of change outweighs the cost of a rebuild.

That means your codebase is so complex and convoluted that it is struggling or unable to adapt to requirement changes.

This is a bad place to be.

Kent Beck and Martin Fowler touch on this in their book Planning Extreme Programming (XP Series), where they talk about the different levers you can pull to increase your development speed:

The other lever is internal quality. This reflects the quality of the internals of the system: how well it is designed, how good the internal tests are, and so on. This is a very dangerous lever to play with if you allow internal quality to drop you’ll get a small immediate increase in speed, rapidly followed by a much bigger decrease in speed. As a result you must keep an eagle eye on this lever and make sure it is always up as far as it can go. Nothing kills speed more effectively than poor internal quality.

And I believe that AI-led development puts code quality at risk.

There are three main reasons why I think this is:

1. Narrow vision

In my experience LLMs tend to focus on fixing the issue at hand based on the prompt provided. This naturally lends itself to a narrower vision.

In contrast a human can take into account the bigger picture, the codebase as a whole, wider business requirements as well as intuition about what the future holds.

2. Refactoring

One of the most important things you can do as a developer is refactor as you develop new features. This was captured by Kent Beck when he said:

First make the change easy, then make the easy change.

Humans are good at this, we start to build a new feature and notice a code smell or some code that doesn’t seem to be a part of a given object and would be better placed elsewhere.

These small incremental refactors are what keeps the whole codebase ticking along and resilient to change. It is the versatile midfielder in the middle of the pitch keeping the rest of the team in good shape so they are ready for the next phase of play.

In my experience LLMs are not good at spotting these changes and making them unless actively prompted to do so with some good old Human-led development.

3. Technical Debt

Have you ever thought about what the biggest contributor to technical debt is?

In my experience it is speed.

There seems to be a correlation between moving quickly and accruing technical debt.

Unfortunately, AI-led development lends itself to coding faster but speed is not always the best thing because it comes with consequences and one of those consequences is technical debt.

Slowly does it 🐢

There is another more subtle consequence of everything happening very quickly.

Have you ever noticed what happens when you are working on a feature but not writing code. The pauses in between, perhaps when you run your specs or just stare at the trees in the wind.

Pauses or moving slowly allow space for thought.

These moments are sometimes the most important as they are the moments when your brain is allowed to wonder and you think about a new edge case that no one else has thought of, or a better architecture that unblocks future development.

Numerous times whilst working on a feature I find myself creating cards for tangential improvements that have risen to the surface along the way.

Moving slowly comes with this benefit, time allows the brain to absorb information and for thoughts to rise to the surface.

Human-led development allows for these moments.

Enjoyment 😄

This sounds obvious. It is important for us to enjoy what we do.

Perhaps AI-led development is more enjoyable for you but I’ve always enjoyed the craft.

For me the enjoyment is sometimes less about the destination and more about the journey.

I like being in the weeds of the code, going deep into a bug and the root cause. I find the process engaging and stimulating.

But it goes deeper then just having a good time.

Humans need joy to be productive. We think and perform at our best when we are happy. The inverse is true for demotivated people.

If AI-led development is not enjoyable for you then human nature is to be less creative and struggle to maintain high levels of care and attention because you are not enjoying your modus operandi.

If AI-led development makes you feel this way then you should feel empowered to choose Human-led development for its enjoyment and the way that contributes to yours and your teams productivity as a whole.

So what’s it gonna be?

As I said before both AI-led and Human-led development are valid options and there are tradeoffs between the two.

But I believe that we have to choose.

At this stage in history we don’t have quantitative metrics that tell us which way to choose, I believe it will take a few years for those to arrive. However, we can use our experience.

We have to carve out a way that works for us, and in order to do this we must create boundaries and make a choice about how we want to incorporate AI into our lives and into our industry, because the AI companies will pursue their own agendas which may be different to ours.

We care about what it takes to build great software of the highest quality which can stand the test of time.

I take pride in Human-led development.

Stubbles - Stubbing and Doubles innit. 🧔

Thu, 02 Mar 2023 00:00:00 +0000

Confession: I’ve always struggled to understand the difference between stubbing and doubles…

As you start to get more familiar with automated testing, at some point you will likely hear other developers say things like:

“You know you can just stub that method, right?!”

“This is a great candidate for a double!”

And at the beginning these things can be confusing to understand. 😕

So let’s start by defining each term, followed by their practical use, in specific relation to rspec within a rails project.

Definitions 📖

One of the tricky things I have seen when these concepts are defined is that they are often defined within the context of testing.

For me, that just adds a layer of complexity.

It is true that these concepts are often used within the context of testing, but they don’t have to be.

So let’s take a stab or should I say stub 😆 at defining them without talking about tests.

Stubbing 🔪

Stubbing is just a term for defining a method on an object.

However, it indicates the short-term nature of that method.

If you stub a method on an object, your intention is that it exists for a short period of time and most likey returns a simple hard-coded value.

You may use a stub to define a method that does not exist yet on an object or to override an existing method to get it to return a value you desire.

Doubles 🎲

A double, is simply an object that is a double of another object.

You may be thinking, “but why would you do that?!”, but lets put that question to one side for now just so we can understand the concept in its purest form.

A double of something is just a copy of that thing.

If I have one chocolate and I double that chocolate I now have two of the same chocolate. We can call the first chocolate the original and the second chocolate a double of the original. yum. 🍫

Great Success!! We made it this far and we haven’t talked about tests!

Testing 🧪

Hopefully now that we understand these concepts independent of testing we can talk a little bit about how they can be helpful tools to use when testing.

Stubbing 🔪

Sometimes when you are testing a method, the method under test will send a message to another object in order to retrieve some value.

That sounds confusing but look at this example:

class EasyMath
  def sum(a,b)
    if SumFeature.available?
      a + b
    end
  end
end

The available? message is being sent to another class SumFeature in order to return the value true or false.

When we come to test the behaviour of the sum method, it would be really useful if we could just worry about a + b without having to be concerned with what the available? method does. At the end of the day, the available? method belongs to the SumFeature class and has nothing to do with us over here and we can assume it is tested in the SumFeature class where it is defined.

Well thankfully we have a tool in out arsenal called stubbing that will allow us to stub the available? method so it always returns true. This is great! We can now focus on testing a + b whilst relying on available? to always return true.

Ok, but what does this look like in a test?

describe "#sum" do
  it "adds two numbers together and returns the total" do
    easy_math = EasyMath.new
    allow(SumFeature).to receive(:available?).and_return(true)
    
    total = easy_math.sum(2,2)
  
    expect(total).to eq(4)
  end
end

See that line allow(SumFeature).to receive(:available?).and_return(true)?

The available? method has now been stubbed out to always return true.

No matter how many times you call SumFeature.available? in your application code, it will always return true.

We did a thing! We stubbed a method! And as you can see it had nothing to do with doubles! 💥

Doubles 🎲

Ok if you have made it this far, then stay with me as we are nearly there..

Let’s take the same example we used above with the sum method, but tweak it slightly, to see how we could use a double.

class EasyMath
  def sum(a,b,user)
    if user.likes_math?
      a + b
    end
  end
end

Once again we are sending a message likes_math? somewhere else in order to retrieve a value of true or false.

Similarly we only want to concern ourselves with the behaviour of a + b without having to worry about likes_math?.

Given what we know so far, we might suggest stubbing the likes_math? method in the same way we stubbed available?.

allow(user).to receive(:likes_math?).and_return(true)

However, whilst a class method like available? can be stubbed without the need for a double, an instance method does require a double before it can be stubbed. (There are exceptions to this by using any_instance_of but it is not recommended.

In other words we first need to create a double of the user object before we can stub the likes_math? method on it, to always return true for us.

Now hold on one second!! Why am I talking about stubbing alongside doubles? Didn’t I kind of say I didn’t want to do that?!

Ok hear me out on this one…

Whilst stubbing and doubles are completely separate concepts, a double is only meaningful and useful once you stub methods on it.

This is because when you create a double you are creating a double of that object without any methods on it.

The double is just a plain Ruby Object.

Therefore, in reality, although stubbing is used on its own, when you are using a double you will likely need to use stubbing as well.

Ok so lets see how the code would look for testing our sum method:

describe "#sum" do
  it "adds two numbers together and returns the total" do
    easy_math = EasyMath.new
    user_double = double
    allow(user_double).to receive(:likes_math?).and_return(true)
    
    total = easy_math.sum(2,2,user_double)
  
    expect(total).to eq(4)
  end
end

See how we first create a double like this user_double = double.

And on the next line we stub the likes_math? method on to our double like this: allow(user_double).to receive(:likes_math?).and_return(true).

It might be helpful to think about it this way:

A double is a useful tool to help you to be able to easily stub.

And that’s really all there is to it folks!

But before I go, let’s wrap up with some helpful tips.

Take-Away Tips 🪶

Stubbing 🔪

Stubbing has nothing to do with doubles.
It helps us to force the return value of a method we don’t care about in our test because it is tested elsewhere.
A class method can be stubbed without the need for a double.
An instance method will need a double (unless you use any_instance_of).

Doubles 🎲

Doubles are a useful way to create an object that acts as a double of another object.
The most basic way to create a double in rspec is to use the double method.
Another option is to use instance_double(User). This is the same as double but will verify that any methods you stub exist on the class you are doubling.
If you are using FactoryBot you can use build_stubbed(:user) which will create an instance_double but with the methods stubbed out as set in the factory. It also has the added advantage of stubbing out associated objects and created timestamps.

🧔

Tips for joining an existing project 💡

Fri, 15 Jul 2022 00:00:00 +0000

I don’t like change!…

Joining an existing project is daunting at the best of times. There are a lot of things to try and wrap your head around and it takes a lot of mental and emotional energy. Most human beings by nature do not like change (I’m one of them 🙂), it is uncertain and requires expending more effort than staying put does.

However, change is inevitable and positive. A new project brings new experiences and sometimes a change of scenery can bring some freshness to your daily routine.

So here are some tips that I have picked up along the way to try and help ease the transition onto an existing project.

Lower your expectations and go exploring 🔎

This might sound counterintuitive but coming into a project at 100mph with expectations to have an immediate impact are probably not realistic and will likely lead to you feeling frustrated.

I understand the desire to do this and it comes from a good place of caring about what you do and wanting to help.

You may also feel like “I am being paid to be here so I need to be doing things”.

However, these expectations and pressures are often self-imposed. Ask yourself, where are these expectations and pressures coming from?

Often the answer is from your own desire to get things done or have an impact.

Instead, give yourself a buffer when joining a new project. You could call it the exploration phase, the discovery phase or the onboarding phase.

It doesn’t matter what you call it, what matters is that mentally you give yourself time to get up to speed without pressures or expectations to deliver.

Depending on the size and complexity of the project this could be weeks or even a couple months or even longer.

⭐ Pro Tip: communicate this with the rest of the team, let them know you will be in an exploratory phase where you get up to speed with all the things there are to learn about the new project.

Remember everyone who joins the project will have to do this anyway, it just helps to set some healthier expectations for yourself and the team around you.

Be sensitive 💙

When you join a new project it can be fairly common to immediately see something that the new team has done or are doing that you feel doesn’t seem right or could benefit from some significant improvement.

The likelihood is that you are correct. Your observations with a new perspective may have spotted something which the rest of the team have been doing habitually without thinking about it and you can see a clear and obvious approach to improve this for everyone.

But before you jump in and start suggesting changes, just take a moment to be sensitive.

Every project and process has its idiosyncrasies and some have a context behind them that explains how they ended up this way.

Moreover, some people may have spent a lot of time honing these processes or code structures, so be sensitive to the possibility that critiquing something might also be viewed as critiquing someone.

⭐ Pro Tip: Consider holding off suggestions until the discovery phase has passed. This gives you the time to gain some more context on how certain things developed but it also means that when you come to make a suggestion you will be respected by the rest of the team for having taken the time to understand things first.

Onboarding Checklist ✅

This is it! Your first day on the project and you arrive at the daily sync (on time, because it is your first day).

There is tendency to feel a bit out of things when everyone is going through their cards or tasks for the day and everyone seems to have a clear idea of what they are doing.

You also want to feel part of it and want to have something concrete to say in the sync.

A quick way to be able to do this is to create a task for onboarding and add an onboarding checklist to it. The team you are joining may already have an onboarding checklist for onboarding new people anyway, but why not create a card for it and add some of your own things that you like to do for onboarding as well (dare I say, you may even add some things from this list 😉).

⭐ Pro Tip: Having an onboarding checklist that is visible will give you something to communicate about in sync but also give good visibility to the rest of the team about what you are doing.

Business Overview 💰

Sometimes we forget that behind the codebase there is often a business.

In fact sometimes the hardest thing about joining a new project is getting up to speed with all the domain knowledge.

Consider asking someone from the business side of things (preferably not another developer) if you can schedule a call just to have a chat about how the business works.

This will not only give you invaluable information about what you are working with but you will also discover what are the best channels for communication to get hold of stakeholders.

Technical Architecture Overview 🎛

So far we still have not looked at anything technological, but let’s do that, without heading into the codebase just yet.

Ask one of the developers or someone from the DevOps team (if there is one) for a chat to go through the technical architecture.

Often you will find that understanding the technical architecture can help to answer a lot of questions that you would encounter in the codebase anyway.

For example:

How many databases are there?
What type of database are we using?
How many front-end clients interact with our server?
Is this a monolith or micro-services?
Is there an API?
Do we integrate with 3rd party API’s?
What technologies are we using?
How many environments are there besides production?
Which branch deploys to which environment?

You will be surprised how many things you will discover about a project by gaining an understanding of the overall architecture and at some point you will likely run into issues with deployments or certain bugs that require knowledge of this anyway.

⭐ Pro Tip: Create your own diagram of the architecture. It will come in handy later when you forget things. You could also add it to the documentation to help future developers onboard.

UI Walkthrough 🖥

This may seem more obvious, but why not book in a chat with someone from QA or a developer to walk through the UI.

Often it will be too vast to walkthrough all of it, so I find it helpful to ask to walkthrough the part of the UI that you will likely interact with most in your work. Go through some happy paths just to get a brief overview and you will pick the rest up as and when you encounter those areas.

⭐ Pro Tip: If the project does not have a UI, ask for a walkthrough of the API docs or even better a walkthrough on Postman where you can see those API requests in action.

Codebase Walkthrough 👨‍💻

I have actually rarely seen this done, but a senior developer on a project I joined recently did this with me and I found it really helpful.

The idea is not to go into detail and look at individual lines of code or do any deep dives, you can do that when you get a task in that specific area. The main purpose is to get a high level overview of where certain parts of the code live. Focus more on folders and files rather than what is in those files.

It can be as simple as where assets are stored or where the JS files are kept. But often it will actually expose certain design patterns that are used in the codebase and this is a good springboard for asking questions about certain styles within the code.

Pull down the repo and get it running locally 💻

Finally!

Something I never do, but I should, is actually read the ReadMe!

So often I just jump into trying to get the project set up that I overlook something as simple as reading the ReadMe. I then ask questions only to be sheepishly redirected back to the ReadMe. Hopefully it is up to date and will help you get the project set up locally.

But if there is something not up to date, make a note of it, even something as simple as typeo, remember that because we will use that to our advantage later.

Generate an ERD diagram 📈

If like me, you are a visual learner, I find this to be a neat trick to help you to get up to speed with the database quickly, without having to trawl through the schema.

There are different tools out there that can do this for you, but if you are using Rails there is a great gem called rails-erd that will do this for you.

This can help you to also understand the size of the system you are working with, how many data points there are, and if there is a big table you need to watch out for.

Lets ship a thing 🚢

Remember that typeo we spoke about earlier, let’s use that to our advantage.

You might not be ready to commit any working code to the project yet but you might be able to improve some documentation somewhere that lives inside the repo after your own onboarding experience.

Create a card for this change like you would for any coding task. Treat it exactly the same as you would any coding task even if it is only a minor correction.

You might feel like this is overkill, but this is a really good way to learn the workflow of making a change on a feature branch and deploying that change through the different environments all the way to production with minimal risk. You will also see how you move the card along on whichever task planner tool you use.

You will get to learn and ask questions about the end-to-end process from development all the way to production in a relatively safe environment. This will lessen the information load when you come to work on your first code-based task and allow you to focus on the code itself without having to also learn the process at the same time.

Ask for easy tasks/cards 😃

Yep that’s right, explicitly ask for easy tasks!

We already set expectations when we spoke to the client about the discovery phase, so lets use that time to do some discovering.

The purpose of asking for easy tasks is not to give you an easy time (even though by now you deserve one!). The purpose is also not to be able to ship things quickly. Everyone knows you could change the wording of a button quickly.

The purpose of an easy task is to give you time to look at that area of the codebase and learn some things about it. Removing complexity from the task itself allows you to focus and work through the complexity of the codebase whilst feeling slightly more comfortable about being able to make a rather trivial change.

You will likely encounter some design patterns and get a feel for some of the automated tests that might be used, as well as linting, and hopefully it will be a springboard for pairing with other developers as well.

⭐ Pro Tip: Ask for 3 or 4 simple tasks that all focus on the same area of the code. Focusing on one area to begin with can help to reduce cognitive overload and you can dive into other areas of the code at a later stage. Start small and simple.

Ask any question ❓

Lastly, ask, ask and ask some more.

It can feel embarrassing sometimes to feel like you are asking so many questions and even vulnerable to be showing others that you know very little.

But at some point on this project everyone knew nothing. Everyone asked the most simple questions because no one was born with the divine knowledge of how these things worked or came to be.

So allow yourself to be human and ask away.

I hope you find some of these tips useful.

It goes without saying that everyone onboards in different ways and ultimately everyone should onboard in the way that feels most comfortable and natural to them. There is no one size that fits all.

But maybe you can add one of these tips to your onboarding arsenal for the next time you join an existing project.

Thanks for reading! ✌️

Rebase with fixup 🔧

Wed, 29 Jun 2022 00:00:00 +0000

Say goodbye to squash and Hell Ye! to fixup

Lets imagine you are rebasing a branch called my-new-feature onto main. In order to do this you are doing an interactive rebase using the command git rebase -i main whilst you have the my-new-feature branch checked out.

(If you are using a GUI for git like the OP is using Git Extensions, if they are up to date they should also contain these new options)

Running git rebase -i main opens the following in your editor:

pick 996b0 work in progress
pick 59f3a feature finished

# Rebase b6914..59f3a onto b6914 (2 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
#                    commit's log message, unless -C is used, in which case
#                    keep only this commit's message; -c is same as -C but
#                    opens the editor
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified); use -c <commit> to reword the commit message

Note the new -C | -c flag.

s, squash = use commit, but meld into previous commit

f, fixup [-C | -c] = like "squash" but keep only the previous commit's log message, unless -C is used, in which case keep only this commit's message; -c is same as -C but opens the editor ---

Looking at our 2 commits:

  
pick 996b0 work in progress
pick 59f3a feature finished

Let’s imagine you want to meld them together (something which can be done with squash or fixup) but you want to only keep the helpful commit message of the second commit feature finished.

Using fixup as we have in the past like so:

  
pick 996b0 work in progress
f 59f3a feature finished

will not do what we want. It will meld the commits together but it will leave us with the work in progress commit message, which is not very helpful.

We could use squash like so:

  
pick 996b0 work in progress
s 59f3a feature finished

this will open a new editor which will allow you comment out the first commit message manually and persist the feature finished commit message. This does work but it forces you to have an extra manual step; aint nobody got time for dat

This is where the new option we can pass to fixup is super handy.

  
pick 996b0 work in progress
f -C 59f3a feature finished

This will meld the commits together but discard the work in progress commit message and only keep the feature finished commit message.

These new options make fixup even more powerful and allows you to rely even less on using squash when you don’t need to.

Ruby Splat Operator 🌟

Wed, 22 Dec 2021 00:00:00 +0000

The splat operator is confusing and here is why…

It does 2 things that are the exact opposite of each other.

Let me explain…

It destructures an array, which looks something like this:

x, y, z = [1,2,3]

puts x 
# => 1

puts y 
# => 2

puts z 
# => 3

But it can also be used to construct an array:

x = *123
#=> [123]

If you think about this, it is doing two very different things.

One takes an array and removes the surrounding [].

[123] becomes 123

The other takes a value and adds the surrounding [].

*123 becomes [123].

The only question we need to answer then is when does it destruct and when does it construct? 🤔

If you use it when defining a method it will take any argument you give it and construct it into an array.

def do_a_thing(*args)
  puts args
  puts args.class
end

do_a_thing(1,2,3)
# 1
# 2
# 3
# Array

If you use it when passing arguments as an array to a method it will deconstruct the array into arguments.

def do_a_thing(x,y,z)
  puts x
  puts x.class
end

do_a_thing(*[1,2,3])
# 1
# Integer

Hopefully now we can understand code that looks like this:

class Thing
  def self.perform(*args) # this splat operator will construct any arguments into an array
    new(*args).perform # this splat operator will deconstruct that array into arguments 
  end
  
  def initialize(x,y,z)
    @x = x
    @y = y
    @z = z
  end
  
  def perform
   puts @x
  end
end

Thing.perform(1,2,3)
# => 1

As an aside, the reason for the above class method of perform, is so you can easily call Thing.perform(), without having to first instantiate the object.

Using *args means that if our expected parameters in the initialize method were to change we would never have to change them in the perform class method.

Credit to this article which helped to shape my understanding.

Dependeny Injection 💉 ⚽

Fri, 17 Dec 2021 00:00:00 +0000

Fact: Objects will very often depend on other objects.

Dependency is not something we can avoid.

However, we can try to make that dependency as loose as possible utilising a pattern called Dependency Injection.

Lets have a look at an example which does not use dependency injection first.

class TottenhamHostspurFootballClub
  def play_a_match
    striker = HarryKane.new
    
    start(striker)
  end
end

class HarryKane
  def score
    #...
  end
end

Looking at the code above we can see that in order for TottenhamHostpur(Spurs) to play a match they need Harry Kane. This is a really restrictive tightly coupled dependency. This means that without a striker called Harry Kane, Spurs would not be able to play a match.

Imagine Harry Kane was injured, or worse, sold to a bigger club with more potential for trophies 😢.

When Spurs would try to play a match they would not be able to do so.

  TottenhamHotspurFootballClub.new.play_a_match
  # HarryKaneGoneError

Our TottenhamHotspurFootballClub class is pretty inflexible and relies heavily on HarryKane.

So how could Dependency Injection allow Spurs to survive and keep playing even if Harry Kane was unavailable.

class TottenhamHostspurFootballClub
  
  def initialize(striker = nil)
    @striker = striker || HarryKane.new
  end
  
  def play_a_match
    striker = @striker
    
    start(striker)
  end
end

class HarryKane
  def score
    #...
  end
end

Ok so now things look a little more flexible.

Of course Spurs are still dependent on a striker, we can’t avoid that.

But they are no longer tightly coupled to Harry Kane as being the only striker.

So we could do something like this:

  spurs = TottenhamHotspurFootballClub.new(LucasMoura.new)
  spurs.play_a_match

One of the key things here is that the TottenhamHotspurFootballClub class doesn’t really need to care much about who or what the striker is, it can get on with doing its own thing, only being concerned that it has received a striker.

Bonus: This would also help us test the TottenhamHotspurFootballClub class in isolation 👊.

When Memoization met DRY 💕

Wed, 15 Dec 2021 00:00:00 +0000

Let’s go on a journey into the world of memoization through the medium of ~~dance~~ Rails…

Once upon a time there was a controller with 3 typical methods:

class UserController
  def index
    clan = Clan.find(params[:clan_id])
    users = clan.users # a user belongs to a clan and a clan has many users

    render locals: {users: users, clan: clan}
  end

  def new
    clan = Clan.find(params[:clan_id])
    user = User.new
    render locals: {user: user, clan: clan}
  end

  def create
    clan = Clan.find(params[:clan_id])
    user = clan.users.new(user_params)

    if user.save
      redirect_to ...
    else
      render :new
    end

  end

  private

  def user_params
    params.require(:user).permit(:name, :power)
  end
end

And all was well and good until ‘DRY’ came along and said “No, not by the hairs on my chinny chin chin…”

In all 3 methods we have the exact same line of code clan = Clan.find(params[:clan_id])

Fear not, we can clean this up by using a before_action to do the exact same thing:

class UserController
  before_action :set_clan
  
  def index
    users = clan.users

    render locals: {users: users, clan: clan}
  end

  def new
    user = User.new
    render locals: {user: user, clan: clan}
  end

  def create
    user = clan.users.new(user_params)

    if user.save
      redirect_to ...
    else
      render :new
    end

  end

  private

  def user_params
    params.require(:user).permit(:name, :power)
  end
  
  def set_clan
    clan = Clan.find(params[:clan_id])
  end
end

“DRY” was happy with this and managed to calm down, until “Memoization” came along and said what if I can get rid of your before_action altogether 🤯

Check this out =>

class UserController  
  def index
    users = clan.users

    render locals: {users: users, clan: clan}
  end

  def new
    user = User.new
    render locals: {user: user, clan: clan}
  end

  def create
    user = clan.users.new(user_params)

    if user.save
      redirect_to ...
    else
      render :new
    end

  end

  private

  def user_params
    params.require(:user).permit(:name, :power)
  end
  
  def clan
    Clan.find(params[:clan_id])
  end
end

Notice what we did?

We removed the before_action and changed the set_clan method to be called clan.

This means that anytime the code calls clan it will not be calling a variable but rather the clan method.

But hold on a second, I spot a performance issue….

Take a look at the index method:

def index
  users = clan.users

  render locals: {users: users, clan: clan}
end

We call clan 2 times which means we will be hitting our database twice in order to retrieve the Clan record from the database.

Enter “Memoization”…

This’ll fix it 🪛

 def clan
   @clan ||= Clan.find(params[:clan_id])
 end

Great! But this is not easy to read, so what is this wizadry? 🧙‍♂️

Lets write the same method without the ||=

 
 def clan
    if @clan.present?
      @clan
    else
      @clan = Clan.find(params[:clan_id])
      @clan
    end
  end

Now this is more readable.

Essentially when the clan method gets called for the first time here users = clan.users the @clan varaible will be nil.

This means it will move to the else block and assign the @clan instance variable to the database record.

When it gets called a second time at render locals: {users: users, clan: clan} @clan will be present so it will just return @clan and not hit the database again.

Not only is this DRY, but it also means we don’t have to use a before_action and we learnt a cool way to utilise Memoization.

And they all lived happily ever after. The End. 👊

Co-authored with David Young

Rails "Joins Tables" are alphabetical

Thu, 02 Dec 2021 00:00:00 +0000

Imagine we have 2 models

Area
Lane

and you want to create a standard Joins Table with just an area_id and lane_id.

When you create the table via a migration Rails will automatically create the joins table with the folloing naming convention in alphabetical order areas_lanes.

If you then decided to change the Area table to be called Screen, one of the things you will likely do is write a migration to change the areas_lanes table to be called screens_lanes.

You may think Rails will therefore look for a joins table called screens_lanes after all we have simply switched the Area table for a Screen one.

Unfortunately not, Rails will look for a table called lanes_screens becuase it will keep to its alphabetical order naming convention.

So you will need something like this:

has_and_belongs_to_many :screens, join_table: "screens_lanes"

Rails! API!! Devise!!! JWT's!!!!

Wed, 30 May 2018 00:00:00 +0000

I had dreamed this day would finally come… Ok that’s a bit melodramatic, but to say I hadn’t lay awake thinking about this concept would be wholly untrue…

My journey into web-development started with all the good stuff on the frontend, as it does for most people. I even went the whole hog and threw in a framework (AngularJS) just for good measure. But now I was in Star Wars territory, this was the life of a server-side developer, time to separate the men from the boys (at least in my child-like mind).

Welcome Ruby on Rails. This was great, I could build a whole application back-to-front using this single framework Ruby on Rails. But hold on one second… If I could build everything with Rails, then what was the point of all the really cool frontend frameworks that everyone was raving about (currently React).

Well unfortunately it turns out that if you wanted to build an application using Ruby on Rails, you would miss out on all the cool functionality of the frontend frameworks like single page applications and 2-way data binding.

This left me in quite a predicament. I could have a really bespoke backend with Ruby on Rails but sub-standard frontend views. Or I could have a really bespoke frontend with Angular but a sub-standard database-as-a-service backend.

Well I wanted both (I screamed, lying down kicking my legs against the floor).

I wanted to have my cake and eat it!

Why couldn’t I have a bespoke backend using Rails and a bespoke frontend using whichever framework I so desired?

This pursuit led me to the crazy world of Rails! API!! Devise!!! JWT’s!!!!

I would build my backend using Rails new API mode. This would allow my backend to be completely agnostic and interact with whichever frontend I wanted. I needed to set up a good authentication system, especially as I was using an API, but I was able to do this using Devise and JWT’s.

Once I had the backend working as its own unit, as an API, I would be free to connect to that backend using HTTP requests from whichever frontend I desired, Angular, React, or even Android and IOS Applications.

Admittedly, this would be far more work but think of the benefits in the long-run. I would have one backend for all different forms of my application. I could have a native mobile application and a website all running off one single backend. Moreover, as the pace of change on the frontend gets ever more Usain-Bolt-like I would be able to adapt my frontend to the latest designs without being concerning about the star wars server side stuff.

Time to sit back, have my cake and eat it!

In my personal opinion, this division of labour between the backend and the frontend is how applications (especially sizeable ones) should be built. But hey! What do I know?! I’m just a developer with a child-like mind.

A project I built using this methodology.

How I Ended Up Here.

Mon, 25 Sep 2017 00:00:00 +0000

How do any of us end up anywhere? Well.. we dip our little toe in the water, and then we wait.. we wait for that freezing cold sensation which we expect to rush through our system and when it doesn’t come we breathe a deep sigh of relief and sink into that nice warm bath. And since dipping my toe into the ocean that be called ‘programming’ I am yet to retract from the ice cold water (mind you though, it can get pretty cold at times).

The straight and narrow path:
I went to school like most people (in London where i was born and raised) and following school I undertook my undergraduate degree BSc from The London School of Economics, one of the top universities in the country. However, although providing me with riguoruos academic analysis of the social political landscape and criminological theses. I didn’t leave LSE with a defined skill, more an amulgamation of academic disciplines (not to say that this hasn’t been handy).

The ~~interesting~~ different path:
Following university, I became rather interested in languages. No, not the computer sort. But.. the ancient sort. I spent time on a course learning the skills to translate Biblical Hebrew and, wait for it.. Aramaic. This study of ancient texts, propelled me into a world of new languages, and Talmudic study, requiring thorough rigurous analysis, organisation, sturcture and clarity. I loved it and I now teach a course in Biblical Hebrew and still continue to pursuit this source of study in my spare time.

From this stand-point the progression into programming was almost logical (more of a dipping toe in the water experience if i’m honest). I can now utiliste these core principles and disciplines of learning ancient languages to learn some of the most modern languages that exist today. And continuously engage in learning, thorough rigurous analysis, organisation, sturcture and clarity.

And here I am.

Please feel free to ask any questions, and if i can help with any advice from my own mistakes and successes along the way I would be happy to help!

What I Find Challenging

Sun, 24 Sep 2017 00:00:00 +0000

In life we all find different things challenging, what may be second nature to one person can be just as easily foreign to another and vice versa. The same rings true in various different industries. Lets examine Dentists. To one dentist performing a pulpectomy is (nearly) as simple as a walk in the park, to another dentist its the equivalent of walking up mount vesuvius in flip-flops.
Note: neither Dentist is subordinate to the other, it is just the nature of all of us in all settings to find different aspects more challenging than others.

So, where am I going with this?.. It is true this would be a good introduction to actually begin to relate a number of things I may find challenging in life as a whole. But lets quickly limit the question to the sphere of programming. Phew!

What have I, or do I, find most challenging about programming? For me personally it’s that first point where you grapple with or are introduced to a brand new concept for the first time. That moment, where you have to come to terms with something completley new and often without a previous frame of reference.

For example, learning JavaScript as an object orientated programming language for the first time was very challenging. Its a brand new concept and it’s complex at times. Moreover, when you try and find definitions for certain aspects, the definition can often include references to other concepts which hitherto are unknown. Thus, it can feel very overwhelming at first and take time to break down a new concept/language and gain a good understanding in order to venture forward.

However, the greater the challenge the greater the reward. Although overwhelming at first I actually enjoy taking something new and complex, investigating it, breaking it down, simplifying it and acquiring a good understanding of it.

Perhaps its reliving the lego building process of yesteryear where you destroy an entire space station to find out whats really happening underneath, get chased by your older brother, and then rebuild it with a far greater understanding and fear of your older brother than you ever had to begin with.

And with this, is a small insight into what I find most challenging about programming (at least at the moment). It may be worlds apart from what you find challenging or this may resonate with you entirley.

Always feel free to get in touch, if my own challenges can be of any assistance to you I would be happy to help!

My Motivation As A Developer

Sat, 23 Sep 2017 00:00:00 +0000

The title of this post is deceptive. Let me explain. There is an underlying assumption in the title that motivation can be isolated and confined to the work place. This may be true in some cases. But you didnt come all this way to read about some cases you came here (for some unearthly reason) to read about me. Call me one-dimensional if you wish, but for me personally it is worth extrapalating this title to incorporate my motivation as a human-being. Ergo, I have always found that the motivations I possess in life as a whole, must also exist and blossom in my place of work.

In essence therefore, what motivates me as a developer is exactly what motivates me in my day to day existence.

So that being the case, what simply does it for me (apart from ancient texts)?

Well, for some reason, I really do have a genuine drive to help others, not a programming motivation I here you say. Well yes on the surface you are right. But look deeper and its a multi-dimensional motivation which envokes an honest, genuine desire to help you.

Overwhelemed by the tech world and enormity of the web, not to mention complex jargon? I genuinely want to try and help you. Need a certain feature or functionality? If I can I really would like to help.

This motivation really helps me to push through tricky programming challenges because I simply want to help you where I can.

I want to know about other things that motivate you I hear you cry! Well if you insist.
I enjoy breaking things down, getting to understand what’s really going on. Simplifying the complex. Creating order. Structure. Clarity.

Now these motivations may not be your cup of tea by any means, in fact I am completley the type of guy you dont want to play lego with! But these motivations derive from my enjoyment of achieving sense within the seemingly senseless and they have facilitated my motivation in programming and enjoyment of it too.

Whats that?!! You do want to play lego, sure! Get in touch..